Daniel Rodríguez-Fernández

Isaias Martinez-Yelmo

Ellen Munthe-Kaas
email: ellenmk@ifi.uio.no

Thomas Plagemann
email: plageman@ifi.uio.no

Always best (dis-)connected: challenges to interconnect highly heterogeneous networks

Wireless networks enable mobility, multihoming, and Delay Tolerant Networks. In such networking environments, the principles of the Internet, i.e., the end-to-end principle and the combination of location and identification in IP addresses, cannot be applied. In this paper, we propose a scalable application centric approach for mobility and multihoming that is able to interconnect highly heterogeneous networks where the networks may belong to different networking paradigms, e.g., IP based and Delay Tolerant Networks. Applications and users that aim to communicate, form communities. Community members might together have several network technologies available, and the community layer manages internetworking information for the members to seamlessly integrate these. Networking adaptation layers are used to provide a common interface for the different networks to the community layer. Addressing is based on names, cryptographic identifiers, and network locators and such that identifiers can also be created in infrastructure-less and disconnected situations.

Introduction

Mobile devices with multiple wireless networking capabilities, like IEEE 802.11, 3G and Bluetooth, have become mainstream devices in the recent years, and their popularity will increase also in the future. Applications running seemingly smoothly over these different networks give the impression that the Internet architecture is well suited for future wireless and mobile computing. Unfortunately, this impression is not correct. Basic mobility support required a patch to the Internet architecture, i.e., Mobile IP. Mobile IP enables the user to be reachable via the same IP address while roaming, through the help of a Home Agent. Since the Home Agent is a part of the network it conflicts with the fundamentals of the Internet architecture, i.e., the end-to-end principle. The basic problem that causes this conflict is the fact that IP addresses are used as locators and identifiers at the same time. The combination of identification and location causes also substantial problems for seamless integration of different networking technologies at the end host, i.e., for multihoming, because each network interface requires its own IP address. There are several ongoing efforts in the IETF to develop new patches to the Internet architecture to handle multihoming, but so far no solution has been adopted and is mature enough.

Another challenge to the Internet architecture is introduced by Mobile Ad Hoc Networks (MANETs) and Delay Tolerant Networks (DTNs). DTNs are infrastructure-less networks, which are so sparse that end-to-end connections cannot be established. Therefore, DTNs apply the store-carry-forward principle, i.e., nodes carry messages for some time until they meet other nodes that can be used to forward the message one hop. Obviously, such an approach is contradicting to the end-to-end principle and IP cannot be used in DTNs. Thus, DTNs represent a new networking paradigm and are clearly separated from MANETs. MANETs are also infrastructure-less networks, but they obey the end-to-end principle and are based on IP. In MANETs, it is assumed that route breaks caused by mobility can be quickly fixed through discovery of new routes and re-routing. We believe that the strong separation between MANETs and DTNs is wrong, because both network types are infrastructure-less and are used either due to necessity, i.e., no network infrastructure exists, or due to the explicit choice of the user. Examples for the first case include sensor networks for wildlife and environmental monitoring, emergency and rescue operations in areas with destroyed infrastructure, and also military applications. Examples for the second case include Vehicular Networks which do not want to rely on cellular networks like 3G due to the unacceptable end-to-end delay between neighbouring vehicles, and social content distribution networks that either want to save money (roaming costs) or want to establish a network that nobody can control, like floating content [START_REF] Ott | Floating content: Information sharing in urban areas[END_REF]. The question whether MANETs or DTNs should be deployed in a certain setting depends on the density and mobility of the nodes. MANETs might become quickly partitioned and nodes in DTNs might be close enough to each other to form a MANET with end-to-end connection. Multihoming and a seamless integration of the different networking paradigms would enable applications that are always best (dis-)connected in highly heterogeneous networks. Therefore, full advantage and resource optimisation of available communication capabilities from underlying layers could be obtained for applications and services in any network (dis-)connected node.

The contributions of this work comprise the identification of the challenges introduced by mobility, multihoming and different network paradigms and a proposal to address these challenges. One of the main characteristics of our proposal is that it is application and user centric compared to related network centric solutions.

The rest of the paper is structured as follows. In Section 2, we detail the challenges that mobility and multihoming over highly heterogeneous networks present. The state of the art in mobility, multihoming and heterogeneous internetworking is discussed in Section 3. In Section 4, we present our proposal for solving the aforementioned problems. Section 5 concludes the paper, discussing the differences between the proposed approach and related work, and pointing out our future work.

Challenges

The proliferation of wireless technologies has broken many of the assumptions made in the design of the current Internet. On the one hand, the Internet was designed with a much more reliable wired network in mind, so some protocols as TCP may be inefficient for wireless communication. On the other hand, wireless technologies have facilitated node mobility and multihoming through the access to different network technologies, such as e.g. IEEE 802.11, Bluetooth, and 3G. These two novelties have revealed a fundamental problem in the design of IP, i.e. the dual role of the IP address, which acts as node identifier and network locator. Due to this design issue, IP cannot provide native support for node mobility and multihoming. In Section 3, we present several approaches for identifier and locator split, which in turn introduce many new problems.

The application of wireless technologies has pushed to the limits the utilisation of networking technologies. In so-called challenged networks [START_REF] Fall | A delay-tolerant network architecture for challenged internets[END_REF], it is necessary to deal with long delays and network disruptions, breaking some of the fundamental assumptions made during the Internet protocol suite design. In such networks, it is not possible to rely on the classical end-to-end principle widely used in the Internet. This has caused the apparition of a new networking paradigm, i.e. DTN. In this section we describe the challenges that arise from the conjunction of mobility and multihoming support when internetworking highly heterogeneous networks that might be based on different networking paradigms.

Wireless technologies have inherent problems which are not usually observed in wired networks. The transmission medium causes a higher probability of transmission errors due to interferences or collisions when several nodes try to transmit in a free transmitting slot. These effects are caused by the existing limitations in the wireless medium and can consequently not be removed. In addition, such undesirable effects might be increased by other phenomena such as hidden nodes. Since these effects were not taken into account in the design of the Internet protocol suite, the usage of TCP/IP on wireless technologies leads to a suboptimal utilization of the available resources. The current layered approach of the Internet does not offer enough flexibility to take full advantage of the available resources. This has resulted in a number of different cross-layering optimisation proposals [START_REF] Srivastava | Cross-layer design: a survey and the road ahead[END_REF].

Wireless technologies have enabled device mobility. At the same time, the diversity of wireless technologies has caused the proliferation of multihomed devices, i.e., devices which can use more than one wireless technology to communicate. Neither host mobility nor host multihoming are supported in the current IP. This is due to a fundamental architectural problem of the current Internet, where IP addresses have a dual role as both host identifiers and network locators. At the application and transport layers, IP addresses are used to identify a host, so all information flows are attached to them. At the network layer, IP addresses are network locators, indicating points of attachment to the network. In order to achieve global scalability, IP addresses are aggregated reflecting the hierarchical organisation of the network. Therefore, if host mobility causes a change in the point of attachment to the network, the host appears as a different node to the rest of the network. In this case, the host should reset the information flows in order to continue with the communication. A similar problem comes from multihoming, where a host appears as different nodes to the network. The hosts should decide upfront which IP addresses to use for communication. In order to provide native support in the network layer for mobility and multihoming, there are many proposals that rely on the separation of the roles that the current IP address possesses. In Section 3, we describe some of those approaches.

The Internet was designed to interconnect sub-networks, which may have different underlying networking technologies. During the design of the Internet, the end-to-end principle was proposed, where complexity is moved to the hosts, while the network is kept as simple as possible. The end-to-end principle works fine in presence of constant end-to-end connectivity, low probability of error, and small end-to-end delays. However, the end-to-end principle cannot be successfully applied in all kinds of networks, e.g. in challenged networks [START_REF] Fall | A delay-tolerant network architecture for challenged internets[END_REF]. Such networks require a different networking paradigm, i.e. DTN. This is based on the store-carry-forward principle, where the intermediate nodes need to play a much more important role than in the Internet. It should be noted that from the DTN perspective, node mobility and multihoming could be considered more as an opportunity than as a challenge, since they allow new alternative paths to deliver information if they are properly handled.

The internetworking of heterogeneous networks is a complex problem that poses many issues. According to [START_REF] Tanenbaum | Computer Networks[END_REF], networks can vary in type of service, routing and forwarding protocols, addressing scheme, packet size, support for QoS, flow and congestion control, security, accounting, etc. An internetworking solution needs to take into account all the differences. In this paper, we also consider the integration of different networking paradigms, i.e. IP networks and DTNs, which adds additional challenges. The internetworking should be aware of the networking paradigm of the underlying networks and perform according to them. For example, in order to provide interoperability between the Internet and a DTN, the internetworking system should be able to work in DTN mode, avoiding or replacing the usage of the end-to-end principle.

Current mobility and multihoming solutions relying on IP may not work properly over DTNs since IP assumptions are incompatible with the DTN paradigm. Any solution should nonetheless take into account all challenges that emerge when the identifierlocator split is done. The mapping between identifiers and locators must also work in DTN mode. One issue is that, at times, it may not be possible to update the mapping information due to network partitions. Thus, the mapping system should be able to work with partial knowledge. On the other hand, the mobility of nodes could be beneficial since node mobility may allow communication among otherwise isolated partitions (akin to message ferrying).

In the following section, we present the state of the art of solutions that consider some of the aforementioned challenges.

State of the art

