Aspects of Multi-Homing in IP Access Networks

Transcription

1 Aspects of Multi-Homing in IP Access Networks Andrej Mihailovic 1, Tapio Suihko 2, Mark West 3 1 Centre for Telecommunications Research, King s College London, andrej.mihailovic@kcl.ac.uk 2 Nokia / VTT Information Technology, tapio.suihko@vtt.fi 3 Siemens / Roke Manor Research Ltd., mark.a.west@roke.co.uk ABSTRACT This paper presents some results of work in multihoming conducted as part of the MIND [1] project. It contains an overview of the concepts of multi-homing in relevant Internet research as well as the steps used for developing an original perspective on the problem. The uniqueness of the problem is argued to arise from the originality of connectivity scenarios in IP access networks, such as the network developed in BRAIN [2] called BRAIN Access Network, and the new wireless self-configurable and ad-hoc elements of the access network architecture designed in MIND. We examine deployment and serviceenhancement aspects of multi-homing for both the access network and the attaching terminal, and their interrelations. I. INTRODUCTION Initially our work was centred on creating a common understanding of the concepts of multi-homing due to the extensive and sometimes subjective consideration of the topic. This approach is clearly justified considering the presence of two distinct approaches to the problem, site and host multi-homing can sometimes refer to completely different sides of the problem. Hence, the practical application of multi-homing needs to be preceded by a careful interpretation of the available definitions and solutions, as well as provisioning a platform for creating an original interpretation of the problem. There are two basic approaches in defining the concept of multi-homing: Host multi-homing [3]: Starting from the IPv4 perspective, the basic definition states that a host is multi-homed if it has two or more interfaces with a different IP address associated with each. A slightly more modern definition states that a host may have more than one IP address associated with one physical interface, thus having more logical interfaces (or address aliases). These addresses can differ in the host part or completely (including the network prefix) provided the network is configured to support two or more IP subnets (logical networks) on the same link. Additionally, IPv6 introduces mechanisms that natively support using multiple addresses and prefixes. The common and arguably most important problem to both versions of IP is the source address selection for outgoing packets of multi-homed hosts [6] (interface selection is considered as important but can sometimes coincide with address selection). Site multi-homing of the IETF multi6 working group [4] [5]: In this case the emphasis is placed on a site (enterprise) and manipulating its connectivity with its transit providers (i.e. Internet Service Providers - s). The essential model for achieving multi-homing in the multi approach [7][8][9][10][11][12][13] is to provide intelligent control of the traffic between the s that the site is connected to. We note that the focus of the multi6 work is on multi-homed sites, but that supporting this inevitably requires some involvement of IP hosts. Additionally there is parallel work on achieving maintenance of transport layer sessions by breaking the requirement for a single address as a session identifier [16]. II. THE CONTEXT OF MULTI-HOMING IN MIND/BRAIN Characterising the specific requirements for multihoming in MIND (and BRAIN) networks is the initial consideration when developing appropriate solutions. The reference network architecture of the BRAIN access network and MIND network extensions is displayed in Figure 1. The four main objectives of using multihoming in MIND networks are to: a) overcome the weakest links in the chain, b) increase bandwidth and flexibility, c) balance the load inside the access network, d) achieve redundancy over the backbone. The weakest links of a connection in a MIND and BRAIN access networks are usually the air interfaces that a terminal (i.e. Mobile Node ) uses to access the network. A particular feature of MIND network is the ad-hoc mesh network of terminals, which use the ad-hoc network to access the fixed infrastructure and/or provide such access for their neighbour [1]. Thus in such environments the weakest link is also the dynamic connections between neighbouring terminals (Mobile Routers MRs as far as ad-hoc routing is concerned, also functioning as s for the access network) inside the ad-hoc part. To overcome these weaknesses, more than one connection via one or more air interface could be established to increase the chance for a reliable overall connection and several paths through the ad-hoc fringe can be used simultaneously.

