NetExt K. Xue Internet-Draft D. Ni Intended status: Standards Track P. Hong Expires: January 1, 2013 USTC H. Chan Huawei June 30, 2012 Flow Mobility In Muti-LMA Environment draft-xue-netext-flowmo-multilma-00.txt Abstract PMIPv6 allows multiple Local Mobility Anchor(LMA) to exist in a PMIPv6 domain, it MAY cause that different interfaces of a mobile node(MN) are anchored to different LMAs. In this document, we propose to discuss how to support flow mobility in multi-LMA environment. Among the discussed scenarios, The scenario of different interfaces with different MAGs in multi-LMA environment cannot use traditional ways to realize flow mobility to a existing interface. 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 January 1, 2013. Copyright Notice Copyright (c) 2012 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 Xue, et al. Expires January 1, 2013 [Page 1] Internet-Draft Multi-LMA flow mobility June 2012 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Xue, et al. Expires January 1, 2013 [Page 2] Internet-Draft Multi-LMA flow mobility June 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 2.1. Conventions Used in This Document . . . . . . . . . . . . 4 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview of PMIPv6-based Flow Mobility Extensions in Multi-LMA Environment . . . . . . . . . . . . . . . . . . . . 5 3.1. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6 3.2.1. Different Interfaces with a Shared MAG . . . . . . . . 6 3.2.2. Different Interfaces with Different MAGs . . . . . . . 9 4. Select the Target Interface . . . . . . . . . . . . . . . . . 15 5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Enhance Flow Mobility Initiate(eFMI) . . . . . . . . . . . 16 5.2. Enhanced Flow Mobility Acknowledge(eFMA) . . . . . . . . . 17 6. Conceptual Data Structures . . . . . . . . . . . . . . . . . . 18 6.1. Multiple Care-of Address Registration . . . . . . . . . . 18 6.2. Flow Mobility Cache . . . . . . . . . . . . . . . . . . . 19 6.3. Mobile Node's policy profile . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . . 21 8.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Xue, et al. Expires January 1, 2013 [Page 3] Internet-Draft Multi-LMA flow mobility June 2012 1. Introduction Since single LMA environment may cause single point failure, multi- LMA environment is proposed and some documents have discussed issues in such environment. In [RFC 6463], runtime LMA assignment is proposed for the purpose of load sharing in multi-LMA environment. In the architecture of 3GPP, P-GW plays the role of LMA. There are two real deployment examples in 3GPP architecture to support multi- LMA environment. 1) In the flow based mobility scenarios, UE can use local P-GW to carry new generated flow and home P-GW to carry former flow simultaneously; 2)UE can use different P-GWs to access different services. PMIPv6 allows a MN to access Internet services through different interfaces in the same PMIPv6-Domain, and it also allows multiple LMAs in the same domain. In such environment, different interfaces of a MN can be anchored to different LMAs. But the existing flow mobility technology [I-D.ietf-netext-pmipv6-flowmob] is not complete, which is only adapted to the scenario with a single LMA. This document specifies protocol extensions to enable flow mobility on different physical interfaces in multi-LMA environment. This document assumes that the mobile node(MN) implements the logical interface model [I-D.ietf-netext-logical-interface-support], prefixes of specific flows are transferred on different physical interfaces in a loose way regardless of the assigned prefixes on these interfaces. 2. Conventions and Terminology 2.1. Conventions Used in This Document 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 [RFC2119]. 2.2. Terminology The following terms used in this document are defined in the Proxy Mobile IPv6 [RFC 5213]: Local Mobility Agent (LMA). Mobile Access Gateway (MAG). Proxy Mobile IPv6 Domain (PMIPv6-Domain). LMA Address (LMAA). Xue, et al. Expires January 1, 2013 [Page 4] Internet-Draft Multi-LMA flow mobility June 2012 Proxy Care-of Address (Proxy-CoA). Home Network Prefix (HNP). The following terms used in this document are defined in the Multiple Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support [RFC6089]: Binding Identification Number (BID). Flow Identifier (FID). Traffic Selector (TS). The following terms are defined and used in this document: eFMI (enhanced Flow Mobility Initiate). Message sent by the LMA to the MAG, may be forwarded by another LMA managing this MAG, conveying the information required to enable flow mobility in a PMIPv6-Domain. eFMA (enhanced Flow Mobility Acknowledge). Message sent by the MAG in reply to an eFMI message. FMC(Flow Mobility Cache). Conceptual data structure maintained by the LMA and the MAG to support the flow mobility management operations described in this document. 3. Overview of PMIPv6-based Flow Mobility Extensions in Multi-LMA Environment 3.1. Scenarios In multi-LMA environment, we assume that traffic flows distributed on different interfaces can be anchored to different LMAs. Each LMA logically manages a different group of MAGs, however is unaware of the MAGs registered on other LMAs and the corresponding interfaces attached. Thus, one LMA SHALL NOT communicate with the MAG under another LMA without the help of this LMA. In this specification, selected flows after flow mobility SHALL not change the anchored LMA but MN's interfaces and relative MAGs SHOULD adjust accordingly. Policy Profile SHOULD exist in a PMIPv6-Domain implemented in AAA server, which maintains addresses of all the LMAs in the same domain on a per-interface basis. This specification uses the default behavior in basic PMIPv6[RFC5213], in which the MN obtains a prefix or a new set of prefixes for the new session at the time of a new interface attachment. Xue, et al. Expires January 1, 2013 [Page 5] Internet-Draft Multi-LMA flow mobility June 2012 There are two different scenarios of flow mobility in multi-LMA environment as the following: (a) MN's different interfaces are attached to the same MAG, but the flows through different interfaces are anchored to different LMAs. (b)The different interfaces of MN are attached to different MAGs, and are anchored to different LMAs, too. 3.2. Basic Operation 3.2.1. Different Interfaces with a Shared MAG It is corresponding to Scenario-(a). A MN can access Internet in a PMIPv6 domain through different interfaces. The sessions of each interface are anchored to a separate LMA, whereas all different interfaces are attached to a single shared MAG. An example of this scenario is showed in Figure 1, where a mobile node (MN) has two different physical interfaces (if1 and if2), grouped in a logical one (lif). Both interfaces are attached to the same MAG, and each is anchored to a different LMA. These two interfaces are assigned with different set of prefixes upon attachment to MAG. There are 2 cases in this scenario. Xue, et al. Expires January 1, 2013 [Page 6] Internet-Draft Multi-LMA flow mobility June 2012 LMA1 Binding Cache +----+ +----+ ==================== |LMA1| |LMA2| MN, if1, pref1, MAG +----+ +----+ \\ // +------\\----------//--------+ LMA2 Binding Cache ( \\ PMIPv6 // ) ==================== ( \\domain// ) MN, if2, pref2, MAG +---------\\----//-----------+ \\ // \\// +----+ | MAG| +----+ | | |-------| |------| | +-------+ | | | I P | | | +-------+ | | | lif | | | +---+---+ | |---|if1|if2|----| +---+---+ MN Figure 1: Different interfaces with single shared MAG and different LMAs. Figure 2 shows Case 1 of scenario-(a), in which both different physical interfaces of the MN are initially both powered on. Flow X(bound to pref1::/64) goes through if1-MAG-LMA1 and flow Y(bound to pref2::/64) goes through if2-MAG-LMA2. At a certain time, MAG detects the congestion of if2, and flow Y is decided to be moved to if1. Flow Y can be moved just by updating the routing state at MAG locally, binding pref2 with if1. No signaling exchange between LMA and MAG is needed. The binding cache entry at LMA SHOULD not make any change. Xue, et al. Expires January 1, 2013 [Page 7] Internet-Draft Multi-LMA flow mobility June 2012 +-----+ +-----+ +------+ +-----+ Internet | LMA1| | LMA2| | MAG | | MN | +-----+ +-----+ +------+ +-----+ | | | | | | flow X to | flow X to | flow X to | | pref1::lif | pref1::lif | pref1::lif | |<----------->|<-------------------------->|<----------->if1 | flow Y to | flow Y to | flow Y to | | pref2::lif | pref2::lif | pref2::lif | |<------------------------->|<------------>|<----------->if2 | | | | | | ======================================================== | || decision to move flow Y || | ======================================================== | | | | | | flow Y to | flow Y to | flow Y to | | pref2::lif | pref2::lif | pref2::lif | |<------------------------->|<------------>|<----------->if1 | | | | | Figure2: Flow mobility signaling process of Scenario-(a) when both interfaces are powered on initially.(no signaling) Case 2 of Scenario-(a) is showed in Figure 3, flow mobility happens when a new interface if2 is just powered on. In this case, MAG detects L2 attachment of if2 and sends PBU to register in LMA2. LMA2 uses this request as a trigger to enable flow mobility. Flow Y is bound to pref2::/64, and MAG updates routing state binding the prefix2 with if2. This is done by including the related prefixes in the PBU/PBA message. Xue, et al. Expires January 1, 2013 [Page 8] Internet-Draft Multi-LMA flow mobility June 2012 +-----+ +-----+ +------+ +-----+ Internet | LMA1| | LMA2| | MAG | | MN | +-----+ +-----+ +------+ +-----+ | | | | | | flow X to | flow X to | flow X to | | pref1::lif | pref1::lif | pref1::lif | |<----------->|<-------------------------->|<----------->if1 | flow Y to | flow Y to | flow Y to | | pref2::lif | pref2::lif | pref2::lif | |<------------------------->|<------------>|<----------->if1 | | | | | | | | | | | | | MN powers on if2 and | | | performs L2 attachment | | | | | | | | |<------------if2 | | | PBU | | | | |<-------------| | | | | PBA | | | | |------------->| | | flow Y to | flow Y to | flow Y to | | pref2::lif | pref2::lif | pref2::lif | |<------------------------->|<------------>|<----------->if2 | | | | | Figure 3: Flow mobility signaling process of Scenario-(a) when a new attachment occurs.(PBU/PBA message) As the prefixes assigned to these sessions are only maintained in LMA2, the anchor of flow Y MUST not change at all. Both in these two cases, the path of flow Y between MAG and MN's interfaces is changeable, meanwhile the tunnel used to transmit the packets of flow Y between MAG and LMA2 is unaltered. And in both cases, only MAG is REQUIRED to update routing state, no more signaling exchange between LMA and MAG is needed. The binding cache entry at LMA SHOULD not make any change unless a PBU requests it to. 3.2.2. Different Interfaces with Different MAGs It is corresponding to Scenario-(b). It happens when different interfaces are attached to different MAGs and anchored to different LMAs. Each MAG only has the location knowledge of the interfaces attached to it, and each LMA only maintains the MAGs registered on it. In this scenario, one LMA( which the mobile flow anchored ) needs to send message to the target MAG beyond the charge to inform flow mobility, thus the LMA in charge of the target MAG can help forward the message sent by the source LMA. The communication Xue, et al. Expires January 1, 2013 [Page 9] Internet-Draft Multi-LMA flow mobility June 2012 between LMAs MUST be with the help of Mobile Node's Policy Profile existing in the PMIPv6 domain, which keeps the storage of Mobile Node's Identifier and the addresses of the LMAs on a per-interface basis, the mandatory fields of policy profile here SHOULD be extended as following: o The mobile node's identifier (MN-ID).It is unique for MN despite of the different interfaces. o The interface identifier (IF-ID). Under a MN-ID, it is unique for each interface. o The IPv6 address of the local mobility anchor(LMAA) When source LMA enables flow mobility, it firstly checks whether MN's other interfaces under the same LMA can take over these selected flows. If not, flow mobility in multi-LMA environment is enabled. Figure 4 shows an example of Scenario 2. MN is implemented with two different physical interfaces (if1 and if2), grouped in a logical one (lif).Each physical interface is attached to a different MAG and anchored to a different LMA. Initially, flow X(bound to pref1::/64) goes through path if1-MAG1-LMA1 and flow Y(bound to pref2::/64) goes through path if2-MAG2-LMA2. At a certain time, flow Y needs to be moved to the path if1-MAG1-LMA2. The anchor MUST not change after flow mobility. A new tunnel SHOULD be established between LMA2 and MAG1 to transmit packets of flow Y. But initially the LMA in one path has no knowledge of the interface and relative MAG in another path, and it needs the help of another LMA. To enable flow mobility, LMA2 MUST send request to Policy Profile to search for LMA information of a proper interface under the same MN-ID. LMA2 gets the address of LMA1 and IF1-ID after REQ-ACK message exchanging with policy profile. Xue, et al. Expires January 1, 2013 [Page 10] Internet-Draft Multi-LMA flow mobility June 2012 LMA1 Binding Cache +----+ +----+ ==================== |LMA1| |LMA2| MN, if1, pref1, MAG1 +----+ +----+ || || LMA2 Binding Cache +----||--------------||----+ ==================== ( || PMIPv6 || ) MN, if2, pref2, MAG2 ( || domain || ) +----||--------------||----+ || || +----+ +----+ |MAG1| |MAG2| +----+ +----+ | | | +-------+ | | | I P | | | +-------+ | | | lif | | | +---+---+ | |---|if1|if2|----| +---+---+ MN Figure4: Different interfaces with different MAGs and different LMAs. Figure 5 gives the first possible signaling process. LMA2 sends eFMI to LMA1, eFMI carries mobile node's identifier, interface identifier and the Flow Identification Mobility option (specified in [RFC6089]) which can convey prefix or full flow information, and the type of flow mobility operation (add flow). LMA1 picks the entry of Binding Cache Entry(BCE), matching the MN-ID and IF-ID carried in the request, and locates the corresponding MAG1. LMA1 simply forwards eFMI to MAG1. MAG1 constructs the reply eFMA with all the options that a PBU MUST contain, which is used for a new mobile access gateway MAG1 to register in LMA2. Optionally, LMA2 sends FMI, which is defined in[I-D.ietf-netext-pmipv6-flowmob], to remove the flow Y state at MAG2. Otherwise, the flow state at MAG2 will be removed upon timer expiration. Xue, et al. Expires January 1, 2013 [Page 11] Internet-Draft Multi-LMA flow mobility June 2012 +-----+ +-----+ +------+ +------+ +-----+ Internet | LMA1| | LMA2| | MAG1 | | MAG2 | | MN | +-----+ +-----+ +------+ +------+ +-----+ | | | | | | |flow X to | flow X to | flow X to | |pref1::lif| pref1::lif | pref1::lif | |<-------->|<---------------------->|<---------------------->if1 | flow Y to | flow Y to | flow Y to | | pref2::lif | pref2::lif | pref2::lif| |<--------------------->|<---------------------->|<--------->if2 | | | | | =========================================================== | || decision to move flow Y || | =========================================================== | | | | | | | |eFMI[MN1-ID,IF-ID,flow_info(Y),add] | | | |<-----------| | | | | | eFMI | | | | |------------------------>| | | | |eFMA[CoA1,ATT1,LL-ID...] | | | | |<------------------------| | | | | eFMA | | | | | |----------->| | | | | | | optional | | | | | FMI[MN1-ID,flow_info(Y),lft=0 | | | |----------------------->| | | | | FMA | | | | |------------------------| | | flow Y to | flow Y to | flow Y to | | pref2::lif | pref2::lif| pref2::lif | |<--------------------->|<---------->|<-------------------->if1 | | | | | | Figure5: Flow mobility signaling process 1 of Scenario-(b) when both interfaces are powered on initially.(eFMI signaling) Figure 6 gives the second possible signaling process. The LMA2 still needs to acquire the address of LMA1 and sends eFMI to inform flow mobility, however eFMA replied by MAG1 is sent to LMA2 straightly without the help of LMA1. MAG1 SHOULD query for the address of LMA2 from policy profile before it sends back eFMA. Optionally, LMA2 sends FMI, which is defined in[I-D.ietf-netext-pmipv6-flowmob], to remove the flow Y state at MAG2. Otherwise, the flow state at MAG2 will be removed upon timer expiration. Xue, et al. Expires January 1, 2013 [Page 12] Internet-Draft Multi-LMA flow mobility June 2012 +-----+ +-----+ +------+ +------+ +-----+ Internet | LMA1| | LMA2| | MAG1 | | MAG2 | | MN | +-----+ +-----+ +------+ +------+ +-----+ | | | | | | |flow X to | flow X to | flow X to | |pref1::lif| pref1::lif | pref1::lif | |<-------->|<---------------------->|<---------------------->if1 | flow Y to | flow Y to | flow Y to | | pref2::lif | pref2::lif | pref2::lif| |<--------------------->|<---------------------->|<--------->if2 | | | | | ============================================================ | || decision to move flow Y || | ============================================================= | | | | | | | | eFMI[MN1-ID,IF1-ID,flow_info(Y),add]| | | |<-----------| | | | | | eFMI | | | | |----------------------->| | | | | | eFMA[CoA1,ATT1,LL-ID...] | | | |<----------| | | | | | optional | | | | | FMI[MN1-ID,flow_info(Y),lft=0] | | | |----------------------->| | | | | FMA | | | | |<-----------------------| | | flow Y to | flow Y to | flow Y to | | pref2::lif | pref2::lif| pref2::lif | |<--------------------->|<--------->|<---------------------->if1 | | | | | | Figure6: Flow mobility signaling process 2 of Scenario-(b) when both interfaces are powered on initially.(eFMI signaling) Figure7 gives the third possible signaling process. After acquiring the address of LMA1 and IF1-ID, LMA2 sends the request to LMA1, LMA1 picks the entry that matches the MN-ID and IF1-ID in the request and locates MAG1. It replies with the address of MAG1 directly to LMA2. Then LMA2 can communicate with MAG1 straightly, without the help of LMA1. Optionally, LMA2 sends FMI, which is defined in[I-D.ietf- netext-pmipv6-flowmob], to remove the flow Y state at MAG2. Otherwise, the flow state at MAG2 will be removed upon timer expiration. Xue, et al. Expires January 1, 2013 [Page 13] Internet-Draft Multi-LMA flow mobility June 2012 +-----+ +-----+ +------+ +------+ +-----+ Internet | LMA1| | LMA2| | MAG1 | | MAG2 | | MN | +-----+ +-----+ +------+ +------+ +-----+ | | | | | | |flow X to | flow X to | flow X to | |pref1::lif| pref1::lif | pref1::lif | |<-------->|<---------------------->|<---------------------->if1 | flow Y to | flow Y to | flow Y to | | pref2::lif | pref2::lif | pref2::lif| |<--------------------->|<---------------------->|<--------->if2 | | | | | ============================================================ | || decision to move flow Y || | ============================================================ | | | | | | | | eFMI[MN1-ID,IF1-ID] | | | | |<-----------| | | | | | eFMA[CoA1]| | | | | |----------->| | | | | | | eFMI[MN1-ID,IF1-ID,flow_info(Y),add]| | | |---------->| | | | | | eFMA[CoA1,ATT1,LL-ID...] | | | |<----------| | | | | | optional | | | | | FMI[MN1-ID,flow_info(Y),lft=0] | | | |----------------------->| | | | | FMA | | | | |<-----------------------| | | flow Y to |flow Y to | flow Y to | | pref2::lif |pref2::lif | pref2::lif | |<--------------------->|<--------->|<---------------------->if1 | | | | | | Figure7: Flow mobility signaling process 3 of Scenario-(b)when both interfaces are powered on initially.(eFMI signaling) There is another case in Scenario-(b) showed in Figure 8 when a new interface if2 is powered on. Initially, Flow X goes through if1- MAG1-LMA1 and flow Y goes through if1-MAG1-LMA2. When MAG2 detects the new attachment, it sends PBU to LMA2 to creating a new binding entry. Since LMA2 manages both MAG1 and MAG2 after the registration, it becomes the case already have been discussed in [I-D.ietf-netext- pmipv6-flowmob]. Xue, et al. Expires January 1, 2013 [Page 14] Internet-Draft Multi-LMA flow mobility June 2012 +-----+ +-----+ +------+ +------+ +-----+ Internet | LMA1| |LMA2 | | MAG1 | | MAG2 | | MN | +-----+ +-----+ +------+ +------+ +-----+ | | | | | | |flow X to | flow X to | flow X to | |pref1::lif| pref1::lif | pref1::lif | |<-------->|<---------------------->|<---------------------->if1 | flow Y to | flow Y to | flow Y to | | pref2::lif | pref2::lif| pref2::lif | |<--------------------->|<--------->|<---------------------->if1 | | | | | | | | | | | | | | | | MN powers on if2 and | | | | performs L2 attachment | | | | |<----------if2 | | | PBU | | | | |<-----------------------| | | | | PBA (pref2) | | | | |----------------------->| | | | LMA moves pref2 to new| | | | |binding cache entry for if2 | | | | | | | | | | | | | | | | | (optional)| | | | | | BRI[pref2]| | | | | |---------->| | | | | | BRA | | | | | |<----------| | | | flow Y to | flow Y to | flow Y to | | pref2::lif | pref2::lif | pref2::lif| |<--------------------->|<---------------------->|<--------->if2 | | | | | | Figure 8: Flow mobility signaling process of Scenario-(b)when a new attachment occurs.(PBU signaling) 4. Select the Target Interface When MN has more than 2 different interfaces, the policy profile can selects an available target interface of the same MN for source LMA according to some rules, here we propose two possible ways: o Select an interface arbitrarily. Policy profile selects the first interface of all the other available interfaces under the same MN-ID as target interface. Source LMA Xue, et al. Expires January 1, 2013 [Page 15] Internet-Draft Multi-LMA flow mobility June 2012 sends request to the target LMA controlling the selected interface, the acknowledge contains the status of flow mobility. If the code indicates failure, then source LMA SHOULD sends request to policy profile to ask for another interface and repeat the steps before until find a proper one. o Select all the available interfaces as target ones. Policy profile selects all the other available interfaces under the same MN-ID as target interfaces. Source LMA sends request to each target LMA controlling each interface, asking for the load information. The acknowledge MUST contains Load Information Mobility Options to report the priority and key load information to source LMA. Then source LMA orders all the available target interfaces and picks a proper one. 5. Message Format 5.1. Enhance Flow Mobility Initiate(eFMI) The LMA sends an eFMI message to a MAG to enable flow mobility. eFMI is enhanced FMI, adding new bit M to indicate multi-LMA flow mobility, and the options it carries are more. It is a Mobility Header message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|M| Reserved | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number: A monotonically increasing integer. Set by the LMA sending then initiate message, and used to match a reply in the acknowledge. 'I' (initiate) flag: Xue, et al. Expires January 1, 2013 [Page 16] Internet-Draft Multi-LMA flow mobility June 2012 Set to 1, indicates it is an eFMI message. 'M' (multiple) flag: Set to 1, indicates it is multi-LMA flow mobility. Reserved: This field is unused. MUST be set to zero by the sender. Lifetime: The requested time in seconds for which the LMA asks the MAG keep flow-specific state. A value of all one bits (0xffff) represent infinity. If set to 0, it indicates a request to remove state about the flow (cancel flow mobility). Mobility Options: MUST contain the MN-ID, IF-ID, followed by one or more Flow Identification Mobility options [RFC6089]. 5.2. Enhanced Flow Mobility Acknowledge(eFMA) The MAG sends an eFMA message to the LMA as a response to the eFMI message. eFMA is enhanced FMI, adding new bit M to indicate multi-LMA flow mobility, the status and options are more. It is a Mobility Header message. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence # | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |I|M| Reserved | Status | Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | . . . Mobility options . . . | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sequence Number: A monotonically increasing integer. Set by the LMA sending then initiate message, and used to match a reply in the acknowledge. Xue, et al. Expires January 1, 2013 [Page 17] Internet-Draft Multi-LMA flow mobility June 2012 'I' (initiate) flag: Set to 0, indicates it is an eFMA message. 'M' (multiple) flag: Set to 1, indicates it is multi-LMA flow mobility. Reserved: This field is unused. MUST be set to zero by the sender. Status(values to be assigned by IANA): Despite of the already defined values in eFMI, the new values defined in multi-LMA environment are as following: ??: Target LMA not support flow mobility ??: No existing MAG ??: No existing interface Lifetime: The requested time in seconds for which the MAG keeps flow-specific state. A value of all one bits (0xffff) represents infinity. Mobility Options: When Status code is 0, MUST contain the MN-ID, followed by one or more Flow Identification Mobility options [RFC6089], and MUST include other regular options in a normal PBU. 6. Conceptual Data Structures 6.1. Multiple Care-of Address Registration The LMA is extended to allow a mobile node to register multiple proxy care of address (Proxy-CoA). The LMA maintains multiple binding cache entries for an MN. The number of binding cache entries for an MN is equal to the number of the MN's interfaces attaching to any MAGs. Xue, et al. Expires January 1, 2013 [Page 18] Internet-Draft Multi-LMA flow mobility June 2012 +---------+-----+-------+------+-----------+------------+ | BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA | +---------+-----+-------+------+-----------+------------+ | 20 | 1 | MN | WiFi | HNP1,HNP2 | IP1 (MAG1) | | 30 | 2 | MN | 3GPP | HNP1,HNP3 | IP2 (MAG2) | +---------+-----+-------+------+-----------+------------+ Figure 9: Extended Binding Cache Figure 9 shows two Binding Cache Entries of the MN when it is attached to the network using two different access technologies. Both of the two attachments share HNP1 and are bounded to two different Proxy-CoAs. 6.2. Flow Mobility Cache Each LMA MUST maintain a flow mobility cache (FMC) as shown in Figure 10. This table MUST contain an entry for each flow sent from the MN. A flow binding entry includes the following fields: o Flow Identifier Priority (FID-PRI). o Flow Identifier (FID). o Traffic Selector (TS). o Binding Identifier (BID). o Action. o Active/Inactive. +---------+-----+-----+------+---------+----------+ | FID-PRI | FID | TS | BIDs | Action | A/I | +---------+-----+-----+------+---------+----------+ | 10 | 2 | TCP | 1 | Forward | Active | | 20 | 4 | UDP | 1,2 | Forward | Inactive | +---------+-----+-----+------+---------+----------+ Figure 10: Flow Mobility Cache The BID field contains the identifier of the binding cache entry which packets matching the flow information described in the TS field will be forwarded to. When a flow is decided to be moved, the affected BID(s) of the table are updated. Xue, et al. Expires January 1, 2013 [Page 19] Internet-Draft Multi-LMA flow mobility June 2012 Similar to flow binding described in [RFC6089], each flow binding entry points to a specific binding cache entry identifier (BID). When a flow is moved, the LMA simply updates the pointer of the flow binding entry with the BID of the interface to which the flow will be moved. The traffic selector (TS) in flow binding table is defined as in [RFC6088]. TS is used to classify the packets of flows basing on specific parameters such as service type, source and destination address, etc. The packets matching with the same TS will be applied the same forwarding policy. FID-PRI is the order of precedence to take action on the traffic. Action may be forward or drop. If a binding entry becomes 'Inactive' it does not affect data traffic. An entry becomes 'Inactive' only if all of the BIDs are deregistered. The Mobile Access Gateway MAY also maintain a similar data structure. In case no full flow mobility state is required at the MAG, the Binding Update List (BUL) data structure is enough and no extra conceptual data entries are needed. In case full per-flow state is required at the MAG, it SHOULD also maintain a Flow Mobility Cache structure. 6.3. Mobile Node's policy profile There is Mobile Node's policy profile in a PMIPv6-Domain, MAY be implemented in AAA server. The mandatory fields of it SHOULD be extended as following: o The mobile node's identifier (MN-ID).It is unique for MN despite of the different interfaces. o The interface identifier (IF-ID). Under a MN-ID, it is unique for each interface. o The IPv6 address of the local mobility anchor(LMAA). 7. Security Considerations The protocol signaling extensions defined in this document share the same security concerns of Proxy Mobile IPv6 [RFC5213]. The new Enhanced Flow Mobility Initiate and Enhanced Flow Mobility Acknowledge messages exchanged between the mobile access gateway and the local mobility anchor MUST be protected using IPsec using the established security association between them. 8. References Xue, et al. Expires January 1, 2013 [Page 20] Internet-Draft Multi-LMA flow mobility June 2012 8.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. [RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K., and P. Yegani, "Binding Revocation for IPv6 Mobility", RFC 5846, June 2010. [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, January 2011. [RFC6089] Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support", RFC 6089, January 2011. [RFC6463] Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui, "Runtime Local Mobility Anchor (LMA) Assignment Support for Proxy Mobile IPv6", RFC 6463, February 2012. 8.2. Informative References [I-D.ietf-netext-logical-interface-support] Melia, T. and S. Gundavelli, "Logical Interface Support for multi-mode IP Hosts", draft-ietf-netext-logical-interface-support-05 (work in progress), April 2012. [I-D.ietf-netext-pmipv6-flowmob] Bernardos, C., "Proxy Mobile IPv6 Extensions to Support Flow Mobility", draft-ietf-netext-pmipv6-flowmob-03 (work in progress), March 2012. Xue, et al. Expires January 1, 2013 [Page 21] Internet-Draft Multi-LMA flow mobility June 2012 Authors' Addresses Kaiping Xue USTC Room 305, EEIS Department, USTC West Campus Shushan District, Hefei 230027 P. R. China Phone: +86-551-3601334 Email: kpxue@ustc.edu.cn Dan Ni USTC Room 305, EEIS Department, USTC West Campus Shushan District, Hefei 230027 P. R. China Phone: +86-551-3601334 Email: nidan@mail.ustc.edu.cn Peilin Hong USTC Room 305, EEIS Department, USTC West Campus Shushan District, Hefei 230027 P. R. China Phone: +86-551-3601334 Email: plhong@ustc.edu.cn H Anthony Chan Huawei 5340 Legacy Dr. Building 3 Plano, TX 75024 USA Email: h.a.chan@ieee.org Xue, et al. Expires January 1, 2013 [Page 22]