In Section 2, we introduced the problems that the current IP has due to the dual role of the IP address. Unfortunately, IPv6 does not offer a native solution, having the same problems as IPv4. There has been an effort at the IETF to give solutions to issues like mobility, multihoming, security, etc. However, instead of providing a general solution, each of these solutions focuses on a specific challenge, leading to incompatible partial solutions. A network based solution for multihoming is LISP [START_REF] Farinacci | Locator/ID separation protocol (LISP)[END_REF]. LISP does not require modifications on the hosts, only on network routers. The problem with LISP is that it presents scalability issues when deployed on the Internet. Other proposals are host based, requiring modifications only on hosts and a few nodes in the network. This is the case of Mobile IP (MIP) [START_REF] Johnson | Mobility support in IPv6[END_REF][START_REF] Perkins | IP mobility support for IPv4, revised[END_REF], SHIM6 [START_REF] Nordmark | Shim6: Level 3 multihoming shim protocol for IPv6[END_REF], and HIP [START_REF] Nikander | Host identity protocol (HIP): Connectivity, mobility, multi-homing, security, and privacy over IPv4 and IPv6 networks[END_REF], which target mobility, multihoming and security, respectively, but with extensions that can be used to solve other issues. HIP provides a clear solution, not just to security but also to mobility and multihoming. HIP adds a new layer between network and transport, and introduces a new cryptography-based identity namespace. Identities are composed by a publicprivate key pair, where the public key is used as host identifier (HI). Upper layers use HIs, while IP continues using IP addresses which maintain their topological information. All these approaches are designed to solve problems of IP (IPv4 or IPv6), trying to patch the current Internet rather than giving new architectural designs. All assume that IP is used as network protocol. Thus, they are making the same assumptions as IP.

In parallel, the IETF DTN-RG has proposed the Bundle Protocol (BP) [START_REF] Cerf | Delay-tolerant networking architecture[END_REF][START_REF] Scott | Bundle protocol specification[END_REF], which aims to provide a general solution to DTN. The bundle protocol creates an overlay composed by BP agents that interconnect different DTN regions. A convergence layer is used to encapsulate the native network stack of each region. Security is an optional extension defined in [START_REF] Symington | Bundle security protocol specification[END_REF]. The naming proposal is intentional naming [START_REF] Basu | Intentional naming in DTN[END_REF]. It is very flexible, but it is unclear how to do routing and how to support multihoming and mobility. BP has been criticised that it lacks reliability and error detection support, relies on synchronised time among BP agents, lacks a clear naming scheme, and lacks support for application requirements [START_REF] Wood | A bundle of problems[END_REF].

There has also been a significant amount of effort on the definition of the Future Internet. Many of the proposals give a clean slate design, reviewing the fundamental principles of the Internet. A general survey in the area can be found in [START_REF] Paul | Architectures for the future networks and the next generation internet: A survey[END_REF]. Due to space limitations we can mention only a few of them. The Ambient Networks [START_REF] Niebert | Ambient networks: an architecture for communication networks beyond 3G. Wireless Communications[END_REF] propose a flexible framework to create the so-called ambient networks, which are formed spontaneously by the nodes that have some access to networking technology. The project aims to fulfil the always best connected vision [START_REF] Gustafsson | Always best connected[END_REF]. The proposal of SpoVNet is also interesting, by providing a generic framework to create overlays. The internetworking functionality is provided by the Underlay Abstraction, described in [START_REF] Bless | The underlay abstraction in the spontaneous virtual networks (SpoVNet) architecture[END_REF]. However, neither Ambient Networks nor SpoVNet consider the problems that may arise from the integration of DTN. Despite the large amount of work, there are not many proposals that consider the problem of internetworking of highly heterogeneous networks, where different networking paradigms need to be integrated.

PONA [START_REF] Paul | A vision of the next generation internet: A policy oriented perspective[END_REF] proposes a separation layer that performs the ID-locator split at different levels, allowing host, user, and data IDs. It proposes a hierarchy of realms that reflects logical organisations, e.g. administrative or commercial organisations. A hierarchy of connectivity zones reflects the physical network connectivity. PONA does not propose a specific ID definition, allowing different types depending of the type of realm. It also allows users to specify requirements by providing policies. This vision also allows the possibility of supporting DTN relying on the realm structure.

MEDEHA/HENNA [START_REF] Rais | Towards truly heterogeneous internets: Bridging infrastructure-based and infrastructure-less networks[END_REF][START_REF] Rais | Communication Mechanisms for Message Delivery in Heterogeneous Networks Prone to Episodic Connectivity[END_REF] is a proposal for internetworking of highly heterogeneous networks. It can interconnect infrastructure networks and MANETs, and also can work in a DTN-like mode. MEDEHA was originally designed to work over IPv4. However, HENNA provides an ID-locator split which can be used to enhance MEDEHA. HENNA provides support for IPv4, IPv6 and DTN network locators. It works in a similar way to MIP, extending it to support DTN. The Location and Management Server (LMS) plays a similar role to the Home Agent on MIP. HENNA has two main problems: (1) its lack of support for multihoming, allowing just one network locator for each node identifier, and (2) the construction of the identifiers. Node IDs are constructed by concatenating the LMS locator on the Internet and a local label managed by the LMS. This causes many security and scalability problems. HENNA makes many assumptions about the LMSs, which should be static and publicly available at all times. Furthermore, the node IDs depends on a specific locator (IP address) of the LMS. Thus, the ID-locator split problem still remains at the LMS level (e.g. making impossible to exploit LMS multihoming).

The Phoenix architecture [START_REF] Luo | The-Day-After networks: A First-Response Edge-Network architecture for disaster relief[END_REF] aims to fulfil the communication requirements after a disaster, on a so-called Day After Network (DAN). The idea of such networks is to integrate all available communication means after a disaster and use them to offer services to the rescue team, victims of the disaster, etc. The proposal relies on two protocols: the Phoenix Interconnectivity Protocol (PIP) which enables the creation on islands of connectivity though heterogeneous networks, and the Phoenix Transport Protocol (PTP) which enables delay tolerant communication between partitions. The proposed naming system is based on roles, such as firemen, police, etc. However, apart from the project description, there is not much information available about these two protocols.

Community Internetworking

In this section we present our proposal to solve the challenges presented in Section 2. In order to take full advantage of present and future networking heterogeneity, it is necessary to consider the following requirements. Firstly, it is vital not to make strong a priori assumptions about the underlying networks. Consequently, the internetworking system needs to be aware of the characteristics of these networks, by some kind of network description and corresponding ontology. The internetworking further needs to be aware of the changing status of the network and the nodes resources. It is also necessary to support node multihoming and mobility. An application should be allowed to influence the internetworking, describing the service that it expects from the network. Finally, security should be a main concern of the internetworking system.

Taking into account the aforementioned requirements, we propose community internetworking. The basic idea behind our proposal is to provide internetworking to a set of nodes that want to communicate with each other. This set of nodes is called community in our proposal. The nodes that compose a community may have access to several heterogeneous networks, so the community should handle this heterogeneity in order to perform the internetworking. Multihoming over highly heterogeneous networks can cause an explosion in routing information management, since nodes may be accessible though several networking interfaces. In order to avoid scalability issues, we propose that instead of managing all nodes in each network, just the community members are taken into account in each community. This allows performing a more sophisticated internetworking, because much less information needs to be managed. The communities are created to reflect a permanent or temporal relationship among the nodes that form them. The relationship can, e.g., reflect an organisation or a social network. It also can be created to support requirements of an application, as, e.g., a video streaming commu- nity or a content sharing community. Another example can be a Personal Area Network, where the community integrates all the communicating devices currently used by a user (laptop, phone, PDA, etc.). We assume that the community receives a set of policies that reflects the requirements of the application and user. These policies determine the behaviour of the community. Node mobility and multihoming are supported through an identifier-locator split described in Section 4.1. Figure 1(a) illustrates how community internetworking reduces the size of the problem, as just the nodes that are members of the community are considered in the internetworking. Our proposal relies on three main abstractions: node, networking substrate, and community. The node represents a device that has access to one or more networking substrata, and can be member of one or more communities.

The community abstraction represents a group of nodes that cooperate in order to fulfil some common objectives. Communities are formed to support the high level requirements of applications and users. These policies will be used to manage the community internals. Each community should perform the internetworking of its members over different networking substrata.

Finally, the networking substrate represents any kind of legacy or future network. Our proposal aims for minimising the assumptions about the internal characteristics of the networking substrata, which is just assumed to be able to provide some basic networking functionalities, such as transmission of packets and some kind of addressing. Thus, this abstraction can wrap many different types of networks, ranging from complex network overlays to simple communication services such as SMS, including direct communication over link layer protocols. The current Internet is one possible instance of a networking substrate. In order to be able to use the different networking substrata, we place on top of each of them a Networking Substrate Adaptation Layer (NSAL). The NSALs provide a common API to the communities by using the native primitives of each networking substrate. NSAL is further described in Section 4.4. However, the common NSAL API is not enough to perform a proper internetworking, it is also necessary to know the internal properties (addressing scheme, type of service, etc.) of each networking substrate. We obtain such knowledge from a self-description of the networking substrate, which is one of the key services provided by the NSAL.

Name-Identifier-Locator

Our approach for ID-locator split identifies three main entities: name, identifier, and network locator. Names constitute a high level abstraction, which can be resolved into identifiers, which are used to uniquely identify nodes and communities. Identifiers are mapped to the network locators that the nodes have on each of the networking substrata. The namespaces for names, identifiers and network locators are independent of each other.