2 Many times the requirements on downlink and uplink are different, for example a high-bandwidth downlink is needed, but the uplink need only have a low bandwidth. If a terminal is able to use more than one interface to the network (i.e. be multi-homed), the flexibility and bandwidth can be increased. Inside the access network, balancing of the total traffic load is desirable for achieving a more efficient use of network infrastructure. By using more than one path through the access network at the same time, a better utilization of the network can be achieved through dynamic capacity management. Some specific requirement for multi-homing in MIND network are summarised in the following subsection. ANG Default wired BRAIN Access network = Global Internet Fixed/Mobile Converged IPv6 Core Network Newly formed as seen by MRs Self-organising MIND wireless access network MIND Ad-hoc mesh for enabling connectivity to all MRs (also nesting access network hosts) Figure 1: A MIND network setup A. MIND Requirements for Multi-homing Servers Access Network Router Access Network Wireless Router Support for multi-homing must allow efficient use of the radio resources of multiple access networks and technologies. Multi-homing should have a minimal impact on the access network functionalities. Multi-homing should not be relied upon to resolve issues that can be handled by routing. For example, failure of certain nodes can be managed solely through IP routing or mobility management. Non-MIND networks should not need to change in order to support MIND multi-homing. Flexible load-sharing is an important use of multihoming. This could refer to the use of multiple transitproviders by the. It would also allow for loadsharing between multiple access networks. In both cases, this can apply to both in-bound and out-bound traffic. Redundancy is important to ensure continuity of connectivity in the event of failures. Although some failure can be handled without recourse to multi-homing, air-interface link failure, for example, or transit provider failure can be addressed by multi-homing. Performance can be maintained in the event of failures, but multi-homing can also provide increased performance. Clearly, any solution for multi-homing needs to be scalable. Scalability can be considered with regard to the number of s supported; the number of addresses per ; the number of s; and the number of transit providers. From a security perspective, the goal is that the introduction of multi-homing does not introduce any security issues. There is also a need to support non-multi-homing aware s in MIND. The network should not assume that all terminals can handle multiple points of attachment (clearly a terminal may only have one radio interface, for example). We consider whether supporting multiple addresses for mobility is different (from the perspective of the terminal) from multi-homing. From a user point of view, there may be non-technical reasons for multi-homing, or for making decisions about the use of multi-homing (eg. cost of using a link) The overall solution needs to allow a user to specify policies in a manner that allows multi-homing to work for the user. The scope of what is being covered is also important. The transparency principle established in BRAIN means that the should appear to outside networks like any wired network. Specifically, this means that MIND should not require any additional support from peer networks or correspondent nodes beyond what is necessary for existing IETF multi-homing operation. It may also be worth noting that the cannot expect to exert direct influence on networks (and nodes) that affect multi-homing. Further, we consider the impact that multi-homing may have on various components of MIND architecture and solution. For example, support for the micro-mobility solution where hosts may have multiple addresses. Key issues here include the requirements for address allocation; the impact on handover; extensions to idlemode (paging) support; and the effect of ingress filtering. III. MULTI-HOMING SCENARIOS IN MIND/BRAIN NETWORKS Multi-homing scenarios in MIND highlight different aspects of the multi-homing concept by focussing on specific domains in the network architecture (for example, multi-homing within the, or s having multiple air interfaces). One view of the scenarios could be to regard them as constituents in an evolving series as depicted in Figure 2. In the Figure, the lines between the components denote direct links or any conceivable intermediate routing infrastructure (e.g., a mesh of intermediate mobile ad hoc network terminals between the and the ). The following cases of multi-homing can be recognised:

