Network Working Group T. Melia Internet-Draft B. Mongazon-Cazavet Intended status: Standards Track Alcatel-Lucent Bell Labs Expires: September 2, 2010 March 01, 2010 Proxy Mobile IPv6 extensions for flow mobility support draft-melia-netext-flow-mob-solution-00 Abstract The Netext WG has been recently rechartered to determine what Proxy Mobile IPv6 extensions are required for flow mobility support of a MN implementing the signle IP interface hiding mechanism. This document briefly introduces the single IP interface hiding mechanism and it derives the associated protocol operations to enable seamless flow mobility across multiple access networks. These extensions are intended to allow such mobile nodes to send and receive IP packets on multiple physical media in a simultaneous and possibly discriminated manner when attached to a PMIPv6 domain. A typical usage of these extensions is to perform downlink flow discrimination through multiple interfaces based on filtering rules (i.e. dedicate one MN physical media to VOIP traffic and another MN media to HTTP traffic). The proposed extensions to PMIPv6 attempt to increment in a backward compatible manner the current PMIPv6 specification. In addition these extensions use, when possible, existing specifications related to multihoming support at IETF and conform to the problem statement of Netext Working Group. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].RFC (e&" Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 1] Internet-Draft Flow Mobility March 2010 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 2, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. 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 BSD License. Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 2] Internet-Draft Flow Mobility March 2010 Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. OvervieW . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Conceptual Data Structure . . . . . . . . . . . . . . . . . . 8 5. Detailed flow charts . . . . . . . . . . . . . . . . . . . . . 9 5.1. Initial multihoming setup . . . . . . . . . . . . . . . . 9 5.2. Multi-interface renewal . . . . . . . . . . . . . . . . . 10 5.3. Multi-interface filters modification MN initiated . . . . 11 5.4. Multi-interface filters modification LMA initiated . . . . 12 5.5. Multi-interface interface removal . . . . . . . . . . . . 12 5.6. Multi-interface interface addition . . . . . . . . . . . . 12 6. Protocol Extensions . . . . . . . . . . . . . . . . . . . . . 13 6.1. Multi-interface Option . . . . . . . . . . . . . . . . . . 13 6.2. Flow Identifier Option . . . . . . . . . . . . . . . . . . 15 7. MAG behavior . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. LMA behavior . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.1. BCE modifications . . . . . . . . . . . . . . . . . . . . 17 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 10. Security Considerations . . . . . . . . . . . . . . . . . . . 17 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 3] Internet-Draft Flow Mobility March 2010 1. Terminology This document uses the following terminology: MIGID Multi6interfqce Group ID: a set of physical interfaces (two or more) belonging to the same MN. On the same MN multiple MIGID can be configured. NIC Network Interface Card: it provides physical access to a networking medium and provides a low-level addressing system through the use of MAC addresses. Bonding Ethernet bonding: is a computer networking arrangement in which two or more network interfaces on a host computer are combined for redundancy or increased throughput. MASTER Master of the bonding device. SLAVE Slave of the bonding device. UL Up Link: flows sent from the MN to the network. DL Down link: flows send from the network to the MN. 2. Introduction Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network based mobility management to hosts connecting to a PMIPv6 domain. PMIPv6 introduces two functional entities, the Local Mobility Anchor (LMA) and the Mobility Access Gateway (MAG). The MAG is the first layer-three hop detecting MN attachment and providing IP connectivity. The LMA is the entity assigning one or more Home Network Prefix (HNP) to the MN and is the topological anchor for all traffic from/to the MN. PMIPv6 allows a MN to connect to the same PMIPv6 domain through multiple interfaces. However in such a case, PMIPv6 requires each interface to be assigned a set of distinct IPv6 address(es) and thus prevents from flow mobility capabilities. The revised Netext charter imposes that the MN uses a single logical IP interface to hide the use of multiple wireless/wired media to the IP stack. In this context the MN is requested to: o configure the logical IP interface (master) and bind to this logical interface two or more wireless/wired physical media (slaves) Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 4] Internet-Draft Flow Mobility March 2010 o perform layer two network attachment and co-ordinate neighbor discovery mechanisms o configure one or more IPv4 and/or IPv6 HNP on the logical IP interface o configure local policies for physical media selection for UL traffic o send/receive triggers for flow mobility to/from the network and local policy update Configuration of a single logical IP interface strictly depends on the OS running in the MN. In Linux/Unix systems virtual interfaces can be configured with the bonding technology. Ethernet bonding (or NIC teaming in Windows OS) allows a host equipped with two or more Ethernet NICs to be connected to one or more layer two switch and to exploit the different NICs for different purposes being reliability, load balancing and bandwidth aggregation some of the possible use cases. As an example, a host equipped with 4 NICs can configure its bonding module for reliability. In case one of the NICs notifies a link failure the following one in the slaves list can take the relay. Alternatively a server, equipped with multiple NICs can be configured to optimize bandwidth aggregation. For an exhaustive list of the different bonding modes in Linux please refer to the Ethernet bonding driver. Under the Window OS the NDIS driver type can be used to create an NDIS Intermediate Driver. Intermediate drivers sit in- between the MAC and IP layers and can control all traffic being accepted by the NIC card. Upon logical interface configuration the MN should perform network attachment and IPv6 neighbor discovery. If we consider the Linux bonding interface, the logical interface (master) and the physical interfaces (slave) share the same MAC address. The PMIPv6 domain where the MN is attaching to can only detect one interface and additional intelligence is required to notify the PMIPv6 domain that both physical interfaces need to be simultaneously connected to the same LMA. In other words, if the MN attaches the physical interface IF1 and configures HNPA, when it attaches physical interface IF2 it should always configure HNPA and, accordingly, the LMA should record both bindings in the BCE (i.e. this is not an intra-technology handover). Additionally, depending on the configured bonding mode, IPv6 neighbor discovery messages should be treated differently than data plane (e.g; bonding configured in round robin mode sends packets iterating across the interfaces). For IP address configuration the MN can exchange DHCP or ND signaling. In case of ND signaling the MN should send RS messages Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 5] Internet-Draft Flow Mobility March 2010 and wait for unicast RA from the MAG. For DHCP the MN sends a DHCP request to the MAG and waits for the DHCP reply carrying the HNP. In both cases, as stated above, the bonding module (given the nature of the Ethernet environments where it usually operates) selects any of the physical interfaces to send out the packet. This has shortcomings since each for the two links should be carrying DHCP/ND messages. It seems intuitive that layer two interaction is required. Upon configuration of one or more HNP on the logical IP interface the MN needs to equally configure policies for media selection for UL packets routing. Policies configuration can happen upon network attachment ( and transferred to the MN by means of layer two signaling) or dynamically via an external channel. This document assumes that L2 signaling can carry such information and that PMIPv6 signaling can convey the routing policies from/to the LMA to/from the MAG. Along the same lines policies update can occur during the lifetime of a binding connection. Update of such policies may result in moving ongoing flows from one access network to another access network. In principle a MN can have two or more NICs and one or more logical interface can be configured. In this sense logical interface A can group IF1 and IF2 and logical interface B can group IF3 and IF4. The document introduces therefore the concept of multi-interface group (a logical set of physical interfaces of a MN) and provides the support of elementary operations (addition, modification, removal) on a group entity for a MN. This terminology is expected to be more suited to the general multi-interface paradigm. In a first step, a default Multi Interface Group ID (MIGID=0) is defined to represent all interfaces of a given MN. 3. OvervieW The functional usage of multi-interface MN capabilities in a PMIPv6 domain is defined by the present specification in a flexible and multi-purpose manner. This allows for various traffic processing in a PMIPv6 domain with multi homed MN such as (not limited to): traffic blocking, traffic load-balancing or traffic dissemination. To achieve this flexibility, this document uses the concept of "filter" to denote a unitary criteria that can be managed between a MAG and a LMA in relationship with a MN interface. Unitary filters can be added, deleted and modified on a per multi-interface group basis. Flexibility is achieved by allowing an arbitrary filter syntax (or grammar) as proposed in [MEXT]. The filter syntax is a matter of agreement between MAG and LMA entities. For the sake of understanding, the "flow" and "filter" terminology shall be considered equivalent. Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 6] Internet-Draft Flow Mobility March 2010 The following Figure 1 depicts the general principles of PMIPv6 extensions for flow mobility support as proposed by the present document. LMA State +----+ --------- |LMA | (addr, pCoA1, flow1, migid) +----+ (addr, pCoA2, flow2, migid) //\\ +---------//--\\-------------+ ( // \\ ) PMIPv6 domain ( // \\ ) +------//--------\\----------+ // \\ pCoA1 // \\ pCoA2 +----+ +----+ if1 -> migid |MAG1| |MAG2| if2 -> migid +----+ +----+ | | | | | if1 if2 | +------[MN]------+ addr Figure 1: Multi-interface MN with PMIPv6 extensions When MN activates if1, MAG1selects the default multi-interface group and performs proxy registration toward the LMA. MAG1 provides filters (flow1) during registration. LMA accepts proxy registration from MAG1 and allocates MN addr according to the shared address model. Since proxy registration is requesting flow mobility support, LMA stores MAG1 filters that come along with delivery to pCoA1. When MN activates if2, MAG2 selects the default multi-interface group and perform proxy registration toward the LMA. MAG2 provides filters (flow2) during registration. LMA accepts proxy registration from MAG2 and allocates MN addr according to the shared address model. LMA stores MAG2 filters that come along with delivery to pCoA2. It should be noted that for both attachment procedures we assume filters can be provided by other means (e..g layer two signaling). Later on, LMA receives IP packets destinated to MN addr. The LMA attempts to match each IP packet against filters (flow1, flow2) stored for the MN addr. When a filter match is found (flow1 or flow2), the LMA performs the action for the IP packet in the context of the matching flow. In particular if the IP packet is to be delivered, the LMA performs delivery using the pCoA associated to the Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 7] Internet-Draft Flow Mobility March 2010 filter (pCoA1 on flow1 or pCoA2 on flow2). LMA behavior is extended to allow simultaneous transmission of downlink (DL) flows to the mobile node across multiple physical interfaces. For UL flows it is assumed that the MN can configure local policies base don user preferences, operator policies, applications requirements, etc... This document does not make any assumption on the order in which rules should be considered neither if some policies have higher priority with respect to others. This document further assumes that the MN is capable of transmitting policies at layer two signaling with the MAG., either during network attachment or upon reception of specific layer two triggers (e.g. Link going down). In the latter case the MN is said to trigger the flow mobility procedure. Both LMA and MAG behaviors are extended to provide enhanced Proxy Binding management for multi-interface MN. LMA shall support Binding Control Entries (BCE) of multi-interface type. This includes the capability to refer to a multi-interface group id (mhgid) and a set of filters in a BCE. LMA shall support or delegate the downlink packet processing and delivery according to flow specifications. Both MAG and LMA shall be able to manage flows on a per multi- interface group basis. This document also assumes that the LMA can equally start a flow mobility procedure based, for instance, on network load conditions. 4. Conceptual Data Structure This specification proposes to extend PMIPv6 to support multiple proxy CoAs per mobility session possibly associated with downlink transmission criteria using the flow concept. Upon MN attachment the MAG determines if the MN should be provided with multi-interface service and, if so, selects the flow configuration that should be put in place for packet delivery. The MAG can learn this information through a policy store or using attachment-specific signaling. Any of the methods used by the MAG is however out of scope of this document. If the MAG determines that the MN can use the multi-interface service it forms a PBU as per [RFC5213] and adds a Multi-interface Option (newly defined by this document) and possibly one or several Flow Identifier option(s) as defined in [MEXT]. The Multi-interface option aims at identifying (MHGID) and parameterizing the multi-interface group to be created/ updated/deleted by the LMA on MAG demand. The choice of identification of the multi-interface group follows the following rule: Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 8] Internet-Draft Flow Mobility March 2010 All PBUs with the same HNP and MIGID values belong to the same mobility session from the LMA perspective. In the current revision of the document, only the default multi- interface group is supported (id=0). In addition, multi-interface group parameters are left for further study. Mobility Session 1 Mobility Session 1 +----------------------+ +---------------------+ | HNP1 PCoA1 MIGID0 | ========> | HNP1 PCoA1 migid0 | +----------------------+ | HNP1 PCoA2 migid0 | +---------------------+ Figure 2: Mobility session extended for multi-interface Figure 2 shows how the mobility session is extended to span the same HNP across multiple interfaces. This updates the text in [RFC5213] where each single interface is managed under a different mobility session. The MHGID, selected by MAG1 (corresponding to PCoA1) upon MN attachment, is stored at the LMA. When the MN attaches to MAG2 (corresponding to PCoA2) MAG2 selects its MIGID value. If both MAG1 and MAG2 MGHID and HNP values match then the LMA adds PCoA2 -- migid0 to the already existing mobility session. The MAG treats the indication of multi-interface as an explicit indication of adding flows to the PBU if any. Such flows can be learned for instance during MN access to the network. Upon reception of a PBU containing indication for multi-interface the LMA should perform a binding cache lookup and append the information to the found BCE. Filters, if present, are extracted from the PBU and processed by the LMA. The result of Filters processing is returned in the PBA by the LMA on an individual basis. 5. Detailed flow charts This section introduces detailed flow charts for multi-interface setup, renewal, filters modifications and interface removal/addition. 5.1. Initial multihoming setup Figure 3 shows the attachment of IF1 and subsequently the attachment of IF2. IF1 and IF2 belong to the same multi-interface group ID (i.e. the default multi-interface group id 0). Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 9] Internet-Draft Flow Mobility March 2010 +-----+ +------+ +------+ +-----+ | MN | | MAG1 | | MAG2 | | LMA | +-----+ +--|---+ +------+ +-----+ | | | MN_ID, PCoA1, | MN[IF1] Attached MAG1 | MIGID0, HI=1, | | | | Filters_1 RQ | | |------------ PBU ------------->| | | | |MN_ID, HNP1, PCoA1, | |<------------- PBA ------------|MIGID0, HI=1, |---RtSol---->| | |Filters_1 RP | |==== Bi-Dir Tunnel ============| |<--Rtr Adv --| | | | | | | IP Address | | Configuration |MN_ID, PCoA2, | | |MGHID0, HI=1, | |MN[IF2] Attached MAG2 |Filters_2 RQ | | |------------ PBU ---->| | | |MN_ID, HNP1, PCoA2, | |<---- PBA ------------|MIGID0, HI=1, |---RtSol------------->| |Filters_2 RP | | | |<-----------Rtr Adv --| | IP Address | | Configuration | | | | | Figure 3: Initial multi-interface setup 5.2. Multi-interface renewal Figure 4 shows inding renewal upon lifetime expiration. Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 10] Internet-Draft Flow Mobility March 2010 +-----+ +------+ +------+ +-----+ | MN | | MAG1 | | MAG2 | | LMA | +-----+ +--|---+ +------+ +-----+ | | | | MN[IF1] Attached MAG1 | HNP1, PCoA1, | Lifetime expires | | MGHID0, HI=5 | | |------------ PBU ------------->| | | | |HNP1, PCoA1, | |<------------- PBA ------------|MGHID0, HI=5 | | | | | | MN[IF2] Attached MAG1 | | Lifetime expires | | | | | | | | | |HNP1, PCoA2, | | |MGHID0, HI=5 | | |------------ PBU ---->| | | |HNP1, PCoA2, | |<---- PBA ------------|MGHID0, HI=5 | | | | | | Figure 4: Multi-inerface renewal 5.3. Multi-interface filters modification MN initiated Filters can also be modified upon reception of an internal or external MAG trigger Figure 5. From the PMIPv6 point of view, filters modification is carried by binding renewal semantics (HI=5). The target multi-interface group is set by the MAG in the multi- interface option (MHGID field). This allows MAG to modify at any time the downlink filters it is responsible for. +-----+ +------+ +------+ +-----+ | MN | | MAG1 | | MAG2 | | LMA | +-----+ +--|---+ +------+ +-----+ | | | HNP1, PCoA1, | MN[IF1] Attached MAG1 | MIGID0, HI=5 | MAG triggers flow modif | Filters_1_modifs RQ | |------------ PBU ------------->| | | | |HNP1, PCoA1, | |<------------- PBA ------------|MGHID0, HI=5 | | Filters_1_modifs RP | | | Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 11] Internet-Draft Flow Mobility March 2010 Figure 5: Multi-interface filters modification MN initiated 5.4. Multi-interface filters modification LMA initiated TBD. 5.5. Multi-interface interface removal Figure 6 shows how to remove an interface from a multi-interface group managed by a MAG for a given MN. The target multi-interface group is set by the MAG in the multi-interface option (MHGID field). +-----+ +------+ +------+ +-----+ | MN | | MAG1 | | MAG2 | | LMA | +-----+ +--|---+ +------+ +-----+ | | | HNP1, PCoA1, | MN[IF1] Attached MAG1 | MIGID0, HI=4 | LINK going down | | LIFETIME = 0 | | |------------ PBU ------------->| | | | |HNP1, PCoA1, | |<------------- PBA ------------|MIGID0, HI=4 | | | Figure 6: Multi-interface interface removal 5.6. Multi-interface interface addition Figure 7 addresses the case where the MN adds a third interface to the same multi-interface group for a given MN. The target multi- interface group is set by the MAG in the multi-interface option (MHGID field). Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 12] Internet-Draft Flow Mobility March 2010 (------) +-----+ ( MAG1 ) +------+ +-----+ | MN | ( MAG2 ) | MAG3 | | LMA | +-----+ (------) +------+ +-----+ | | MN_ID, PCoA3, | MN[IF1] and MNF[IF2] | MIGID0, HI=1, | attached to MAG1 and MAG2 | Filtrers_3 RQ | | |--- PBU ------------->| | | | HNP1, PCoA3, | |<---- PBA ------------| MIGID0, HI=1, | | | Filtrers_3 RP | |== Bi-Dir Tunnel =====| | | | |---RtSol------------->| | | | | |<-------Rtr Adv-------| | | | | Figure 7: Multihoming interface addition 6. Protocol Extensions We provide in the following extensions to the protocol options as defined in [RFC5213]. 6.1. Multi-interface Option Figure 8 shows the Multi-interface option. Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 13] Internet-Draft Flow Mobility March 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | MIGID | ACT | RFU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBA Length 8-bit unsigned integer indicating the length of the option in octets, excluding the type and length fields. This field MUST be set to 2. MIGID This 8 bit field identifies the multi-interface group the PBU/PBA refer to. The value 0 is reserved to the default multi-interface group which includes all interfaces of a MN. Only value 0 is currently supported. ACT This 3-bit field is used to provide optional action to be performed by LMA upon removal of an interface from a multi-interface group. The field shall only be set by the MAG when HI value in PBU is set to 4, otherwise the field shall be set to 0. The following bit values are currently defined: 000: Reserved 001: Remove filters 010: Keep filters RFU (Reserved for Future Use) This 5-bit field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. Figure 8: Multi-interface option The following considerations on the ACT field apply. If 001 (Remove filters) is set on interface removal, the LMA shall remove all filters currently configured. This might result in downlink traffic disruption. If 010 (Keep filters) is set on interface removal, the LMA shall arrange to re-instantiate filters configured on the removed interface to existing filters (if any) of other interfaces of the multi-interface group if any. This allows to avoid downlink traffic disruption. Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 14] Internet-Draft Flow Mobility March 2010 TBD: LMA level decision for flow mobility. However, a filter that has been re-instantiated on a interface should be advertised by the LMA with a specific status of Flow identifier option whenever a MAG performs a filter operation the interface. 6.2. Flow Identifier Option The FID option defined in ID [MEXT] is used in the current specification to manage downlink packet delivery across interfaces of a multi homed MN. The option might be used by a MAG to create/ modify/delete filter(s) on the LMA for a particular multi-interface group of a MN. Upon successful processing and installation of filter(s) at LMA level an individual status (Status field) shall be returned to the MAG by the LMA. The LMA should later evaluate packets destinated to a MN through filters installed by MAG(s) that are proxying the MN under the same mobility session. The LMA must perform the action(s) associated to the matching filter(s). In case, the LMA re-instantiates flows on a multi-interface group toward a MAG for a given MN, the LMA shall perform the following processing: o Allocate a unique FID to the re-instantiated filter within the context of existing filters for the multi-interface group of the MN toward the target LMA o Set the PRO field to a new reserved value (2: flow binding re- instantiated by LMA) of [MEXT] as proposed by the current specification o Copy FID-PRI and Action fields from the original filter into the re-instantiated filter TBD: Since no notification mechanism is currently defined between MAG and LMA in [RFC5213], re-instantiated filter(s) will be returned by LMA only on MAG demand. This might happen when MAG renews PBU or create/modify/delete its own filters. The format of the option is briefly recalled hereafter. The present specification proposes to extend the PRO field value in order to add the (2: flow binding re-instantiated by LMA) predefined value. The full specification of the option can be found in [MEXT] Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 15] Internet-Draft Flow Mobility March 2010 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option Type | Option Len | FID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FID-PRI | Action | Rsvd | PRO | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: FID Option Action values 7. MAG behavior The MAG upon MN attachment performs all the steps as per [RFC5213]. In addition to this it MUST perform the following checks. The MAG learns if the MN is requesting a HNP as part of a new mobility session or if it is requesting to attach a new interface as part of an already existing mobility session. The MAG retrieves the MIGID from e.g. MN's profile as well as filters. The MAG can learn filters in an access-specific manner or alternatively via other infrastructure support. This is however out of scope of this document. In any case the MAG MUST encode the PBU including at least the Multi-interface option as specified before and possibly one or more FID option(s). The MAG can modify or delete filters attached to a multi-interface group by sending a PBU carrying the filter operation(s) to be performed. It shall analyze individual results according to what is returned by the LMA. In addition, MAG should be prepared to handle filters that have been re-instantiated by LMA when MN has disconnected an interface belonging to the same multi-interface group. When MAG proxying a MN detects the MN has detached the related interface, MAG stops proxying the MN by sending a PBU with lifetime set to 0 and includes the multi-interface option that identifies the target multi-interface group of the detached interface as well as removal behavior regarding filters. MAG waits for successful PBA to release the MN access. 8. LMA behavior The LMA should be modified in the BCE and conceptual data structures. Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 16] Internet-Draft Flow Mobility March 2010 8.1. BCE modifications The LMA binding cache lookup method should be extended to accommodate multi-interface support. In case the LMA processes the Multi- interface Option it SHOULD update existing mobility session as defined in [RFC5213]. In addition to this it MUST perform the following checks. If the Multi-interface option is present in the PBU, the LMA must allocate/update/delete the mobility session and the multi-interface group ID it refers to. Flow filters received in the PBU shall be created/modified/deleted for the target Multi-interface group ID and a result shall be return on an individual filter basis. In addition, the LMA shall handle removal of interfaces from multi- interface group according to MAG instructions. In particular, if a MAG instructs a LMA to remove an interface from a multi-interface group but to keep filters, the LMA should re-instantiate filters on existing interface(s) of the multi-interface group according to its own mechanisms. If a LMA does not support multi-interface extension (as a whole) or specific multi-interface option, as proposed by the present document, it shall return a status code in PBA as defined in [RFC5213]. The later specification might be extended to include multi-homing specific statuses, such as: MI_NOT_SUPPORTED_BY_LMA MI_FILTERS_REINSTANCIATION_NOT_SUPPORTED_BY_LMA 9. IANA Considerations This document makes no request of IANA. 10. Security Considerations This document only extends existing options, no security issues are introduced. 11. Acknowledgements TBD. Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 17] Internet-Draft Flow Mobility March 2010 12. References 12.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 12.2. Informative References [MEXT] IETF MEXT Working Group, "Flow Bindings in Mobile IPv6 and Nemo Basic Support", April 2009. [NETEXT] IETF NETEXT Working Group, "Multiple Interface Support with Proxy Mobile IPv6", March 2009. [RFC5149] Korhonen, J., Nilsson, U., and V. Devarapalli, "Service Selection for Mobile IPv6", RFC 5149, February 2008. Authors' Addresses Telemaco Melia Alcatel-Lucent Bell Labs Email: telemaco.melia@alcatel-lucent.com Bruno Mongazon-Cazavet Alcatel-Lucent Bell Labs Email: Bruno.Mongazon-Cazavet@alcatel-lucent.com Melia & Mongazon-Cazavet Expires September 2, 2010 [Page 18]