Our proposal does not require names to be of a specific type. We believe that depending on the specific situation, different name systems might be used. The only requisite is that it must be possible to resolve names into identifiers. Two examples of name systems could be the fully qualified domain names provided by DNS, or the role based naming proposed in [START_REF] Luo | The-Day-After networks: A First-Response Edge-Network architecture for disaster relief[END_REF].

Network locator spaces are defined by each networking substrate. They may have meaning only inside the network substrate. For example, IPv4 and IPv6 would use IPv4 and IPv6 addresses respectively, while a DTN may use another type of network locators such as, e.g. GPS coordinates in geographic based DTN routing.

The common namespace for all the communities and nodes is the identifier namespace. We propose the usage of cryptographic based identifiers similar to what HIP proposes [START_REF] Nikander | Host identity protocol (HIP): Connectivity, mobility, multi-homing, security, and privacy over IPv4 and IPv6 networks[END_REF]. The identifiers are the public part of an identity, which is a public-private key pair. In our proposal, both nodes (hosts) and communities are associated with at least one identity, and therefore an identifier. Cryptographic identifiers have the following advantages: (1) They offer support for security and ( 2) can be auto-generated by each entity. In addition, (3) they are totally independent of names and network locators.

At the same time, they introduce some challenges since such identifiers do not provide any information about the location of the entities in the network substrata. Hence, we need a system that maps the identifiers to network locators in order to be able to start any communication with a node or community. An issue that arises from the usage of identifiers is privacy. In our proposal, nodes can have one or more identities. A node with two identities would appear to the rest of nodes as two different nodes.

Community Layer

The implementation of the community internetworking functionality is done in the community layer. As shown in Figure 1(b), this layer is introduced between layer 3 and layer 4. Nevertheless, the network substrate definitions allow the coexistence of very different networking substrata, ranging from link layer network technologies to complete protocol stacks. The community layer maintains on each node a registry that contains information about: (1) its identities, (2) its NSALs, and (3) the communities that the node is member of. The community layer is also responsible for coordinating the utilisation of shared resources on the node by different communities. The communities may, for example, have a priority that could be used to organise the usage of these resources.

As shown in Figure 1(b), a cross-layering information sharing component gives access to information from other components of the system. In order to achieve awareness, nodes, communities and networking substrata should be able to give a description of their characteristics. In addition to this description, information about the status of the networking substrata and the node internal resources is needed. For this purpose, a monitoring framework component will be used. The monitoring framework is in charge of performing measurements about the status of nodes and networking substrata. This component is shared by all communities, leading to an efficient utilisation of the resources. For instance, if several communities require the same type of measurements, they need to be performed only once.

Community Management

Each node can create communities. We assume that, when a community is created, it is provided with a set of policies that reflects the preferences of an application or user. Community management and internal routing will be done according to those policies. The ownership of a community is given by the ownership of the private key of the community identity. The node that creates a community is therefore its owner. The owner may either delegate to other community members management responsibilities, or share the private key with other members of the community. This is decided by the community policies.

Another way to become member of a community is joining an existing community. Nodes can apply for joining a community, or they can be invited to join it. In both cases, community membership policies are checked before membership is granted.

The communities maintain the mapping between the identifiers of its members and their network locators within the different networking substrata. This mapping is performed by the mapping manager component. The implementation of this component depends of the community. For instance, in a small size community that should deal with disruptions, each node may maintain its own local copy. In a larger community where nodes are accessible through stable networks, the mapping manager may be implemented in a different form, e.g. by a distributed hash table, in order to achieve better scalability.

The inter-community routing is performed according to the community topology. This can be extracted from the mapping manager of each community. The selection of the next hop inside of the community is done by using the routing policies of the community. In this process, the NSAL and the network locators that will be used are selected. This last process might be too heavy for a per-packet processing. Thus, it may be possible to use a per-flow processing, where a temporal state about the open communication flows is used. This state may react to changes in the community topology and modify the next hop of the flow. Each hop at the community level may be done in a different networking substrate. This hop inside of a network substrate may potentially require more than one internal hop, which will be managed by the native routing and forwarding mechanisms of the networking substrate.

Communities might also consider the case when none of the available networking substrata can be used to send data to the destination. This could for example occur when nodes do not have a DTN substrate. In this case the community might decide, based on the community policies, to provide some basic DTN support, e.g. buffering data. The behaviour of this DTN support would be managed by the community policies.

Networking Substrate Adaptation Layer

The networking substrate provides a generic abstraction for any kind of legacy network. This allows the community layer to handle highly heterogeneous networks. There may be large differences between the technology, protocols, addressing, and even networking paradigm of the networking substrata. In order to reduce the complexity required at the community layer, we introduce the Networking Substrate Adaptation Layer, which wraps a particular networking substrate and provides a set of services though a common API to the community layer. One of the key elements is the networking substrate description. We assume a network definition language that can be used to communicate the networking substrate properties to the community layer. The last may be done by a network definition ontology.

The services provided by the NSAL API include services to (1) send data and (2) receive data, (3) resolve names to identifiers, and (4) resolve identifiers to network locators. These two functions can be combined to find communities by using a networking substrate. The first is used to, given a name, resolve the identifier of a node or a community, while the second is used to, given an identifier, resolve network locators to a node or a community in the networking substrate. And finally, (5) request a description of the properties of the path to the destination in the network substrate. The path description is used by the community layer to identify the best network substrate to forward data to. To implement the name-to-ID and ID-to-locator resolve services, the adaptation layer will use the native services offered by the network substrate, if available. For example, an IP NSAL could use DNS, while a DTN NSAL may use an epidemic dissemination. The send and receive services are mapped to the native send and receive primitives of the network substrate.

Conclusions

In this paper we present community internetworking, which is our proposal to support mobility and multihoming in highly heterogeneous internetworking. The basic idea behind our proposal is to provide internetworking just to the nodes that need to participate in a communication, following an application and user centric approach compared to other networking centric approaches. This decision reduces the size of the problem, allowing a better scalability. In our approach, we define three main abstractions: node, community, and networking substrate. A node may be member of several communities and have access to different networking substrata. Communities manage the internetworking among the nodes that are members of the community. The behaviour of a community is driven by a set of policies that reflects the preferences of an application and user. Finally, the networking substrate represents any kind of legacy or future network. It is integrated into the community internetworking by a Networking Substrate Adaptation Layer (NSAL) that offers a common API to the communities. In order to deal with the networking substrata heterogeneity we propose that each NSAL provides a description of the networking substrate that it wraps.

There have been several proposals to support mobility and multihoming, and to perform heterogeneous internetworking. However, just a few approaches consider the integration of Delay Tolerant Networking (DTN).

The DTN Bundle Protocol presents a set of problems as indicated in [START_REF] Wood | A bundle of problems[END_REF]. The current naming system [START_REF] Basu | Intentional naming in DTN[END_REF] is quite imprecise about how mapping and routing should be done. Neither is there a clear way to support mobility and multihoming. Finally, the support for the application requirements is very limited.

The vision of the Future Internet provided by PONA [START_REF] Paul | A vision of the next generation internet: A policy oriented perspective[END_REF] presents many similarities with community internetworking. For instance, the user requirements are specified though policies. Realms and zones have a similar function as communities and networking substrata. However, our concept of community is more general since it is not necessarily attached to an organisation. The same is the case of the networking substrata, which can be used to describe, not just the connectivity structure, but almost any kind of network, ranging from the Internet to a DTN, including MANETs. In our proposal we also present a clear identity system and a mechanism to support legacy or future networks by using NSAL and its network description functionality.

The MEDEHA/HENNA [START_REF] Rais | Towards truly heterogeneous internets: Bridging infrastructure-based and infrastructure-less networks[END_REF][START_REF] Rais | Communication Mechanisms for Message Delivery in Heterogeneous Networks Prone to Episodic Connectivity[END_REF] proposal for highly heterogeneous networks internetworking does not provide support for multihoming. Its ID-locator split scheme relies on the locators of a global Internet (LMS locator + a local label) and introduces the same ID-locator problems (mobility, multihoming, security) at the LMS level. Our proposal fully separates the identifier namespace from the specific network locator namespaces, in a similar fashion as HIP. MEDEHA/HENNA provides a limited support for the application requirements. There is no concept similar to the community, and therefore all the nodes need to be considered for the routing, which can lead to scalability issues.

The Phoenix architecture [START_REF] Luo | The-Day-After networks: A First-Response Edge-Network architecture for disaster relief[END_REF] targets DAN scenarios, while we propose a more general internetworking approach that covers a larger type of networks. Another difference is that Phoenix has a role based naming, whilst we propose the concept of community. Both role and community based approaches have as a goal to provide routing scalability. The community abstraction can be used to create role based communities, e.g. a police community. In our approach, application requirements are specifically supported through policies. Finally, [START_REF] Luo | The-Day-After networks: A First-Response Edge-Network architecture for disaster relief[END_REF] does not describe how node and network heterogeneity is managed, while our proposal relies on the node, community and networking substrate description, the last one provided by NSAL.

The ANA framework [START_REF] Bouabene | The autonomic network architecture (ANA). Selected Areas in Communications[END_REF] provides very generic abstractions that can be used to implement different communication paradigms. It does not define how addressing, routing, etc. should be done, leaving this to the system designers.

Our ongoing and future work is to refine the design of the community internetworking presented in this paper and to implement a proof-of-concept prototype, for which we are considering to use the ANA framework. We plan to focus our first experimental studies on the integration of MANETs and DTNs.

Fig. 1 .

 1 Fig. 1. (a) Community Internetworking example, and (b) Community Layer scheme

Acknowledgements