3 Scenario 1 +Scenario 2 +Scenario 3 +Scenario 4 Scenario 1: a with a single air interface acquires multiple addresses from a single-homed, Scenario 2: a with single air interface acquires multiple addresses from a multi-homed, Scenario 3: a with multiple air interfaces acquires address(es) from a multi-homed, Scenario 4: a with one or more air interfaces accesses multiple networks and acquires one or more addresses from the networks. In the following, we investigate the issues related to the multi-homing scenarios. It is obvious that the scenarios share common issues. Therefore, we look into the scenarios in the order of increasing complexity (although, this ordering is quite arbitrary because the concepts of multi-homed site and multi-interfaced terminal are orthogonal). Thus many of the issues of the simpler scenarios can be regarded as being implicitly included in the more complex scenarios. A. Scenario 1 A Non-multi-homed Offering Multiple Addresses to s This scenario does not assume that itself is multihomed. Therefore, the reasons for simultaneously offering multiple addresses to s would typically be related to -internal packet forwarding efficiency or QoS provision (although, similar effects could also be achieved with constraint based routing). A specific example is the case when is initiating new connections via mobility management in the network and is able to choose between the acquired addresses so that data traffic flows through the most optimal part of the network (the would need advice from the to make this decision). Other causes for multiple address assignment could be related to rehoming of the in the sense that the single is (semi-)permanently changed to another, or attaching -internal QoS profiles to distinct addresses. Although infrequent, re-homing events might add an incentive to support auto-configurability of a in order to achieve flexibility and scalability in address prefix allocations. In order to support these characteristics, a must be able to offer multiple addresses to s and should be able to indicate the preferences (and other selection criteria), and lifetimes of the addresses. If needed, a should be able to exercise policy routing based on the used source addresses. Similarly, s should be able to interpret the address preferences, attached QoS expectations, and the urgency for changing to a new Figure 2: A schematic view of multi-homing scenarios address. The change of address would imply reregistration with the global mobility protocol, if any. Despite the above, as concerns radio resource redundancy, the need for establishing additional redundancy mechanisms within an access network is questionable. The micro-mobility protocol of MIND/BRAIN (BCMP [15]) is designed to offer redundancy between access points with a performance that should exceed that of possible alternative mechanisms. B. Scenario 2 A Multi-homed Offering Multiple Addresses to s As already mentioned, site multi-homing solutions (primarily concerned with features in the network) may require interaction between the host and routing system. The benefits of site multi-homing expand on the benefits already identified in Scenario 1. For example, traffic load could now be shared between s and not only within a. This could be achieved or accompanied with load-aware address assignment at the address allocation function in the (although this type of statistical load sharing would be possible without handing out multiple addresses to each ). In addition, expedited forwarding service or other network services could be available at a specific transit or target network. The should then ensure that this service is bi-directionally accessible by taking care that all packets having a certain IP source address prefix exit the through this network. Also, s should become aware of the differences between the offered source addresses. As an example of the side effects that site multi-homing may impose on a, consider ingress filtering at the border between the and a transit network provider () network. If the link to the primary fails the s may need to change the IP source addresses that they use in order to be able to get packets through a secondary (if ingress filtering is performed by the secondary ). The need for such a change has to be signalled to the s somehow. This could be achieved by using an ICMP error message or a kind of reregistration request from the. The latter could allow proactive warning of address deprecation but requires that the becomes aware of the situation. This issue falls into a general need for an addresspreference notification to the s (which could also be used to suggest to change an anchor point, for example).

