NETEXT WG T. Melia, Ed. Internet-Draft Alcatel-Lucent Intended status: Informational S. Gundavelli, Ed. Expires: April 27, 2011 Cisco October 24, 2010 Logical Interface Support for multi-mode IP Hosts draft-ietf-netext-logical-interface-support-01.txt Abstract A Logical Interface is a software semantic internal to the host operating system. This semantic is available in all popular operating systems and is used in various protocol implementations. The Logical Interface support is desirable on the mobile node operating in a Proxy Mobile IPv6 domain, for leveraging various network-based mobility management features such as inter-technology handoffs, multihoming and flow mobility support. This document explains the operational details of Logical Interface construct and the specifics on how the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes. Furthermore, this document identifies the applicability of this approach to various link-layer technologies and analyzes the issues around it when used in context with various mobility management features. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 27, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. Melia & Gundavelli Expires April 27, 2011 [Page 1] Internet-Draft Logical Interface Support October 2010 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Hiding link layer technologies - Approaches and Applicability . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Link-layer Abstraction - Approaches . . . . . . . . . . . 7 4.2. Applicability Statement . . . . . . . . . . . . . . . . . 8 4.2.1. Link layer support . . . . . . . . . . . . . . . . . . 8 4.2.2. Logical Interface . . . . . . . . . . . . . . . . . . 9 5. Logical Interface Operation . . . . . . . . . . . . . . . . . 10 5.1. Logical Interface Link Layer Configuration . . . . . . . . 11 5.2. Bring up a new physical interface . . . . . . . . . . . . 12 5.3. Link Scoped Traffic . . . . . . . . . . . . . . . . . . . 13 5.3.1. Unicast Traffic . . . . . . . . . . . . . . . . . . . 13 5.3.2. Multicast Traffic . . . . . . . . . . . . . . . . . . 13 5.4. Global Scoped Traffic . . . . . . . . . . . . . . . . . . 14 5.5. Logical Interface Conceptual Data Structures . . . . . . . 14 5.6. MTU considerations . . . . . . . . . . . . . . . . . . . . 15 6. Logical Interface Use-cases in Proxy Mobile IPv6 . . . . . . . 16 6.1. Multihoming Support . . . . . . . . . . . . . . . . . . . 16 6.2. Inter-Technology Handoff Support . . . . . . . . . . . . . 17 6.3. Flow Mobility Support . . . . . . . . . . . . . . . . . . 19 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 21 9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 Melia & Gundavelli Expires April 27, 2011 [Page 2] Internet-Draft Logical Interface Support October 2010 11. Appendix . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 12.2. Informative References . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Melia & Gundavelli Expires April 27, 2011 [Page 3] Internet-Draft Logical Interface Support October 2010 1. Introduction Proxy Mobile IPv6 [RFC5213] is a network-based mobility protocol. Some of the key goals of the protocol include support for multihoming, inter-technology handoffs and flow mobility support. The PMIPv6 extensions chartered in the NETEXT WG) allow the mobile node to attach to the network using multiple interfaces (simultaneously or sequentially), or to perform handoff between different interfaces of the mobile node. However, for supporting these features, the mobile node is required to be activated with specific software configuration that allows the mobile node to either perform inter-technology handoffs between different interfaces, attach to the network using multiple interfaces (sequentially or simultaneously), or perform flow movement from one access technology to another. This document analyzes from the mobile node's perspective a specific approach that allows the mobile node to leverage these mobility features. Specifically, it explores the use of the Logical Interface support, a semantic available on most operating systems. A Logical Interface is a construct internal to the operating system. It is an approach where the link-layer implementations hide the physical interfaces from the IP stack and from the network nodes. This semantic is widely available in all popular operating systems. Many applications such as Mobile IP client [RFC3775], IPsec VPN client [RFC4301] and L2TP client [RFC3931] all rely on this semantic for their protocol implementation and the same semantic can also be useful in this context. Specifically, the mobile node can use the logical interface configuration for leveraging various network-based mobility management features provided by the Proxy Mobile IPv6 domain [RFC5213]. The rest of the document provides the operational details of the Logical Interface on the mobile node and the inter-working between a mobile node using logical interface and network elements in the Proxy Mobile IPv6 domain. It also analyzes the issues involved with this approach and characterizes the contexts in which such use is appropriate. Melia & Gundavelli Expires April 27, 2011 [Page 4] Internet-Draft Logical Interface Support October 2010 2. Requirements Language In this document, the key words "MAY", "MUST, "MUST NOT", "OPTIONAL", "RECOMMENDED", "SHOULD", and "SHOULD NOT", are to be interpreted as described in [RFC2119]. Melia & Gundavelli Expires April 27, 2011 [Page 5] Internet-Draft Logical Interface Support October 2010 3. Terminology This document uses the following terms: PIF Physical Interface: a network device providing IP connectivity (e.g. an Ethernet card, a WLAN card, an LTE interface). LIF Logical Interface: a virtual interface hiding to the IP stack the heterogeneous wired/wirelss network devices. VLL-ID Virtual Link Layer ID: a virtual MAC address configured on the LIF. It can be randomly generated or configured based on the MAC of one of the PIF. Melia & Gundavelli Expires April 27, 2011 [Page 6] Internet-Draft Logical Interface Support October 2010 4. Hiding link layer technologies - Approaches and Applicability There are several techniques/mechanisms that allow hiding access technology changes or movement from host IP layer. This section classifies these existing techniques into a set of generic approaches, according to their most representative characteristics. We then refer to these generic mechanisms later in the document, when analyzing their applicability to inter-access technology and flow mobility purposes in PMIPv6. 4.1. Link-layer Abstraction - Approaches The following generic mechanisms can hide access technology changes from host IP layer: o Link layer support: certain link layer technologies are able to hide physical media changes from the upper layers (see Figure 1). For example, IEEE 802.11 is able to seamlessly change between IEEE 802.11a/b/g physical layers. Also, an 802.11 STA can move between different Access Points (APs) within the same domain without the IP stack being aware of the movement. In this case, the IEEE 802.11 MAC layer takes care of the mobility, making the media change invisible to the upper layers. Another example is IEEE 802.3, that supports changing the rate from 10Mbps to 100Mbps and to 1000Mbps. Mobile Node +-----------------------+ | TCP/UDP | AR1 AR2 +-----------------------+ +-----+ +-----+ | IP | | IP | | IP | +-----------------------+ +-----+ +-----+ | Link Layer (L2) | | L2 | | L2 | +-----+-----+-----+-----+ +-----+ +-----+ | L1a | L1b | L1c | L1d |<---------->| L1d | | L1b | +-----+-----+-----+-----+ +-----+ +-----+ ^ ^ |_________________________________________| Figure 1: Link layer support solution architecture There are also other examples with more complicated architectures, like for instance, 3GPP EPC. In this case, a UE can move (inter-RA handover) between GERAN/UTRAN/E-UTRAN, being this movement invisible to the IP layer at the UE, and also to the LMA logical component at the PGW. The link layer stack at the UE (i.e. PDCP and RLC layers), and the GTP between the RAN and the SGW (which plays the role of inter-3GPP AN mobility anchor) hide this kind of mobility, which is not visible to the IP layer of the Melia & Gundavelli Expires April 27, 2011 [Page 7] Internet-Draft Logical Interface Support October 2010 UE (see Figure 2). --------- | Appl. |<-----------------------------------------------------> --------- ---------- | |<+ - - - - - - - - - - - - - - - - - - - - +>| | | IP | . ----------------- . ------------------- . | IP | | |<+>| relay |<+>| relay | . | | --------- . ----------------- . ------------------- . ---------- | PDCP |<+>| PDCP | GTP-U |<+>| GTP-U | GTP-U |<+>| GTP-U | --------- . ----------------- . ------------------- . ---------- | RLC |<+>| RLC | UDP/IP |<+>| UDP/IP | UDP/IP |<+>| UDP/IP | --------- . ----------------- . ------------------- . ---------- | MAC |<+>| MAC | L2 |<+>| L2 | L2 |<+>| L2 | --------- . ----------------- . ------------------- . ---------- | L1 |<+>| L1 | L1 |<+>| L1 | L1 |<+>| L1 | --------- . ----------------- . ------------------- . ---------- UE Uu E-UTRAN S1-U SGW S5/S8a PGW Figure 2: 3GPP LTE/EPC data plane architecture (GTP option) o Logical interface: this refers to solutions (see Figure 3) that logically group/bond several physical interfaces so they appear to the upper layers (i.e. IP) as one single interface (where application sockets bind). Depending on the OS support, it might be possible to use more than one physical interface at a time -- so the node is simultaneously attached to different media -- or just to provide a fail-over mode. Controlling the way the different media is used (simultaneous, sequential attachment, etc) is not trivial and requires additional intelligence and/or configuration at the logical interface device driver. An example of this type of solution is the Logical interface, which is defined in this document, or the bonding driver (a Linux implementation). 4.2. Applicability Statement We now focus on the applicability of the above solutions against the following requirements: o multi technology support o sequential vs. simultaneous access 4.2.1. Link layer support Link layer mobility support applies to cases when the same link layer technology is used and mobility can be fully handled at these layers. One example is the case where several 802.11 APs are deployed in the Melia & Gundavelli Expires April 27, 2011 [Page 8] Internet-Draft Logical Interface Support October 2010 same subnet and all of them share higher layer resources such as DHCP server, IP gateway, etc. In this case the APs can autonomously (or with the help of a central box) communicate and control the STA association changes from one AP to another, without the STA being aware of the movement. This type of scenario is applicable to cases when the different points of attachment (i.e. APs) belong to the same network domain, e.g. Enterprise, hotspots from same operator, etc. This type of solution does not typically allow for simultaneous attachment to different access networks, and therefore can only be considered for inter-access technology handovers, but not for flow mobility. Existing RFC 5213 handover hint mechanisms could benefit from link layer information (e.g. triggers) to detect and identify MN handovers. Link layer support is not applicable when two different access technologies are involved (e.g. 802.11 WLAN and 802.16 WiMAX) and the same is true when the same access technology expands over multiple network domains. This solution does not impose any change at the IP layer since changes in the access technology occur at layer two. 4.2.2. Logical Interface The use of a logical interface allows the mobile node to provide a single interface view to the layers above IP (thus not changing the IP layer itself). Upper layers can bind to this interface, which hides inner inter-access technology handovers or data flow transfers among different physical interfaces. This type of solution may support simultaneous attachment, in addition to sequential attachment. It requires additional support at the node and the network in order to benefit from simultaneous attachment. For example special mechanisms are required to enable addressing a particular interface from the network (e.g. for flow mobility). In particular extensions to PMIPv6 are required in order to enable the network (i.e., the MAG and LMA) to deal with physical interfaces, instead to IP interfaces as current RFC5213 does. RFC5213 assumes that each physical interface capable of attaching to a MAG is an IP interface, while the logical interface solution groups several physical interfaces under the same IP logical interface. It is therefore clear that the Logical Interface approach satisfies the multi technology and the sequential vs: simultaneous access support. Melia & Gundavelli Expires April 27, 2011 [Page 9] Internet-Draft Logical Interface Support October 2010 5. Logical Interface Operation On most operating systems, a network interface is associated with a physical device that provides the capability for transmitting and receiving network packets. In some cases a network interface can also be implemented as a logical interface which does not feature any packet transmission or reception capabilities, but relies on other network interfaces for such capabilities. A logical interface can be realized by that means. General overview of a logical interface is shown in Figure 3. The logical interface allows heterogeneous attachment while leaving the change in the media transparent to the IP stack. Simultaneous and sequential network attachment procedures are possible enabling inter-technology and flow mobility scenarios. Through link awareness the logical interface can keep consistent neighbor caches and move flows across access networks transparently to the upper layers. +----------------------------+ | TCP/UDP | Session to IP +---->| | Address binding | +----------------------------+ +---->| IP | IP Address +---->| | binding | +----------------------------+ +---->| Logical Interface | Logical to +---->| (MN-HoA) | Physical | +----------------------------+ Interface +---->| L2 | L2 | | L2 | binding |(IF#1)|(IF#2)| ..... |(IF#n)| +------+------+ +------+ | L1 | L1 | | L1 | | | | | | +------+------+ +------+ Figure 3: General overview of logical interface From the perspective of the IP stack and the applications, a Logical interface is just another interface. A host does not see any difference between a Logical and a physical interface. All interfaces are represented as software objects to which IP address configuration is bound. However, the Logical interface has some special properties which are essential for enabling inter-technology handover and flow-mobility features. Following are those properties: o P1: Logical interface has a relation to a set of physical interfaces (sub-interfaces) on the host. Sub-interfaces can be attached/detached to the Logical Interface at any time (i.e. upon Melia & Gundavelli Expires April 27, 2011 [Page 10] Internet-Draft Logical Interface Support October 2010 L2 hints). o P2: The Logical Interface may or may not use the same link layer identifier as the physical interfaces (i.e. some technologies might not allow changing the link layer ID) . o P3: The Logical Interface has the path awareness of an IPv4/IPv6 link through a sub-interface. o P4: The logical Interface may manage heterogeneous links. As such, different MTUs may be announced on different links. The Logical Interface should be able to configure a common value (e.g., the minimum value observed by any link)". o P5: Send/Receive operations of a Logical interface are managed dynamically and are tied to the sub-interfaces (i.e. dynamic mapping not be visible to the applications). o P6: The Logical interface should transmit uplink packets on the same physical interface on which the downlink packet was received for the particular prefix/flow. 5.1. Logical Interface Link Layer Configuration The logical interface has a virtual link-layer identifier (VLL-ID) that is not associated with any physical interfaces (see P2). This VLL-ID can be a representative of those of the physical interfaces or can be independently assigned. The usage of the VLL-ID is as follows: o Used for the neighbor discovery operation o Used to configure the IP address for this logical interface when the SLAAC is applied o Stored in the BCE at the Local Mobility Anchor via the Link-layer Identifier Option of the PBU o Used as the source link-layer address for sending packets from this logical interface In order to support the above usage, all the physical interfaces SHOULD be able to send packets with the VLL-ID as the source link- layer address and SHOULD be able to receive packets with the VLL-ID as the destination link-layer address (the promiscuous mode). If some of the connected wireless links do not allow sending packets with an arbitrary link-layer address, then the link-layer of the Melia & Gundavelli Expires April 27, 2011 [Page 11] Internet-Draft Logical Interface Support October 2010 corresponding PIF MUST be used instead. When receiving packets, whose destination LL-ID is that of the PIF, that LL-ID MUST be replaced with the VLL-ID before it appears to the IP layer. 5.2. Bring up a new physical interface When a new PIF is enabled the following applies (see P1): Bring up a new PIF: When a physical interface is enabled, a link- local address is formed by configuring the well-known link-local prefix FE80::/64 to the interface identifier. This address is a unicast address and has link-only scope. The MN can use this address to reach its neighbors. Sending Neighbor Solicitation: When the MN wants to send a unicast packet but does not know the neighbor's link-layer address, it will perform address resolution by sending Neighbor Solicitation message through all of the enabled PIFs which are hidden by the LIF. Receiving Neighbor Solicitation and Sending Neighbor Advertisement: When the LIF receives a Neighbor Solicitation message from a PIF, it will send a Neighbor Advertisement response message via the same PIF. The LIF may also send unsolicited Neighbor Advertisement message via all enabled PIFs in order to propagate new information quickly. Sending Router Solicitation and receiving Router Advertisement: The LIF sends Router Solicitation messages through all enabled PIFs. The Router Advertisement messages are returned to the LIF through the PIFs that the Router Solicitation messages are sent from. The source link-layer address used in Neighbor Solicitation, Neighbor Advertisement and Router Solicitation is the link-layer identifier of the LIF. It should be noted that since all the MAGs appear to the MN with the same IPv6 link-local and link-layer addresses (and that only the MAG shares the physical links with the MN) the ND caches of the LIF at the MN do not need complex extensions nor internal state kept at the LIF to be able to send traffic via multiple PIFs associated to the same LIF. The LIF engine would be able to generate the whole L2 frame and deliver it to the right PIF(s). No change in the L2 frame is needed at the LIF. Melia & Gundavelli Expires April 27, 2011 [Page 12] Internet-Draft Logical Interface Support October 2010 5.3. Link Scoped Traffic The following section analyzes both unicast and multicast traffic handled by the LIF (see P3 and P5). 5.3.1. Unicast Traffic Link-local unicast traffic generated by the LIF is sent through all PIFs associated to the LIF. As an example, Neighbor Advertisements messages generated by the LIF are sent through all PIFs. From the viewpoint of ND, this does not suppose any problem, as all the PIFs are logically grouped under the same LIF. When receiving, the LIF receives all the traffic received via any of the PIFs associated to the LIF, and processes it normally. For example, Neighbor Solicitations are received and processed by the LIF without any modification (adding/updating the ND cache). Since in PMIPv6 only point-to-point interfaces are supported between the MN and the MAG, and all the MAGs show the same IPv6 link-local and link- layer addresses, this mode of operation of the LIF does not add any issue from the point of view of ND. 5.3.2. Multicast Traffic Link-local multicast traffic generated by the LIF is sent through all PIFs associated to the LIF. As an example, Router Solicitation messages generated by the LIF are sent through all PIFs. This might cause multiple messages being received in response, though that would not cause any issue. When receiving, traffic from all PIFs is delivered to the LIF, which processes it normally. Examples of this traffic could be Router Advertisements or Neighbor Solicitations. As a result of the reception of certain types of link-local multicast traffic, the LIF might need to generate and send a (unicast) response. In this case, there are two possible approaches that can be followed: o Proceed as specified in Section 5.3.1 and send unicast responses via all PIFs associated to the LIF o Keep state at the LIF so replies can be sent via the proper interface only. Melia & Gundavelli Expires April 27, 2011 [Page 13] Internet-Draft Logical Interface Support October 2010 --------- --------- | MAG 1 | | MAG 2 | --------- --------- | mag-IPv6-ll-addr | mag-IPv6-ll-addr | mag-l2-addr | mag-ll-addr | | | | | | | | RA(pref1) | | RA(pref2) | V | V | --------------- | | RS | LIF | RS | | <--- --------------- ----> | ( pref1 and pref2 ) |--------------+ PIF1 | PIF2 +--------------| ( may be the same ) --------------- Neighbor cache (interface LIF): IPv6 address link-layer address ============== ==================== mag-IPv6-ll-addr mag-ll-addr Figure 4: Link scoped traffic management by the LIF and its relation to Neighbor Discovery 5.4. Global Scoped Traffic The following section analyzes both unicast and multicast traffic handled by the LIF (see P3 and P5). For global-scoped traffic, the same assumptions taken in [RFC5213] for unicast traffic apply. Beyond these assumptions, the MULTIMOB WG is looking at ways to enhance the handling of multicast traffic in a PMIPv6 domain. The use of Logical Interface in the mobile node does not affect any of the aforementioned scenarios. 5.5. Logical Interface Conceptual Data Structures The LIF has populates its neighbor cache according to standard operations. It should be noted that given the specificity of the PMIPv6 protocol there is only one entry being all the MAGs configured with the same link local address. The LIF has one default route in its routing table pointing to the link local address of the MAG (it should be noted that the same as before applies). The prefix list contains all the prefixes received during the attachment phase. The destination cache may contain multiple entries but the next hops is the same for all entries pointing the link local address of the MAG. The LIF should maintain the following data structures as depicted in Melia & Gundavelli Expires April 27, 2011 [Page 14] Internet-Draft Logical Interface Support October 2010 figure Figure 5 LIF TABLE FLOW table +===============================+ +===============================+ | PIF_ID | FLOW RoutingPolicies | | FLOW ID | PIF_ID | | | Home Network Prefix | +-------------------------------+ | | Link Layer Address | | FLOW_ID | PIF_ID | | | Status | +===============================+ +-------------------------------| | PIF_ID | FLOW RoutingPolicies | | | Home Network Prefix | | | Link Layer Address | | | Status | +-------------------------------+ | .... | .... | +===============================+ Figure 5 The LIF table maintains the mapping between the LIF and each PIF associated to the LIF (see P3). For each PIF entry the table should store the associated Routing Policies, the Home Network Prefix received during the SLAAC procedure, the configured Link Layer Address (as described above) and the Status of the PIF (active, not active). The FLOW table allows a LIF to properly route each IP flow to the right interface. It assumed that the LIF can identify flows traversing its PIFs and cam map accordingly to any of the PIF. For locally generated traffic the LIF performs interface selection. For traffic of an existing flow received from the network on a different PIF than the one locally stored, the LIF should interpret as an explicit flow mobility trigger and update the PIF_ID parameter in the corresponding table (see P6). 5.6. MTU considerations The LIF SHOULD be configured with the maximum MTU value that is supported by all interfaces (see P4). Melia & Gundavelli Expires April 27, 2011 [Page 15] Internet-Draft Logical Interface Support October 2010 6. Logical Interface Use-cases in Proxy Mobile IPv6 This section explains how the Logical interface support on the mobile node can be used for enabling some of the Proxy Mobile IPv6 protocol features. 6.1. Multihoming Support A mobile node with multiple interfaces can attach simultaneously to the Proxy Mobile IPv6 domain. Each of the attachment links are assigned a unique set of IPv6 prefixes. If the host is configured to use Logical interface over the physical interface through which it is attached, following are the related considerations. LMA's Binding Table +================================+ +----+ | HNP MN-ID CoA ATT LL-ID | |LMA | +================================+ +----+ | HNP-1 MN-1 PCoA-1 5 ZZZ | //\\ | HNP-2 MN-1 PCoA-2 4 ZZZ | +---------//--\\-----------+ ( // \\ ) ( // \\ ) +------//--------\\--------+ // \\ PCoA-1 // \\ PCoA-2 +----+ +----+ (WLAN) |MAG1| |MAG2| (WiMAX) +----+ +----+ \ / \ / HNP-1 \ / HNP-2 \ / \ / +-------+ +-------+ | if_1 | | if_2 | |(WLAN) | |(WiMAX)| +-------+-+-------+ | Logical | (LL-ID: ZZZ) | Interface | HNP-1::zzz/128 +-----------------| HNP-2::zzz/128 | MN | +-----------------+ Figure 6: Multihoming Support Melia & Gundavelli Expires April 27, 2011 [Page 16] Internet-Draft Logical Interface Support October 2010 o The mobile node detects the advertised prefixes from the MAG1 and MAG2 as the on link prefixes on the link to which the Logical interface is attached. o The mobile node can generate address configuration using stateless auto configuration mode from any of those prefixes. o The applications can be bound to any of the addresses bound to the Logical interface and that is determined based on the source address selection rules. o The host has path awareness for the hosted prefixes based on the received Router Advertisement messages. Any packets with source address generated using HNP_1 will be routed through the interface if_1 and for packets using source address from HNP_2 will be routed through the interface if_2. 6.2. Inter-Technology Handoff Support The Proxy Mobile IPv6 protocol enables a mobile node with multiple network interfaces to move between access technologies, but still retaining the same address configuration on its attached interface. The protocol enables a mobile node to achieve address continuity during handoffs. If the host is configured to use Logical interface over the physical interface through which it is attached, following are the related considerations. Melia & Gundavelli Expires April 27, 2011 [Page 17] Internet-Draft Logical Interface Support October 2010 LMA's Binding Table +================================+ +----+ | HNP MN-ID CoA ATT LL-ID | |LMA | +================================+ +----+ | HNP-1 MN-1 PCoA-1 5 ZZZ | //\\ (pCoA-2)(4) <-change +---------//--\\-----------+ ( // \\ ) ( // \\ ) +------//--------\\--------+ // \\ PCoA-1 // \\ PCoA-2 +----+ +----+ (WLAN) |MAG1| |MAG2| (WiMAX) +----+ +----+ \ / \ Handoff / \ ----> / HNP-1 \ / \ / +-------+ +-------+ | if_1 | | if_2 | |(WLAN) | |(WiMAX)| +-------+-+-------+ | Logical | (LL-ID: ZZZ) | Interface | HNP-1::zzz/128 +-----------------| | MN | +-----------------+ Figure 7: Inter-Technology Handoff Support o When the mobile node performs an handoff between if_1 and if_2, the change will not be visible to the applications of the mobile node. It will continue to receive Router Advertisements from the network, but from a different sub-interface path. o The protocol signaling between the network elements will ensure the local mobility anchor will switch the forwarding for the advertised prefix set from MAG1 to MAG2. o The MAG2 will host the prefix on the attached link and will include the home network prefixes in the Router Advertisements that it sends on the link. Melia & Gundavelli Expires April 27, 2011 [Page 18] Internet-Draft Logical Interface Support October 2010 6.3. Flow Mobility Support For supporting flow mobility support, there is a need to support vertical handoff scenarios such as transferring a subset of prefix(es) (hence the flows associated to it/them) from one interface to another. The mobile node can support this scenario by using the Logical interface support. This scenario is similar to the Inter- technology handoff scenario defined in Section 6.2, only a subset of the prefixes are moved between interfaces. Additionally, IP flow mobility in general initiates when the LMA decides to move a particular flow from its default path to a different one. The LMA can decide on which is the best MAG that should be used to forward a particular flow when the flow is initiated e.g. based on application policy profiles) and/or during the lifetime of the flow upon receiving a network-based or a mobile- based trigger. As an example of mobile-based triggers, the LMA could receive input (e.g.by means of a layer 2.5 function via L3 signaling [RFC5677]) from the MN detecting changes in the mobile wireless environment (e.g. weak radio signal, new network detected, etc.). Upon receiving these triggers, the LMA can initiate the flow mobility procedures. For instance, when the mobile node only supports single-radio operation (i.e. one radio transmitting at a time), only sequential (i.e. not simultaneous) attachment to different MAGs over different media is possible. In this case layer 2.5 signaling can be used to perform the inter-access technology handover and communicate to the LMA the desired target access technology, MN-ID, Flow-ID and prefix. Melia & Gundavelli Expires April 27, 2011 [Page 19] Internet-Draft Logical Interface Support October 2010 7. IANA Considerations This specification does not require any IANA Actions. Melia & Gundavelli Expires April 27, 2011 [Page 20] Internet-Draft Logical Interface Support October 2010 8. Security Considerations This specification explains the operational details of Logical interface on an IP host. The Logical Interface implementation on the host is not visible to the network and does not require any special security considerations. Melia & Gundavelli Expires April 27, 2011 [Page 21] Internet-Draft Logical Interface Support October 2010 9. Authors This document reflects contributions from the following authors (listed in alphabetical order): Carlos Jesus Bernardos Cano cjbc@it.uc3m.es Antonio De la Oliva aoliva@it.uc3m.es Yong-Geun Hong yonggeun.hong@gmail.com Kent Leung kleung@cisco.com Tran Minh Trung trungtm2909@gmail.com Hidetoshi Yokota yokota@kddilabs.jp Juan Carlos Zuniga JuanCarlos.Zuniga@InterDigital.com 10. Acknowledgements The authors would like to acknowledge prior discussions on this topic in NETLMM and NETEXT working groups. The authors would also like to thank Joo-Sang Youn, Pierrick Seite, Rajeev Koodli, Basavaraj Patil, Julien Laganier for all the discussions on this topic. 11. Appendix TBD 12. References Melia & Gundavelli Expires April 27, 2011 [Page 22] Internet-Draft Logical Interface Support October 2010 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 12.2. Informative References [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC5677] Melia, T., Bajko, G., Das, S., Golmie, N., and JC. Zuniga, "IEEE 802.21 Mobility Services Framework Design (MSFD)", RFC 5677, December 2009. Authors' Addresses Telemaco Melia (editor) Alcatel-Lucent Route de Villejust Nozay 91620 France Email: telemaco.melia@alcatel-lucent.com Sri Gundavelli (editor) Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: sgundave@cisco.com Melia & Gundavelli Expires April 27, 2011 [Page 23]