This work has been funded by the VERDIKT Programme of the Norwegian Research Council through the DT-Stream project (project number 183312/S10).


Eleni Trouva

Eduard Grasa
email: eduard.grasa@i2cat.netday

John Day

Ibrahim Matta

Lubomir T Chitkushev

Steve Bunch
email: steve.bunch@ieee.org

Miguel Leon
email: miguelpdl@tssg.org

Patrick Phelan
email: pphelan@tssg.org

Xavier Hesselbach-Serra
email: xavierh@entel.upc.edu

Miguel Ponce De Leon

Transport over Heterogeneous Networks Using the RINA Architecture

Keywords: Recursive Inter-Network Architecture (RINA), heterogeneous networks, data transport, mobility, hand-offs

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The Internet originated from and still is primarily a wired network. However, with the years several wireless technologies evolved to meet the growing need for mobility. Users have come to expect access from anyplace, anywhere. In order to make this vision a reality, in the future users will have a greater choice between a wide range of services from various access networks, wired and wireless, giving a new meaning to the Internet as an heterogeneous network. In the effort to migrate the current Internet architecture to a hybrid environment, the research community has encountered many problems. One of the main difficulties arose in providing seamless mobility, while achieving the best utilization of the resources.

As transport over heterogeneous networks must be one of the main features of the future network, it should be faced as a chance to re-evaluate the current Internet architecture. In this paper, we review the challenges encountered, examine the proposed solutions and analyze their inability to provide a global solution that addresses all the problems. Next, we explore how these issues are handled when based on fundamental principles as in the Recursive Inter-Network Architecture (RINA), a clean-slate architecture and present a realistic example of RINA over different physical media.

2 Challenges in Mobility over Heterogeneous Networks

Characteristics of the Hybrid Paths

Hybrid paths exhibit varied behavior across different physical media and technologies as we move from one end of the network to the other. A plethora of available hardware technologies that carry the signal exist and can be classified into guided (wired) or unguided (wireless). In wireless communications, many physical phenomena, such as fading, shadowing, path loss, affect transmission and put impairments in the propagation of the electromagnetic waves. As a result, wireless channels are characterized by higher bit error rates (BER), lower bandwidth and longer round trip times (often variable) comparing to the wired ones.

TCP's performance over hybrid environments has been extensively studied and proven inefficient with the wireless media [START_REF] Tsaoussidis | Open issues on TCP for mobile computing[END_REF][START_REF] Pentikousis | TCP in wired-cum-wireless environments[END_REF][START_REF] Balakrishnan | Improving TCP/IP Performance over Wireless Networks[END_REF][START_REF] Caceres | The Effects of Mobility on Reliable Transport Protocols[END_REF][START_REF] Desimone | Throughput Performance of Transport-Layer Protocols over Wireless LANs[END_REF]. Specifically, the congestion control mechanisms of TCP are the main reason why TCP fails to adapt to an heterogeneous environment. As already mentioned, BER is high in wireless links, whilst negligible in wired. In addition, wireless links are characterized by interrupted connectivity and frequent hand-offs. Media related losses that happen in wireless links are falsely interpreted by TCP for losses due to congestion in the network and trigger congestion control mechanisms. Each "false alarm" forces a reduction in the TCP window size, which results in a severe drop in throughput. This assumption leads to degradation of performance. In essence, TCP has network congestion control, rather than Internet congestion control.

Another issue occurs from the default behavior of TCP to increase the window size proportionally to the rate of the incoming acknowledgments (ACKs). In hybrid paths, the wireless nature imposes high delays, which implies a slower rate in opening the window compared to pure wired links, although the channel might have the capacity for higher throughput. Most of the operations performed from a mobile terminal (e.g. e-mail, web browsing) require the transmission of small amounts of data on short-lived flows. In TCP a sender starts to transmit data in slow start phase and gradually increases the window and thus, the throughput. For short-lived flows, there is high possibility that the operation will be completed while the sender is still in slow start. This is another case in which the native TCP congestion control mechanisms lead to poor use of the available resources.

To alleviate the problems of traditional TCP new implementations have considered additional mechanisms for congestion control: Congestion Avoidance (Tahoe, Reno, Vegas), Fast Retransmit (Tahoe, New Reno), Fast Recovery (Reno, New Reno) and Selective Acknowledgment (SACK) are some of the algorithms introduced. Nashiry et al. [START_REF] Nashiry | Evaluation of TCP performance over mobile IP wired-cum-wireless networks[END_REF] and Henna [START_REF] Henna | A Throughput Analysis of TCP Variants in Mobile Wireless Networks[END_REF] show results of performance measurements of the TCP variants. However, the problem of opening the window according to the received ACKs rate has remained. Moreover, many TCP modifications were proposed to address the problem, such as TCP SAK, TCP FACK and TCP Santa Cruz.

Apart from these proposals, other approaches tried to address the unsatisfactory performance in heterogeneous environments. One of the ideas proposed was to split a connection over a hybrid path to wired and wireless part, for example at the base station. In this way, the base station has the role of acknowledging every packet back to the source. This solution breaks the end-to-end reliability. It is possible that an ACK arrives to the source without the packet actually has arrived to the destination. Another approach is to perform actions in the data link layer and hide it from the transport layer in order to avoid the problems with TCP. Modifications outside TCP were also proposed. Explicit Congestion Notification (ECN) is an example, in which explicit notification for congestion is signaled by the routers. In addition, some new transport layer protocols were designed with the wired/wireless environment in consideration (e.g. WTCP). Pentikousis [START_REF] Pentikousis | TCP in wired-cum-wireless environments[END_REF] provides an extended review of the proposed solutions.

Many of the proposals mentioned above managed to improve the performance of TCP over heterogeneous networks. Yet, none of them manages to address all the problems caused by the characteristics of the hybrid paths, as TCP was not originally designed for such an environment. However, some of the proposed solutions provide some insight on what is the root of the problem. Splitting the hybrid path to wired and wireless for example, underlines the necessity of having a way to treat parts of the network differently, depending on their characteristics, e.g. wired versus wireless links. TCP does not provide us with this functionality as it acts in a global scope, not allowing any further configuration. Taking action in the data link layer and hiding the problem from the transport layer points to the radical idea of explicitly recognizing in its structure that the Internet is a network of networks and points to an architecture of layers that perform the same functions over different scopes. For example, a layer could manage a wired network, another layer could manage a wireless network, and a layer on top of them managing the end to end inter-network.

Mobility and Hand-offs

As a user moves away from the Access Point (AP) that attaches him to the network, the link quality drops gradually, but with luck another AP is getting closer and can attach to it. Mobility over heterogeneous networks involves handoffs, as usually the last part of the path before the users terminal is a wireless link. The whole hand-off procedure can be divided in phases: a) discovery, b) selection, b) de-attachment, c) authentication (if required), d) re-attachment. Whether the de-attachment phase precedes or follows the re-attachment to the new AP is a matter of policy or availability. In the case that the de-attachment follows the re-attachment, the mobile node will be multi-homed by two APs for a period of time.

There are two kinds of hand-offs, horizontal and vertical. In an horizontal hand-off, the mobile terminal performs a switch between two wireless APs that belong to the same technology. In a vertical hand-off, APs of different technologies are involved. The switch from one Point of Attachment (PoA) to another might happen while transferring data to another node of the network. The challenge is to allow the user to roam freely between different networks without interruptions or degradation of performance due to hand-offs. The current Internet architecture does not provide a way to address mobility that involves vertical hand-offs. The problem originates from the choice to provide names only for PoAs (IP addresses) and not for the nodes in the naming schema. If the new AP, to which the mobile node attaches, belongs to the same domain with the previous AP, the same IP address may be used. But if the APs belong to different domains (usually the case in vertical hand-offs), the mobile node will be assigned a new IP address and the connection will break due to the infamous TCP pseudo header, which contains the source and the destination IP addresses. The inevitable change of IP address means loss of the nodes identity. Another problem is that during a switch from a fast network to a slow network (and vice versa), the TCP sender does not have a fast way to adapt to the new characteristics of the channel and update accordingly parameters such as the transmission rate, the congestion window and the RTO (retransmission timeout) estimate in order to achieve the best utilization of the resources. Adaptation to the parameters takes place slowly, after several round trips, as the transport layer learns the characteristics of the new channel implicitly by probing it.

TCP was not designed with hand-offs in mind nor is it clear that it should have been. Again, several solutions have been proposed to deal with the problems occurring during a hand-off. The Internet Engineering Task Forces (IETF) Mobile IP uses a foreign agent to update the location of the mobile node at its home agent, thus allowing the mobile node to keep its IP address even when moving. When a mobile node leaves its home router and is attached to a foreign router, the foreign router informs the home router of a care-of address (CoA) to which all packets with destination the mobile node should be sent. An IP tunnel is created between the home agent and the foreign agent with a direct connection to the mobile node. When PDUs are sent to the mobile node with the old IP address, they are routed to the home agent. The home agent knows the mobile node has changed its location. The PDUs are encapsulated and sent down the IP tunnel to the foreign network. There the PDUs are forwarded on the CoA address that connects the mobile node to the foreign agent. Mobile IP achieves mobility, although several issues arise from the use of tunnels. IP tunnels are hard to configure, create various security problems and represent single points of failure (if the home or the foreign agent fail, communication is lost). Traffic going through the home agent distorts the RTT estimates. In addition, extra cost and overhead is added due to the necessary location update messages and registration messages to the home agent. Propagation of the new position of the mobile node will increase the delay perceived by the user and during this location update, some packets may get dropped. As TCP cannot be aware that the loses are a consequence of the hand-off, it will handle the dropped packets as loses due to congestion. A decrease in the TCP window will be forced, resulting in a drop in throughput. The sender will have to wait for the retransmission timeout to expire, to be able to send packets again. The probability of packets re-ordering at the destination will increase.