4 It is interesting to note that with the introduction of the Home Address destination option, Mobile IPv6 tackles the same ingress filtering problem that we have here. Therefore, Mobile IP mechanisms have been proposed to solve this site multi-homing related issue even for situations where the hosts are not mobile [10]. When applied to access this would mean that a (also Correspondent Nodes - CN) behaves as if one of the acquired (and eventually deprecated) addresses were the s Home Address. That is, the deprecated IP address is still used by the applications for identifying connections (inserted in a Home Address Option), whereas a new IP address is transparently used as a Mobile IP CoA (i.e. as the source address of packets) C. Scenario 3 A Multi-interfaced Accessing a Single This scenario involves connecting to the same through different routing paths. This can be achieved by using separate interfaces of the and/or by connecting to the through diverse routing paths in the ad-hoc mesh. Typically the interfaces would represent different wireless technologies with distinct packet forwarding characteristics. The diverse --connections may be terminated at the same or at different access routers. From the s point of view, a having simultaneous connections to the would look like multiple hosts as regards address assignment and packet routing but, typically, as a single entity as regards AAA functions. Therefore, the must allow a single authenticated user to efficiently attach at multiple access routers simultaneously. The benefit for the is that it is able to select the most suitable paths for its traffic flows. For this, connection management in the must be provided with enough information for making the policy decisions on interfaces and next hop routers used for new connections. An example could be to always select the cheapest network or the network offering the highest bit rate or lowest delay. There may be other selection criteria related to applications. Additionally, reselection of the routing paths should be possible for the s active connections through session management. In this scenario, intra-domain handovers could be performed at each s interface separately. Additionally, the could hand over transport connections from one interface to another by using global terminal mobility mechanisms. The should not care which one of the s interfaces originates packets with a specific IP source address. If the forwarding requirements for upstream and downstream flows of a single connection are different, the should be able to choose inbound and outbound interfaces that best match the asymmetry. This requires that the IP source address of outbound packets is an address of the inbound interface (assuming that a CN uses the s IP source address as the IP destination address for the packets that the CN sends to the ). On the other hand, the asymmetry can be considered as a negative side-effect when the intention is to move both directions of a connection to another interface without exercising global mobility procedures. However, when the source address does not belong to the outbound interface, ICMP Redirects may not work. Furthermore, the outbound packets should be routable even if the source address is not topologically correct. These issues may need to be circumvented by encapsulation techniques with a forwardable IP source address in the outer header. To make a Mobile IP Home Agent (or a CN) divert separate downstream flows to different access routers, the must use different Home Addresses (with bindings to different CoAs) when initiating connections. A having simultaneous attachments to multiple access routers may also hand over active transport connections from one interface to another by using global mobility management, e.g., Mobile IP address bindings at a Home Agent. Unfortunately, the new address binding would divert all IP traffic (destined to a certain Home Address) towards the new access router. However, a using the per-flow movement technique described in [14], could request a split of its inbound flows. Then, the Home Agent (or a CN) would direct classified downstream flows through specific access router. A could also hand over active transport connections from one interface to another by using micro-mobility (BCMP) path updating. However, also here the new address binding would divert all IP traffic (destined to a certain address) towards the new access router. Then the splitting of in-bound flows would facilitate packet forwarding to two or more access points. D. Scenario 4 A Accessing Different Networks In this scenario, a is able to connect to different access network through different interfaces. The scenario characteristics are similar to the multi-interface Scenario 3 where the attaches to a single with the exception that the metrics related to the access network (e.g., contractual issues and available services) have an impact on the selection of the network interface, and that the must perform multiple full logins to networks. Therefore, most of the issues mentioned in Scenario 3 also apply here (when we replace the term access router with access network ). Handovers may be performed at each interface separately. If seamless inter-domain handovers at a single interface are required the should allow temporary tunnelling across the access network domains. IV. IMPLICATION OF AD-HOC CONNECTIVITY ON THE SCENARIOS The previous sections have tacitly assumed that the connects to a through a direct link. If a singleinterface participates in ad-hoc routing and thus attaches through the ad-hoc fringe network, the may become virtually multiple-interfaced. Then it would

