Network Working Group B. Sarikaya Internet-Draft Huawei Expires: March 28, 2013 September 24, 2012 PMIPv6 Multihoming Support Extensions for Flow Mobility draft-sarikaya-netext-flowmob-ext-00 Abstract Base Proxy Mobile IPv6 multihoming support treats each active interface of the Mobile Node separately and creates a different binding cache entry for each interface. This is similar to Mobile IPv6 restricting only one care-of address to be registered with the home agent and this restriction which did not allow flow mobility between interfaces has been removed by allowing multiple care-of address registration. In this document we specify a similar solution for Proxy Mobile IPv6 (PMIPv6) to support flow mobility among simultaneously connected interfaces. Binding cache, binding update list and home network prefix option are slighlty extended to allow indicating the home interface and other interfaces. 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 March 28, 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 publication of this document. Please review these documents Sarikaya Expires March 28, 2013 [Page 1] Internet-Draft PMIPv6 Support for Flow Mobility September 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 4. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 5 5. LMA Operation . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Extensions to Binding Cache Entry . . . . . . . . . . . . 6 6. MAG Operation . . . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Extensions to Binding Update List Entry Data Structure . . 7 6.2. MN Operation . . . . . . . . . . . . . . . . . . . . . . . 7 7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . . 9 11.2. Informative references . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Sarikaya Expires March 28, 2013 [Page 2] Internet-Draft PMIPv6 Support for Flow Mobility September 2012 1. Introduction Mobile IPv6 (MIPv6) previously allowed registering only one care-of address called primary care-of address with the home agent of a Mobile Node (MN). The underlying assumption was that only one interface would be activated at a given time. This restriction has been removed by allowing multiple care-of addresses to be registered as in [RFC5648]. RFC5648 makes the distinction among the interfaces of MN attached to the home link and all other interfaces attached to the visited link(s). Home link has the home address and the visited links have care-of addresses. A short value (16 bits) called Binding ID or BID is used to identify each care-of address. MN sends Binding Update message with Binding Identifier Mobility Option to register these care-of addresses each assigned a unique BID. HA creates separate binding cache entries connected to the home address for each distict BID representing an active interface of MN connected to a visited link. Mobile node uses its home address, i.e. the address of the interface attached to the home link as the source address and all incoming traffic is directed to the home address (HoA). When multiple interfaces are concurrently active, the home agent (HA) has to decide how to route incoming packets to different active interfaces. HA does this based on the flow bindings. MN has to register in a BU its active flows with the HA using Flow Identification Mobility Option associating the flow with one or more registered BIDs HA keeps flow binding entries for each HoA. HA then forwards packets to one of the care-of addresses of an active interface after matching it with an ordered list of flow bindings [RFC6089]. Proxy Mobile IPv6 [RFC5213] lacks a similar mechanism because each active interface is treated separately and a different binding cache entry is created. This restriction is similar to MIPv6 not allowing to register more than one care-of addresses with the HA. Handoff between two different interfaces is allowed in multihoming support of PMIPv6 as long as two different interfaces do not remain active simultaneously. This document proposes changes necessary to the local mobility anchor (LMA) and Mobility Access Gateway (MAG) behaviour so that flow mobility can seamlessly be supported in PMIPv6. The changes to the mobile node are also needed to complement our solution on the host side [I-D.ietf-netext-logical-interface-support]. Sarikaya Expires March 28, 2013 [Page 3] Internet-Draft PMIPv6 Support for Flow Mobility September 2012 2. Terminology 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]. The terminology in this document is based on the definitions in [RFC5213], [RFC6089] in addition to the ones specified in this section: Single-Radio MN: Consider MN with two interfaces. These interfaces are implemented in such a way that MN can keep one radio module (interface) active at a given time. Dual/multiple-Radio MN: Consider MN with two interfaces. These interfaces are implemented in such a way that both radio modules can receive and transmit simultaneously. This specification applies to multi-radio MNs. 3. Problem Statement In base Proxy Mobile IPv6 when MN connects simultaneously with multiple interfaces each interface is treated independently and MN uses different source addresses when sending packets over these interfaces [RFC5213]. In base Proxy Mobile IPv6 [RFC5213] LMA treats each interface independently of the other interface(s) MN may have and tries to provide mobility support for each interface. When LMA receives Proxy Binding Update (PBU) from a MAG it creates a new binding cache entry and allocates a new mobility session for this new interface. In case of inter-technology handover, LMA does not create a new binding cache entry but it assigns the same home network prefix(es) to the new interface. This binding cache entry represents the new interface and it replaces the previous interface. Assigning the same HNPs enables IP session continuity between these two interfaces. LMA does not manage bindings from different interfaces of the mobile node in an integrated fashion because the assumption is that only one interface is active at a given time. So LMA can not be in control of moving the flows between different interfaces. The solution to this is to modify the way the binding cache is managed. Instead of creating an independent mobility session for each interface, the bindings from each simultaneously active interface are kept together so that the flows can be moved among interfaces. The extensions to the base protocol needed for this Sarikaya Expires March 28, 2013 [Page 4] Internet-Draft PMIPv6 Support for Flow Mobility September 2012 should be minimal. As in Mobile IPv6 [RFC5648], the distinction should be made of the interfaces connected to the home link or to the visited link(s). In this specification we call them home and secondary links/ interfaces, respectively. Binding Identifier or BID is not used. BID is mainly defined for multiple-interfaced mobile nodes with Mobile IPv6 functionalities. The BID is an identification number used to distinguish multiple bindings registered by the mobile node. Each BID is generated and managed by a mobile node in Mobile IPv6. In Proxy Mobile IPv6, mobility management of mobile nodes with multiple interfaces is run in different independent MAGs, and BID loses its meaning. However in case of flow mobility, MN itself or LMA might wish to move one flow from one interface to the other. When a flow is moved from interface A to interface B, MN has to stop sending packets on interface A, i.e. it should set the source address to an address based on HNPs assigned to interface B. Forcing an MN to do this after a flow is moved is difficult currently and is one of the problems PMIPv6 flow mobility is facing. The solution for this is to let MN always use a source address from HNPs assigned to its home interface. When multiple interfaces are active, incoming packets can be directed to different active interfaces based on flow state established at LMA. 4. Solution Overview When there is attachment over a new interface (HI value received in the Binding Update from MAG is 1) LMA creates a new binding cache entry and assigns the flag "S" defined in Section 5.1 to all home network prefixes assigned to this interface. Also the corresponding value is set to the (H) flag of the home network interface option defined in Section 7 in the binding acknowledgement sent to MAG. LMA MUST also include the home network prefixes with "H" flag in the BA message. This should enable MN continue to send packets with source addresses selected from HNPs with "H" flag on. The new binding cache entry does not create a new mobility session. The entry is considered as a pointer to another binding the same MN has with LMA. MN may have as many such binding entries as it has active interfaces. These secondary binding cache entries are refreshed regularly by MAGs sending BUs. MAG MUST include HNPs both with "H" and "S" flags in the BU message. LMA refreshes the binding cache entry for the interface with only "S" flag. Sarikaya Expires March 28, 2013 [Page 5] Internet-Draft PMIPv6 Support for Flow Mobility September 2012 5. LMA Operation When LMA receives a Binding Update message which contains Handoff Indication set to a value of 1 LMA MUST create a new binding cache entry and assign new home network prefixes for this interface. In the binding cache entry these HNPs MUST be flagged with a value of 0 representing "S". This binding cache entry becomes part of the binding cache entry that contains home network prefixes with "H" flag. "H" and "S" flags are as defined in Section 5.1. LMA sends home network prefixes assigned to the new interface in the Binding Acknowledgement message. LMA MUST also set the (H) Flag in HNP option to 0. In the same BA message, LMA MAY also send home network prefixes whose (H) flag is set to 1 in the same BA. The modifications specified in this document allow a mobile node to have a single interface connected at a given moment and that interface has prefixes assigned an "S" flag, i.e. the binding with the home interface may have expired. In this case LMA MUST also store the home network prefixes with "H" flag in the binding cache entry. 5.1. Extensions to Binding Cache Entry One flag associated with the following binding cache entry: list of IPv6 home network prefixes assigned to the mobile node's connected interface and prefix length. The flag is set to 1 representing "H" if the connected interface is the home interface and flag is set to 0 representing "S" if the connected interface is not the home interface but it is one of the secondary interfaces. The prefixes assigned after the very first PBU is received for this MN are assigned the "H" flag. The handoff between two different interfaces does not require the prefixes to be changed in order to allow session continuity. Because of this the flag (of "H" or "S") associated with the prefixes stays the same. This specification also brings the change that binding cache entries for the same MN-Identifier are considered together. The number of entries is equal to the number of active interfaces of MN. If there is a single entry it is assumed that the flag value is "H", otherwise the prefixes with "H" flag should also be stored in the binding cache entry. For an incoming packet, the destination address MUST be selected from the set of prefixes with "H" flag, i.e. MN always sends non-local packets with source address assigned from HNPs of its home interface. LMA decides to which interface to route this packet by consulting the Sarikaya Expires March 28, 2013 [Page 6] Internet-Draft PMIPv6 Support for Flow Mobility September 2012 flow mobility cache [I-D.ietf-netext-pmipv6-flowmob], similar to the case in Mobile IPv6 [RFC6089]. The packet will be matched against the flow descriptions [RFC6088] in the flow mobility cache and Proxy- CoA of the matching entry will be determined. Next, binding cache entry for this MN will be searched and the packet will be directed to the MAG to which the matching interface is connected. 6. MAG Operation When MAG detects an attachment over a new interface it sets Handoff Indicator field to 1 as described in [RFC5213] in the Binding Update message that it sends to LMA. MAG MUST store home network prefixes it receives in Binding Acknowledgement message from LMA together with the flag in the binding update list entry. If the flag is "S" MAG MUST also store all home network prefixes in the BA message whose flag is "H" in the corresponding binding update list entry. There will be a maximum of two sets of HNPs for each MN if the MAG is not connected to the home interface. MAG receives packets from LMA, decapsulates them and searches the binding update list to find the corresponding entry (with the "H" flag) and sends them to the MN with the corresponding "S" flag. 6.1. Extensions to Binding Update List Entry Data Structure A flag associated with the following binding update list entry: list of IPv6 home network prefixes assigned to the mobile node's connected interface the corresponding prefix length. The flag is set to 0 representing "H" if the connected interface is the home interface and is set to 1 representing "S" if the connected interface is not. MAG MUST also store the home network prefixes with flag "H" in addition to the prefixes associated with the connected interface if the flag of the home network prefix assigned to the connected interface is "S". MAG determines these flag values from the home network prefix option's (H) flag. 6.2. MN Operation MN moves into PMIPv6 domain and gets connected to its home link. MN roams in PMIPv6 domain as described in Section 7 of [RFC5213]. When MN connects to a secondary link simultaneously with the home link MN MUST use a source address from HNPs assigned to its home link in its communication with the correspondent nodes. Sarikaya Expires March 28, 2013 [Page 7] Internet-Draft PMIPv6 Support for Flow Mobility September 2012 7. Message Formats Home Network Prefix Option defined in [RFC5213] is modified to include a flag to indicate if home network prefixes are associated with "H" flag or "S" flag in the binding cache entries. This specification extends the Home Network Prefix Option with a new flag. The flag is shown and described below. All other fields are as described in [RFC5213]. 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 |H| Reserved | Prefix Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Home Network Prefix + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Home Network Prefix Option H Flag This flag is set to 1 when this prefix is assigned to a secondary interface of the mobile node, i.e. when the binding cache entry for this HNP has "S" flag set. This flag is set to 0 when this prefix is assigned to the firstly connecting or the only connected interface of the mobile node, i.e. when the binding cache entry for this HNP has "H" flag set. 8. Security Considerations This document does not define any new security issues. PMIPv6 security procedures apply. 9. IANA considerations IANA is requested to add the H Flag into the reserved field in Home Network Prefix Option defined in Section 8.3 in [RFC5213] as the first bit, i.e. Bit number 16 and change the Reserved (R) field as follows: Sarikaya Expires March 28, 2013 [Page 8] Internet-Draft PMIPv6 Support for Flow Mobility September 2012 This 7-bit field is unused for now. The value MUST be initialized to 0 by the sender and MUST be ignored by the receiver. 10. Acknowledgements The authors thank Hidetoshi Yokota who provided valuable comments. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, June 1999. [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 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. [RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont, "Traffic Selectors for Flow Bindings", RFC 6088, January 2011. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009. 11.2. Informative references [I-D.ietf-netext-pmipv6-flowmob] Bernardos, C., "Proxy Mobile IPv6 Extensions to Support Flow Mobility", draft-ietf-netext-pmipv6-flowmob-04 (work in progress), July 2012. [I-D.ietf-netext-logical-interface-support] Melia, T. and S. Gundavelli, "Logical Interface Support for multi-mode IP Hosts", Sarikaya Expires March 28, 2013 [Page 9] Internet-Draft PMIPv6 Support for Flow Mobility September 2012 draft-ietf-netext-logical-interface-support-05 (work in progress), April 2012. Sarikaya Expires March 28, 2013 [Page 10] Internet-Draft PMIPv6 Support for Flow Mobility September 2012 Author's Address Behcet Sarikaya Huawei 5340 Legacy Dr. Plano, TX 75024 Email: sarikaya@ieee.org Sarikaya Expires March 28, 2013 [Page 11]