Several modifications and enhancements to the TCP protocol have been proposed [START_REF] Pentikousis | TCP in wired-cum-wireless environments[END_REF][START_REF] Ben-Othman | Performance evaluation of TCP handoffs over mobile IP connections[END_REF] in an attempt to deal with the packet losses and the performance degradation of TCP during a hand-off. One of the ideas is to perform a makebefore-break hand-off [START_REF] Daniel | Adapting TCP for Vertical Handoffs in Wireless Networks[END_REF], in which the connection to the old AP breaks after the connection to the new AP has been established to avoid losses. Another proposal is to make TCP aware of the path change due to a vertical hand-off. This information is signaled to the TCP sender from the lower layers of the stack by setting a new TCP option. After the hand-off the sender sets parameters such as the congestion window, RTO as specified for a new connection. To avoid the long delay caused by waiting for the retransmission timeout to expire, the Fast Retransmit algorithm [START_REF] Caceres | Improving the performance of reliable transport protocols in mobile computing environments[END_REF] has been introduced. A similar proposal is the use of a TCP retransmission trigger option, which notifies the TCP sender to retransmit packets immediately after the connection to the new AP has been established. Another solution relies on the fact that the TCP receiver on the mobile node explicitly notifies the TCP sender that a hand-off has just taken place and thus, the receiver can take appropriate actions. Packet buffering at the base station [START_REF] Eom | Improving TCP handoff performance in Mobile IP based networks[END_REF] is another approach to avoid losses (split-connection protocol, snoop). Again many of the proposed solutions achieve improvement in TCP hand-off performance. However, it seems that once again we miss the root of the problem that needs to be addressed, which is the incomplete naming schema of the current Internet architecture.

3 Recursive Inter-Network Architecture (RINA) over Heterogeneous Networks

Reviewing the proposals made, it is clear that mobility over heterogeneous networks is a very active research area. However, each proposal offers an improvement to one or some of the existing issues but does not address all the problematic points. Several of the solutions work well under specific circumstances and under-perform when the parameters change. None attempts to solve the fundamental problem. As it was already implied, mobility over hybrid environments is incompatible with the current Internet architecture. Trying to stretch the capabilities of the current architecture, does not seem to provide an answer.

In the following sections of the paper we present RINA, a clean-slate network architecture that inherently manages to integrate networks of different physical media.

Main Principles of RINA

RINA is a network architecture proposed by John Day in his book 'Patterns in Network Architecture: A Return to Fundamentals" [START_REF] Day | Patterns in Network Architecture: A Return to Fundamentals[END_REF]. RINA is based on the view that networking is only inter-process communication (IPC). The core element of the architecture is a Distributed IPC Facility (DIF). A DIF is a distributed application that provides IPC for a given range of QoS. Any two application processes6 in different systems are able to communicate using the services provided by a DIF. DIFs of higher levels are able to use the services provided by DIFs of lower levels, forming a recursive structure. A DIF is a layer, but not in the same sense as in the current Internet architecture 7 . In RINA all layers use the same protocols to perform a coordinated set of policy managed functions and achieve the desired IPC service. A detailed description of the RINA model, as well as its features, can be found in [START_REF] Day | Patterns in Network Architecture: A Return to Fundamentals[END_REF][START_REF] Day | Networking is IPC: A Guiding Principle to a Better Internet[END_REF]. In this paper we intend to explore the way RINA deals with transport over heterogeneous networks by examining how mobility and hand-offs are handled.

Hybrid Paths in RINA

RINA provides a recursive architecture formed by different layers stacked one on top of the other. Each layer is self-contained, and operates a complete set of mechanisms to provide data transport services to the client layers, the layers above. These mechanisms include data transport, relaying and multiplexing of data packets, transmission control, flow control, congestion control, authentication and others. A key feature of RINA is that the protocols implementing these mechanisms are the same in each layer, but operate under different configurations (policies) in order to make their operation optimal for certain conditions. The structure provided by RINA perfectly suits the requirements of transport over heterogeneous paths, as with RINA there is no need for mechanisms or algorithms that work well for all types of physical media. Each physical medium has its own dedicated DIF, tailored to the specific medium characteristics. In fact, the configuration of the lower level DIFs aims to match the best way possible the QoS requirements set by the higher level DIFs.

Mobility and Hand-offs in RINA

RINA provides names for applications/nodes rather than interfaces (PoAs). This choice permits routing on the node level and not on the interface level, as in the current Internet architecture and thus, multihoming is supported. In fact, it is provided as a consequence of the structure without the need of any special protocols.

Mobility can be seen as a dynamic version of multihoming with "expected failures". As the mobile node moves, it acquires new points of attachments that connect it to the network. In RINA each new PoA means that the mobile system joins a new DIF. Thus, while moving, the mobile node joins new DIFs and drops its participation in the old ones, a procedure that is equivalent to the attachment and de-attachment to APs during a hand-off. At times, the mobile node might be a member of more than one DIF (multi-homed), which is analogous to a mobile terminal that is in range of several APs and is connected to the network by more than one of them. To better understand how mobility works, a closer look to the naming and addressing schema used in RINA is required. Figure 1 shows an example of the RINA architecture with two levels of DIFs. A DIF maps the source and the destination application names to node addresses (IPC processes) through the directory function. Then, the route from a source application to a destination application is computed as a sequence of (N)-addresses (the blue line in Fig. 1), where the next hop is a node address. Each IPC process knows how to map (N)-addresses to (N-1)-addresses for all nearest neighbors to determine the path to the next hop. Having the addressing schema of RINA in mind, multihoming could now be expressed as an IPC process having more than one (N-1) mapping and mobility as acquiring new (N-1) mappings to use and maybe losing some others. Thus, in any hand-off scenario, vertical or horizontal, indifferent of the technology of the physical media, connecting to a new AP means that an IPC process acquires a new (N-1) binding. For the incoming flows, this new binding is the last binding in the translation of a route to a path connecting a source IPC process to a destination IPC process, while for the outgoing flows is the first binding. The cost for updating this new binding is small, since the update is done locally during the route to path translation. Ishakian et al. [START_REF] Ishakian | On the cost of supporting mobility and multihoming[END_REF] provide further analysis on this cost. Acquiring or dropping (N-1) bindings may modify the graph (topology) at the (N)-layer. These changes are disseminated through routing updates, which will trigger the recalculation of the local forwarding tables of the affected IPC-processes of the N-layer. It is important to note that routing updates carry information about changes in the graph only regarding IPC process addresses ((N)-addresses). The bindings of (N)-addresses to (N-1)-address are a local matter of each IPC process.

An Example of Hand-off in RINA Architecture

In this section, we present a simple hand-off scenario in order to explain how transport over heterogeneous networks is handled in RINA architecture. Our scenario involves a user moving around with a mobile terminal causing hand-offs (Fig. 2). The mobile terminal has two different interfaces active (e.g. Wi-Fi and GPRS). An application process running on the user's terminal has opened a connection with an application process running on a server and data transfer is taking place (e.g. the user is streaming live video). While the connection is open and packets are in transit, the user moves physically, forcing a hand-off from the one AP to the other. In our example this is vertical hand-off, as the first AP is a WLAN router (e.g. Wi-Fi) and the second AP is a router of some technology belonging to the Long Term Evolution (LTE) standard (e.g. GPRS, WiMAX).

Having both APs connected to the same router that the server is connected to is unlike to happen in reality, but we are pointing to a simplified scenario that can be easily pictured and understood by the reader. However, this choice does not spoil the generality, since the number of the possible intermediates does not affect the way mobility and hand-offs are treated in RINA.

Figure 2 depicts the case in which the user is in the range only of the Wi-Fi and the terminal is attached to the network through the first AP. In the lower part of figure we can see the RINA architecture for this case. We illustrate as "source" the system of the server that shares content to the mobile user and as "destination" the system of the mobile terminal. "Intermediate" is an intermediate router that connects through a wired link the server from the one side and the two APs (WLAN and LTE routers) from the other. The oval shapes are the IPC application processes residing in each system. In different colors and numbered from 1 to 7 are the DIFs formed, which are the layers of the RINA architecture. The DIFs numbered 1 -6 are lower level DIFs (0-level or 0-DIFs), while the larger DIF, numbered 7, is an upper level DIF (1-level or 1-DIF).

We can see that the whole architecture involves only application processes that communicate with each other (IPC). Although it is possible to have multiple layers of DIFs to achieve further configuration through policies, in our example we have chosen to describe a 2layer RINA architecture for simplicity. The reader should keep in mind that a 0level DIF for each media AP with a 1-level DIF for networks of a given type, i.e. technology dependent and a 2-level DIF for the technology independent service would be the norm.

The letter in each IPC process denotes its address. Every IPC process has a forwarding table with entries that map addresses of IPC processes to lower level DIFs, so that an IPC process knows where to forward an incoming PDU with a specific destination address. At the lower parts of the 0-DIFs we can see the physical links. The wireless links are denoted with dotted lines, while the wired ones are with continuous lines. As we can see in Fig. 2, 0-level DIFs are sitting on top of every physical link, wired or wireless. These 0-level DIFs allow to perform different configurations through policies analogous to the characteristics of each medium. In this way the 0-level DIFs, although configuring different kind of media, provide the 1-level DIF service with certain properties (e.g. loss, delay), so that, transport at the N-DIF can operate more effectively. The 1-DIF can be seen as an "overlay" to which the source, the intermediate router, the Wi-Fi router, the LTE router and the destination have subscribed and it can be used by the applications of the source and the destination systems to request IPC services. The DIF numbered 4, which consists only of one IPC process, denotes that a second interface is operative in the user's mobile terminal but without a connection to an AP.