5 reach the through multiple paths (multiple virtual interfaces or links), and the would see the as node having multiple interfaces. A may simultaneously attach to multiple access routers or to multiple interfaces of an access router through both or one of: multiple physical interfaces using direct links, multiple virtual interfaces using multiple routing paths through a MANET. Furthermore, the may be attached to one or more access networks at the same time. Accordingly, this case of virtual multi-interface connectivity shares the issues of Scenarios 3 and 4. However, note that the may attach through one of its interfaces to the same access router s interface via multiple ad-hoc. This case is not considered as a multi-homing scenario but a kind of link-layer multiplexing. However, even in this case, the selection of the next-hop router has an influence on the packet forwarding characteristics. The connection management in the must be provided with enough information for deciding on the use of interfaces and next hop routers. External information should be provided by via the link layer interface and by the ad-hoc routing function. To allow alternative paths through different ARs through an ad-hoc fringe network, the ad-hoc routing protocol routing protocol and the must support attachment of a ad-hoc network to multiple access routers. In any case, even though the s may acquire multiple addresses from the, this should not result in multiple host routes per node. Tunnelling or source routing techniques could be used to avoid injecting multiple addresses to routing. V. CONCLUSIONS Despite the intention to avoid overlaps in the scenario investigations we notice that the different aspects to multi-homing share many benefits, issues, and even approaches to solutions. However, the overlap seems to spring from the structural and functional similarities among protocols and related architectures. We have identified at least the following analogues and parallels: Multiple links from a (site multi-homing) and multiple links at a (multi-interfaced terminal) bring similar advantages but also similar vulnerabilities. Mobility and multi-homing incur same problems (e.g., ingress filtering), which follows from the fact that a mobile node plays with two or more addresses. Attachment to multiple access routers of a single access network shares issues with attachment to multiple access networks, this is partly because local mobility management within the involves the same functions as global mobility management (using Mobile IP). We also notice that, in fact, the case of multiple s and/or multiple s interfaces often reduces to the case of multiple addresses. These similarities might be used as guidance in designing the MIND multi-homing architecture. If there are solutions to one of the polymorphic structures, similar solutions may be applicable to others. Currently our multi-homing effort is directed towards creating the internal architecture of s (i.e. terminal) to benefit from multi-homing by using application awareness and link layer convergence feature for providing monitoring information and controlling the wireless link. ACKNOWLEDGMENTS This work has been performed in the framework of the IST project IST MIND, which is partly funded by the European Union. The authors would like to acknowledge the contributions of their colleagues from Siemens AG, British Telecommunications PLC, Agora Systems S.A., Ericsson Radio Systems AB, France Télécom S.A., King's College London, Nokia Corporation, NTT DoCoMo Inc, Sony International (Europe) GmbH, T-Systems Nova GmbH, University of Madrid, and Infineon Technologies AG. REFERENCES [1] IST MIND, Mobile IP-based Network Developments, [2] IST Project BRAIN, Deliverable D2.2, Mar. 01, [3] R. Braden, Requirements for Internet Hosts Communication Layers, RFC 1122, Oct. 89. [4] M. Bagnulo, A. Garcia-Martinez, A. Azcorra, D. Larrabeiti, Survey on proposed IPv6 multi-homing network level mechanisms, IETF Internet Draft (work in progress), draft-bagnulo-multi6-survey6-00.txt, July 01. [5] B. Black, V. Gill, J. Abley, Requirements for IPv6 Site- Multihoming Architectures, IETF Internet Draft (work in progress) draft-ietf-multi6-multihoming-requirements-02.txt, Nov. 01. [6] R. Draves, Default Address Selection for IPv6, IETF Internet Draft (work in progress), draft-ietf-ipngwg-default-addr-select-06.txt, Sep. 01. [7] J. Jieyun, "IPv6 multi-homing with route aggregation", IETF Internet Draft (work in progress) draft-ietf-ipng-ipv6multihome-withaggr-00.txt, Nov. 99. [8] T. Bates, Y. Rekhter, "Scalable support for multi-homed multiprovider connectivity", RFC 2260, Jan. 98. [9] J. Hagino, H. Snyder, "IPv6 multihoming support at site exit routers", RFC 3178, Apr. 01. [10] F. Dupont, "Multihomed routing domain issues", IETF Internet Draft (work in progress) draft-ietf-ipngwg-multi-isp-00.txt, Sep. 99. [11] M. Crawford, "Router Renumbering for IPv6", RFC 2894, Aug. 00. [12] P. Tattam, "Preserving active TCP sessions on Multi-homed networks", drafts/ preserve_tcp_and_multihome.html, Sep. 99. [13] N. Bragg, "Routing support for IPv6 multi-homing", Internet Draft (work in progress) draft-bragg-ipv6-multihoming-00.txt, Nov. 00. [14] H. Soliman, K. El Malki, Castelluccia, Per-flow movement in MIPv6, IETF Internet Draft (work in progress), draft-solimanmobileip-flow-move-01.txt, Nov. 01. [15] C. Keszei, N. Georganopoulos, Z. Turanyi, A. Valko, Evaluation of the BRAIN Candidate Mobility Management Protocol, IST Summit Barcelona, Sep. 01. [16] R. Stewart, Q. Xie, K. Morneault, C. Sharp, H. Scwarzbauer, T. Taylor, I. Rytina, M. Kalla, L. Zhang, V. Paxon, Stream Control Transmission Protocol, RFC 2960, Oct. 00.