The upper DIF maps the source and destination application process names (applications running on the server and the mobile terminal respectively) to IPC process addresses (A and E). For the data transfer between the server and the mobile terminal, the route from A to E is computed as a sequence of intermediate addresses of the 1-level DIF (A, B, D, E). Using its forwarding table, each IPC process has mappings of (N)-DIF addresses to DIFs of the (N-1)-layer, in order to determine the next hop. For example, for a PDU to reach to destination IPC process E, A will forward it to DIF 1, B to DIF 2, etc.

The next figure (Fig. 3) illustrates the changes that happen when the user enters in the range of the second AP and connects to it through an other interface of his terminal. At this moment the mobile node is multi-homed, having the two interfaces on his terminal connected to the two different APs. The IPC processes P and N form a new DIF numbered 4, which is configured according to the characteristics of the wireless link connecting the LTE router and the mobile terminal. A new binding that points to the 0-DIF is added to the forwarding table of IPC process E. This new binding causes changes to the topology of the 1-layer, since the IPC processes A, B and D are now reachable from E through C. These changes are disseminated using routing updates, which trigger re-calculation of the forwarding tables in each IPC process of the 1-layer (DIF 7). Fig. 3 shows the entries of the forwarding tables after the end of this re-calculation process.

Figure 4 describes what happens when the user moves out of the range of the first AP, but remains connected to the second one, completing the hand-off process. The IPC process M departs from DIF 3 and the (N-1)-binding between the processes E and M is dropped. This removal will cause changes to the graph of the 1-DIF, which will be advertised to the rest 1-layer processes through routing updates. In turn, re-calculations of the forwarding tables will take effect to reflect the current bindings.

Conclusions, On-going and Future Work

Despite all the work carried out in many years, transport over heterogeneous networks is still a challenge today. In this paper we indicated that the architectural choices in the current Internet architecture lie at the root of the problem. Specifically, we observed two flaws: The first one is that the current Internet architecture does not recognize that it is operating over more than one network. Although, the network and transport layers operate on top of networks with very different characteristics, the functions they provide apply on a global scope. Trying to perform the same function over different physical networks will always lead to inefficiencies, as it allows for a single configuration, which makes it impossible to adapt to the specific requirements each network imposes. A structure that allows different instances of the same functions to operate independently over different scopes will provide a better framework to achieve transport over hybrid networks. The second flaw we noted is that the current Internet architecture has an incomplete naming and addressing schema, which makes mobility hard, expensive and inefficient. An architecture that provides different names for its basic entities (nodes, PoAs and applications) supports mobility and multi-homing inherently. Following the above observations, we presented RINA, a Recursive Inter-Network Architecture that provides the two features missing from the current architecture, along with many more (support for QoS, multicast, enhanced security). Adopting RINA as the architecture for future networks would make it much easier to support transport over heterogeneous networks.

Currently we are developing a prototype that implements the RINA. Future work includes experimentation with the developed prototype over networks of different physical media and further research, measurements and performance comparisons of RINA versus the current Internet architecture.

Fig. 1 .

 1 Fig. 1. Translating a route to a path in RINA naming and addressing schema.

Fig. 2 .

 2 Fig. 2. The mobile terminal is connected to the first AP.

Fig. 3 .

 3 Fig. 3. As the user moves, gets in the range of the second AP and connects to it through the second interface on his terminal (multi-homing).

Fig. 4 .

 4 Fig. 4. The user gets out of the range of the first AP and remains connected only through the second one.

  Applications that use the transport services provided by DIFs still can have end-to-end mechanisms, such as end-to-end error, flow, and congestion control, as they typically use a DIF that is sitting on top of multiple lower level DIFs, which in turn operate on top of different physical media. Examples of this recursive structure are illustrated in Fig(s). 2, 3 and 4.

For clarity, we refer to application processes that are members of a DIF as IPC Processes and users of a DIF as application processes or simply applications.

To compare to the Internet, (MAC, LLC) are one layer; Network and Transport are one layer. They are complete units of IPC.


Xiang Teng

Lei Qin

Roland Le Borgne

Yusuke Toyama

Remodeling of adhesion and modulation of mechanical tensile forces during apoptosis in Drosophila epithelium

Apoptosis is a mechanism of eliminating damaged or unnecessary cells during development and tissue homeostasis. During apoptosis within a tissue, the adhesions between dying and neighboring non-dying cells need to be remodeled so that the apoptotic cell is expelled. In parallel, the contraction of actomyosin cables formed in apoptotic and neighboring cells drive cell extrusion. To date, the coordination between the dynamics of cell adhesion and the progressive changes in tissue tension around an apoptotic cell is not fully understood. Live imaging of histoblast expansion, which is a coordinated tissue replacement process during Drosophila metamorphosis, shows remodeling of adherens junctions (AJs) between apoptotic and non-dying cells, with a reduction in the levels of AJ components, including E-cadherin. Concurrently, surrounding tissue tension is transiently released. Contraction of a supra-cellular actomyosin cable, which forms in neighboring cells, brings neighboring cells together and further reshapes tissue tension toward the completion of extrusion. We propose a model according which modulation of tissue tension represents a mechanism of apoptotic cell extrusion, and would further influence biochemical signals of neighboring non-apoptotic cells.

Introduction

Throughout development and adult life, epithelia undergo constant growth and turnover.

As a cell population changes, epithelial architecture needs to be maintained and this is done through the tight intercellular adhesions supported by adherens junctions (AJs) [START_REF] Harris | Adherens junctions: from molecules to morphogenesis[END_REF][START_REF] Takeichi | Dynamic contacts: rearranging adherens junctions to drive epithelial remodelling[END_REF][START_REF] Lecuit | E-cadherin junctions as active mechanical integrators in tissue dynamics[END_REF]. Apoptosis, or programmed cell death, is the most common mechanism of eliminating damaged or unnecessary cells during embryonic development, and tissue homeostasis [START_REF] Jacobson | Programmed cell death in animal development[END_REF]. When cells within a tissue undergo apoptosis, the adhesions between the dying and neighboring non-dying cells need to be remodeled. This ensures the apoptotic cell can be expelled from a tissue without compromising tissue cohesion. The loss of adhesions in the apoptotic process has been studied, with a focus on the disruption of cell-cell junctions associated with caspase activation. Members of the caspase family serve as the key executors of apoptosis [START_REF] Riedl | Molecular mechanisms of caspase regulation during apoptosis[END_REF]Shi, 2004, Miura, 2012). For instance, AJ components, such as E-cadherin (E-cad) and -catenin ( -cat) are known substrates of caspase-3 in mammalian cells [START_REF] Bannerman | Bacterial Lipopolysaccharide Disrupts Endothelial Monolayer Integrity and Survival Signaling Events through Caspase Cleavage of Adherens Junction Proteins[END_REF][START_REF] Brancolini | Dismantling Cell-Cell Contacts during Apoptosis Is Coupled to a Caspase-dependent Proteolytic Cleavage of β-Catenin[END_REF]. In Drosophila the reduction in the levels of E-cad from AJs is associated with the cleavage of the -cat homolog Armadillo by the Drosophila effector caspase DrICE [START_REF] Kessler | Cleavage of Armadillo/beta-catenin by the caspase DrICE in Drosophila apoptotic epithelial cells[END_REF].

Along with AJ remodeling, the process of cell extrusion is also crucial in the expulsion of dying cells from a tissue. In tissue culture, apoptotic cells autonomously develop an actomyosin cable, and the neighboring non-apoptotic cells also form a supra-cellular actomyosin purse-string [START_REF] Rosenblatt | An epithelial cell destined for apoptosis signals its neighbors to extrude it by an actin-and myosin-dependent mechanism[END_REF][START_REF] Kuipers | Epithelial repair is a two-stage process driven first by dying cells and then by their neighbours[END_REF].

Development LEC extrusion (Fig. 1c), and the degree of elongation decayed as a function of the distance from the extruding cell (Fig. S1a). These observations indicated that the mechanical impact of apoptotic cell extrusion was not restricted to the nearest-neighbor histoblast, but propagated to the next-to-nearest-neighbor cells. The elongated histoblasts (Fig. 1b) underwent either cell division or cell-cell junction remodeling after cell extrusion had completed, and did not maintain their elongated shape (Fig. S2).

These rearrangements, however, had no impact on tissue expansion, with the edge of the histoblasts remaining in place after cell extrusion was complete (Fig. S2). This suggests that the mechanical impact of boundary LEC apoptosis on tissue expansion is preserved even after the completion of LEC extrusion. Compared to the control boundaries, the initial recoil velocity after ablation (Materials and Methods), which is the first good approximation of the junctional tension right before ablation, decreased immediately after E-cad levels reduced. (Fig. 8e). Moreover, the recoil velocity increased to an even higher level at the later stages of apoptosis, compared to that of the control boundaries (Fig. 8e). The cell boundaries of neighboring LECs showed the same trend (Fig. S16). Altogether, our results show that tissue tension is transiently released upon the reduction of E-Cad and is re-shaped during the late stages of cell extrusion.

To further examine the kinematics of extruding

Development • Advance article

We report here, the temporal sequence of events during apoptotic cell extrusion, with a focus on the remodeling of AJs, the cytoskeleton, and mechanical tension. After caspase-3 starts to be activated in LECs, those undergoing apoptosis initiate apical constriction (Fig. 2). We reasoned that the initiation of this constriction could be due to a combination of actomyosin cable formation in the dying cell (Fig. 4)

Development • Supplementary information

Cell shape anisotropy analysis

To measure the anisotropy of individual histoblast cell (Fig. 1c and Fig. S1), the zprojected E-cad::GFP time-lapse images were first segmented by Packing Analyzer V2.0 (Aigouy et al., 2010). The cell boundary data were subsequently analyzed with Matlab software (MathWorks, MA, USA). Segmented cell shapes were fitted by ellipse, which was optimized by maximizing the area overlap between a segmented cell shape and an ellipse. Anisotropy of the cell was defined as the ratio of minor and major axes of the fitting ellipse.

Caspase-3 activity analysis

To monitor caspase-3 activity (Fig. 2a and Movie 5), fly with FRET base caspase-3 sensor, SCAT3 (Nakajima et al., 2011, Takemoto et al., 2003) was used. A 405nm laser was used to excite ECFP and two fluorescence images (ECFP and Venus) were simultaneously captured. FRET ratio was calculated by taking the intensity ratio between the sum-intensity z-projected ECFP and Venus images. FRET ratio of an apoptotic LEC (Fig. 2c) was measured by averaging the FRET ratio within an apoptotic cell. The shape of an apoptotic cell was manually segmented from the sumintensity z-projected Venus images over time by using ImageJ [START_REF] Schneider | NIH Image to ImageJ: 25 years of image analysis[END_REF].

Determination of the transition time

To measure the time delay between the beginning of apical constriction and caspase-3 activation (Fig. 2c), we first normalized the cell area and caspase-3 activity data to the value measured at time = 0 sec (Fig. S3a). The area data was shifted in time to minimize the difference between area and caspase-3 data (Fig. S3b). The shift was defined as ∆tshift.

To determine when the cell started to constrict with higher speed (τarea) and when the cell started to activate its Cas-3 activity (τCas3) without comparing the two graphs, we referred to the maximum derivative of each graphs. We defined τarea as the time when the derivative of the graph reached to 25% of the maximum slope (Fig. S3c). Similarly, we defined τCas3. The time delay between the initiation of apical constriction and caspase-3 activation measured by 25% of maximum slope, ∆t25% = |τarea -τCas3|, was consistent to ∆tshift (Fig. S3d). With the other values, e.g., numbers between 10% and 40%, |τarea -τCas3| was not as close to ∆tshift as 25%.

Same setting (25% of the maximum slope) was used to define the transition time not only for τarea and τCas3, but also for all the other data, for instance τEcadKI, τouter_MyoII and τinner_MyoII.

MyoII intensity analysis

To quantify the progression of MyoII accumulation in apoptotic LECs or neighboring cells, the average fluorescent intensity of MyoII::GFP signal either from histoblast that originally attached to apoptotic LEC (Fig. 4a') or solely originated from the cell periphery of apoptotic LECs (Fig. 4c') were measured. Images of sumintensity z-projection (around AJ) of MyoII::GFP were analyzed over time. ROIs (see main text for more detail) to calculate the intensity were manually defined by the free-hand line tools of ImageJ. The total intensity along the line with thickness of 4 pixels (0.24 µm/pixel) was measured and divided by the length of the line.

Development • Supplementary information

Cell boundary linearity measurement Linearity of the histoblast cell boundaries was calculated as a ratio of the two ends of boundary (measured by using ImageJ Straight Line tool) to the actual length of the histoblast cell boundary (measured by using ImageJ Segmented Line tool). A linearity value 1 represents a straight line.

Calculation of initial recoil velocity after ablation

The length of ablated cell boundary was measured overtime by using ImageJ Straight Line tool. Data points before the cut were fit with linear line. An exponential was used to fit the data after the cut. The effective time of the cut was found as the intersection of the linear line with the exponential. The initial recoil velocity was found from the deliberative of the exponential at effective time of the cut. The velocity was calculated in Matlab. More detail can be found in (Hara et al., 2016).

Quantitative analyses of the deformation in the shape of extruding LECs

To quantify the local/isotropic deformation of extruding LEC, as shown in Fig. 1e (before τarea) and 1e' (after τarea), we first measured the differences in cell shapes at two different time points (Fig. S4a). Before τarea, the differences in cell shapes at [τarea-25] min and τarea min was shown as gray area in Fig. S4a (left). The centoid of this gray area (residual area) and the cell area at τarea (white area) were shown as a red and black cross, respectively. We then defined the black cross as the origin of the new coordinate system. We further rotated the coordinate so that y-axis represented the direction toward histoblast. After τarea, the differences in cell shapes at τarea min and [τarea+25] min was shown as gray area in Fig. S4a (right). The centoid of this gray area (residual area) and the cell area at [τarea+25] (white area) were shown as a blue and black cross, respectively. Finally, we analyzed 6 cells before and after τarea, and summarized all data in a same graph (Fig. S4b).

Statistics

All the p values are calculated using a student t-test: p < 0.05, significantly different; p > 0.05, not significantly different.

Development • Supplementary information

  dynamics and the cytoskeleton, and in turn, progressive changes in tissue tension around the apoptotic cell. The mechanisms resulting from this interplay remain to be fully understood. We elected to study tissue replacement during histoblast expansion in Drosophila. At the onset of pupal development, the quiescent abdominal histoblasts (precursors of the adult epidermal cells) are grouped in nests embedded amongst larval epidermal cells (LECs) (Fig. 1a, Movie 1). As metamorphosis progresses, histoblasts exhibit rapid proliferation and active migration, leading to the growth and expansion of the nests (Ninov et al., 2007, Ninov et al., 2010). Concurrently, pre-existing LECs undergo caspase-3 mediated apoptosis (Nakajima et al., 2011). The majority of the apoptotic cells in Drosophila, including LECs, extrude basally. This is observed in, 2012). This is intriguingly contrary to apical cell extrusion in most vertebrates (Rosenblatt et al., 2001, Eisenhoffer et al., 2012, Yamaguchi et al., 2011). Around 80% Development • Advance article of LECs undergo apoptosis in proximity to histoblast nests (hereafter referred to as 'boundary' LECs) and ~20% of LECs die away from the nests (hereafter referred to as 'non-boundary' LECs) (Ninov et al., 2007, Bischoff and Cseresnyes, 2009, Nakajima et al., 2011). Although the proliferation of histoblasts is known to contribute to histoblast expansion (Ninov et al., 2007, Ninov et al., 2010), it was not clear whether the mechanics of LEC apoptosis also contributes to the expansion (Ninov et al., 2007, Bischoff and Cseresnyes, 2009). In this study, we reveal that during the extrusion of apoptotic LECs, AJs between apoptotic and neighboring cells become remodeled, and this is associated with a reduction in the levels of AJ components. Furthermore, this correlates with a transient release of tissue tension. Towards the end of the extrusion process, neighboring cells are brought together by the formation and contraction of a supra-cellular actomyosin cables within the neighboring cells. This further restores tissue tension. We conclude that adhesion remodeling and changes in tissue tension are mechanically coordinated, and this represents a mechanism of apoptotic cell extrusion. Furthermore, we reveal that the extrusion process of death-committed LECs is able to mechanically drive histoblast expansion. Results Apoptotic cell extrusion coincides with neighboring cell deformation To explore the effects of extrusion of apoptotic LECs on histoblast expansion, we Development • Advance article collected confocal images of the surface of wild-type pupae expressing a DE-cad:dotted line in Fig. 1b). The next-to-nearest-neighbor histoblasts also elongated (white and magenta dotted lines in Fig. 1b). With time, the space originally occupied by the apoptotic LECs was covered by neighboring cells. To quantify histoblast deformation upon boundary LEC extrusion, we monitored cell elongation by measuring the anisotropy of cell shape (Materials and Methods, Fig. 1c, Movie 4). Analyzing the anisotropy revealed that histoblast elongation correlated with

  Fig.1e). We speculate that the local deformation, before area , was due to compressive

Fig. 2 .(Fig. 6 .Fig. 8 .

 268 Figures

Fig. S4 .

 S4 Fig. S4. Quantitative analyses of the deformation in the shape of extruding LECs. (a) Two contour plots showing the cell shape of different time points (25 min apart) for before (left) and after (right) τarea. Black cross denotes the centroid of the cell area at later time point (white in the figure). Red and blue crosses denote the centroid of residual area (difrence between two contour plots, gray in the figure) at before and after τarea, respectively. (b) Summary of 6 data. Open circles and error bars represent the average values and the STDEV, respectively. ***: p<0.001.

Fig. S6 .

 S6 Fig. S6. Mechanical impact of non-boundary LEC apoptosis. (a) Confocal fluorescence images of wild type pupa expressing DE-cad::GFP. Non-boundary LEC (i.e., one LEC away from histoblast) is highlighted by filled circles. Scale bars, 50 μm. (b) Color-enhanced reproduction of the confocal images from (a). Colors demote the anisotropy of the cell shape: The darker color represent more elongated histoblast cells (same as Fig. 1c). The color of the histoblasts did not change as much as the case of boundary LEC. Scale bar, 20 μm.

Fig. S7 .

 S7 Fig. S7. Actin distribution around the periphery of apoptotic LEC shows two actin cable-like structures. Confocal fluorescence images of wild type pupa expressing Moesin::GFP. Apoptotic LECs are highlighted by filled circles. Arrow and arrowhead show the actin accumulation in the apoptotic LEC and the neighboring non-apoptotic LECs, respectively. Scale bar, 20 μm.

Fig. S8 .

 S8 Fig. S8. Formation of de novo AJs between the non-apoptotic neighboring cells. Confocal fluorescence images of wild type pupae expressing DE-cad::GFP and MyoII::mCherry. Two pairs of neighboring cells (filled and open circles) form de novo AJs before the completion of apoptotic cell extrusion (arrows and doublearrows). Scale bar, 10 μm.

Fig. S9 .

 S9 Fig. S9. Reduction of the level of AJ components during apoptosis. (a) Time delays of the reduction of AJ components (τEcad_red, τ α-cat_red , τ β-cat_red , and τEcadα-cat_red ) using area transition τarea as a reference (*: P < 0.05, n.s.: Not significant). n=13, 9, 12, and 7 for τEcad_red, τ α-cat_red , τ β-cat_red , and τEcadα-cat_red , respectively. Average values are shown as thick horizontal lines. (b and c) Confocal fluorescence images of wild type pupa expressing Dβ-cat::YFP and MyoII::mCherry (b, Movie 7) or pupa expressing αcat::RFP only in LECs and MyoII::GFP ubiquitously (c, Movie 8). (d) Confocal fluorescence images of pupa expressing GFP tagged fusion protein that the C-terminal domain of E-cad was replaced by an α-cat protein lacking the N-terminal domain (DEcad-α-cat::GFP). Apoptotic LECs are highlighted by filled circles. Arrowheads shows the dissociation of fluorescence signal. Arrows and double arrows denote the myosin in the apoptotic LEC and the neighboring cells, respectively. Scale bars, 20 μm. Development • Supplementary information

Fig. S10 .

 S10 Fig. S10. AJ disengagement upon apoptosis. Confocal fluorescence images of wild type pupa expressing the plasma membrane markers PH::GFP in LECs, and MyoII::mCherry ubiquitously, highlighting the plasma membranes of apoptotic (arrow) and neighboring (double arrows) cells detach once the separation of the two myosin cables become apparent. Same data as shown in Fig. 3g. Scale bar, 20 μm.

Fig. S11 .

 S11 Fig. S11. AJ non-disengagement upon apoptosis. (a-c) Confocal fluorescence images of wild type pupa expressing the plasma membrane markers PH::GFP only in the histoblasts, and MyoII::mCherry ubiquitously. (d) High magnification of the dotted region depicted in (c), highlighting the myosin cable in the apoptotic cell (arrow) and the edge of the histoblast membrane are closely juxtaposed each other. Moreover, the myosin cable in the neighboring cells (double arrowheads) is away from the membrane. Scale bar, 20 μm.

Fig. S16 .

 S16 Fig. S16. Tissue tension release and reshape after reduction of E-cad levels in LECs. (a-c) Confocal fluorescence images of wild-type pupa expressing DE-cad::GFP KI and MyoII::mCherry ubiquitously highlighting the LEC boundaries connected to the apoptotic LEC before ablation. (a'-c') Kymographs generated from the white boxed regions in a-c, showing the dynamics of the cell boundaries after ablation. The ablations were performed in three different stages of apoptotic cell extrusion: before reduction of E-cad levels (a and a'); right after reduction (b and b'); and during neighboring actomyosin cable (double-arrow in c) contraction (c and c'). Scale bar, 10 μm. Statistical comparison of the recoil velocities (d) and the length of cell boundary at laser ablation (e) at each stage of cell extrusion shown in a-c. n=16, 11 and 13 for control, after reduction, and, during cable contraction, respectively. Error bars indicate SEM. *: P < 0.05, ***: P < 0.001, n.s.: no significance.

Fig. S17 .

 S17 Fig. S17. A model of the progressive remodeling of AJ and tissue tension during apoptosis. Cartoons show the progression of apoptotic events with the top view at the AJ. Cell size and shape are not scale. (a) Caspase activation (set this time as t=0min). (b) Beginning of apical constriction and MyoII accumulation (orange dotted line) in the apoptotic cell (t=20min). The contraction of the actomyosin cable pulls the neighboring cells through the AJ (black arrows). (c) AJ disengagement (black dotted lines) and tension release (t=50min). (d) MyoII accumulation in neighboring nonapoptotic cells (red dotted lines). Contraction of supra-cellular actomyosin cables reshape the tissue tension (black arrows) (t=50-70min). (e) End of apical constriction. The propagation of mechanical force promotes tissue dynamics (black arrows) (t=70min).

Movie 2. Time-lapse images of wild-type pupa expressing ubi-DE-cad::GFP. Scale bar, 20

Acknowledgements

We acknowledge the following for the generous gift of flies: M.Affolter, H.Hong, D.P.Kiehart, E.Kuranaga, T.Lecuit, A.C.Martin, M.Miura, K.Sugimura, Bloomington Stock Center, Kyoto Drosophila Genetic Resource Center, and Vienna Drosophila RNAi Center. We thank Microscopy Core of MBI, Bioimaging and Biocomputing Facility of TLL, and Microscopy Rennes Imaging Center. We also thank E.Kuranaga, B.Ladoux, E.Martın-Blanco, M.Sheetz, M.Sudol, K.Sugimura, and MBI Science Development • Advance article Communication Core (S.Wolf) for helpful discussions and critical reading of the manuscript.

Funding

This work was supported by an NUS Research Scholarship (to X.T.), Mechanobiology Institute and National University of Singapore Startup Grants (to Y.T.), Temasek Life Sciences Laboratory (to Y.T.), and a Singapore Ministry of Education Tier 2 grant (MOE2015-T2-1-116 to Y.T.). R.L.B. and Y.T. thank the support by the PHC Merlion Programme n° 5.14.13 of the Institut Français de Singapour, under administrative supervision of the French Ministry of Foreign Affairs, and the National University of Singapore.

Competing interests

The authors declare no competing or financial interests.

Development • Supplementary information

Supplemental Experimental Procedures

Drosophila stocks and Genetics

Otherwise stated, fly stocks were obtained from the Bloomington Stock Center. The following lines were used: ubi-E-cad::GFP (H. Oda), Nrg::GFP (Kyoto Stock Center), moe::GFP (D. Kiehart), ubi-E-cad::GFP; sqh-Sqh-mCherry (A.C. Martin), Armadillo::YFP , and Knock-in alleles of DE-cad::GFP and DE-cad::mTomato (Huang et al., 2009). The following UAS and GAL4 were used to ectopically express the gene of interest: UASsqh::GFP (M. Affolter), UAS-α-catenin::RFP (K. Sugimura), UAS-sqh-RNAi (VDRC), UAS-SCAT3 (M. Miura), UAS-p35, Esg-GAL4, Eip71CD-GAL4, and tsh-GAL4. Live imaging of E-cad and caspase-3 sensor SCAT3 was carried out by crossing tsh-GAL4, UAS-SCAT3/CyO (M. Miura) with DE-cad::mTomato (Huang et al., 2009). sqh-RNAi MARCM clones that were positively marked by the double copy of histone-RFP expression were recovered from neoFRT19A, tubP-Gal80, hsFLP; UAS-sqh-RNAi (male), and neoFRT19A, ubi-mRFP.nls; ubi-E-cad::GFP, Eip71CD-GAL4 (female). Mitotic clones were induced using the FLP-FRT technique by using the hs-FLP with heat shock for 50 min at 37°C in early embryos. The genotypes of three cells analyzed in Fig. 7b are, neoFRT19A, tubP-Gal80, hsFLP/neoFRT19A, ubi-mRFP.nls; UAS-sqh-RNAi/ DE-cad::GFP-KI, Eip71CD-GAL4; +/+ (LECWT/WT), neoFRT19A, tubP-Gal80, hsFLP/neoFRT19A, tubP-Gal80, hsFLP; UAS-sqh-RNAi/ DE-cad::GFP-KI, Eip71CD-GAL4; +/+ (LECWT/RNAi), and neoFRT19A, ubi-mRFP.nls/neoFRT19A, ubi-mRFP.nls; UAS-sqh-RNAi/ DE-cad::GFP-KI, Eip71CD-GAL4; +/+ (LECRNAi).

Sample preparation and Live Imaging

Staged pupae were collected, dissected, mounted and imaged as previously described (Ninov and Martin-Blanco, 2007). Z-stack images were captured every 1.6 µm along the apical-basal axis of the tissue at 5-minute intervals (except Fig. 3d

Immunohistochemistry

Pupae were staged as described in (Ninov and Martin-Blanco, 2007), dissected and fixed following protocols described in [START_REF] Wang | Drosophila pupal abdomen immunohistochemistry[END_REF]. DNA was stained with 4',6-diamidino-2-phenylindole (DAPI). Primary antibody anti-pMLC (Cell Signaling, #3671) was used with concentration 1/50. Secondary antibody conjugated with Alexa 546 (Life Technologies) was used.

Laser ablation

Laser ablation at histoblast was performed using a Leica TCS SP5 multi-photon confocal microscope with a 63×/1.4-0.6 HCX PL Apo objective. Ablation was carried out at the AJ plane with a multi-photon laser (Mai-Tai HP from Spectra Physics, CA, USA) set to 800 nm, with a laser power of 40% out of 2.8 Watt maximum output. Laser ablation of LECs was performed using a femtosecond laser (FP1030 from fianium, UK) interfaced to the Nikon A1R MP confocal microscope. A laser power was set to 140 mW at back aperture of the objective. More detail can be found in (Hara et al., 2016).

Development • Supplementary information

Supplemental Movies

Development • Supplementary information

Development • Supplementary information