Network Working Group B. Sarikaya Internet-Draft F. Xia Expires: August 5, 2010 Huawei USA February 1, 2010 PMIPv6 Multihoming Support for Flow Mobility draft-sarikaya-netext-fb-support-extensions-00 Abstract This document specifies extensions to Proxy Mobile IPv6 (PMIPv6) for flow mobility support. Binding cache and binding update list are slighlty extended to allow indicating the home interface and other interfaces. 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 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 August 5, 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 Sarikaya & Xia Expires August 5, 2010 [Page 1] Internet-Draft PMIPv6 Support for Flow Mobility February 2010 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . 4 4. Multihoming Case . . . . . . . . . . . . . . . . . . . . . . . 4 5. LMA Operation . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1. Extensions to Binding Cache Entry . . . . . . . . . . . . . 5 6. MAG Operation . . . . . . . . . . . . . . . . . . . . . . . . . 6 6.1. Extensions to Binding Update List Entry Data Structure . . 6 7. Message Formats . . . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 9. IANA considerations . . . . . . . . . . . . . . . . . . . . . . 7 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 11.2. Informative references . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Sarikaya & Xia Expires August 5, 2010 [Page 2] Internet-Draft PMIPv6 Support for Flow Mobility February 2010 1. Introduction In Mobile IPv6 [RFC3775] multi-homing is supported efficiently due to the use of home address. Mobile node uses its home address 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 its active flows with the HA and 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. Proxy Mobile IPv6 [RFC5213] lacks a similar mechanism because each active interface is treated separately and a different binding cache entry is created. This document proposes changes necessary to the local mobility anchor (LMA) behaviour so that flow mobility can seamlessly be supported in PMIPv6. The changes to the mobile node considered in [I-D.yokota-netlmm-pmipv6-mn-itho-support] are also needed to complement our solution on the host side. 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], [I-D.ietf-mext-flow-binding] 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. Inter-technology handover: Sometimes called vertical handover. A multi-homed MN communicates with one interface at any time to conserve power. Each interface can support different access technology. Inter-technology handover occurs when MN moves out of coverage of one technology and moves into the coverage area of another technology which will result in switching of the communicating interface on MN [I-D.yokota-netlmm-pmipv6-mn-itho-support]. Sarikaya & Xia Expires August 5, 2010 [Page 3] Internet-Draft PMIPv6 Support for Flow Mobility February 2010 3. Problem Statement When MN connects simultaneously with multiple interfaces each interface is treated independently and MN uses different source addresses when sending packet over these interfaces. 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. When MN does an inter-technology handover, the new MAG sends a Proxy Binding Update (PBU) message to the local mobility anchor (LMA) to register the new proxy care-of address. In the PBU, MAG sets the access technology type (ATT) and handoff indicator (HI) values. If ATT is different from the one stored in the existing binding cache entry for this MN and if HI is set to 2 (Handoff between two different interfaces of the mobile node), LMA concludes that an inter-technology handover happened and assigns the same home network prefix(es) to MN which enables IP session continuity. Setting the access technology type correctly might prove easier for MAGs that are connected to a single technology. Currently this could be the most popular case. However with the advent of fixed mobile convergence this is likely to change. MAGs in the future are expected to serve more than one access technologies. Setting the handoff indicator correctly is also not so easy. Most MAGs would tend to set HI to 1 (Attachment over a new interface) which would result in LMA setting new prefix(es) to MN and creating a new binding cache entry and allocating a new mobility session for this new interface. This behaviour as described in Section 5.4 of [RFC5213] needs to be changed. 4. Multihoming Case 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" to all home network prefixes assigned to this interface. Also this flag is set in the binding Sarikaya & Xia Expires August 5, 2010 [Page 4] Internet-Draft PMIPv6 Support for Flow Mobility February 2010 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 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. 5. LMA Operation When LMA receives a Binding Update meesage 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. The flag MUST be assigned to "S". This binding cache entry becomes part of the binding cache entry that contains home network prefixes with "H" flag. LMA sends home network prefixes assigned to the new interface in the Binding Acknowledgement message. LMA MUST also set the flag to "S". In the same BA message, LMA also sends home network prefixes whose associated flag is "H" 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 A flag associated with the following binding cache entry: list of IPv6 home network prefixes assigned to the mobile node's connected interface. The flag is set to "H" if the connected interface is the home interface and is set to "S" if the connected interface is not. The prefixes assigned after the first PBU is received for MN are assigned "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 Sarikaya & Xia Expires August 5, 2010 [Page 5] Internet-Draft PMIPv6 Support for Flow Mobility February 2010 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. LMA decides to which interface to route this packet by consulting the flow binding entries list, similar to the case in Mobile IPv6 [I-D.ietf-mext-flow-binding]. The packet will be matched against the flow descriptions in the flow binding entries list 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 corrsponding binding update list entry. 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 flag is set to "H" if the connected interface is the home interface and is set to "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". 7. Message Formats Home Network Prefix Option defined in [RFC5213] is modified to include a flag to indicate if home network prefixes are assocaited with "H" flag or "S" flag in the binding cache entries. Sarikaya & Xia Expires August 5, 2010 [Page 6] Internet-Draft PMIPv6 Support for Flow Mobility February 2010 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 when this prefix is assigned to a secondary interface of the mobile node and when the binding cache entry for this HNP has "S" flag set. This flag is not set when this prefix is assigned to the firstly connecting or the only connected interface of the mobile node and 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 TBD. 10. Acknowledgements TBD. 11. References Sarikaya & Xia Expires August 5, 2010 [Page 7] Internet-Draft PMIPv6 Support for Flow Mobility February 2010 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. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [I-D.yokota-netlmm-pmipv6-mn-itho-support] Yokota, H., Gundavelli, S., and K. Leung, "Inter- Technology Handoff support in Mobile Node for Proxy Mobile IPv6", draft-yokota-netlmm-pmipv6-mn-itho-support-02 (work in progress), October 2009. [I-D.ietf-mext-flow-binding] Soliman, H., Tsirtsis, G., Montavont, N., Giaretta, G., and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO Basic Support", draft-ietf-mext-flow-binding-04 (work in progress), November 2009. 11.2. Informative references [I-D.ietf-netlmm-pmip6-ipv4-support] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17 (work in progress), September 2009. Sarikaya & Xia Expires August 5, 2010 [Page 8] Internet-Draft PMIPv6 Support for Flow Mobility February 2010 Authors' Addresses Behcet Sarikaya Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: sarikaya@ieee.org Frank Xia Huawei USA 1700 Alma Dr. Suite 500 Plano, TX 75075 Phone: +1 972-509-5599 Email: xiayangsong@huawei.com Sarikaya & Xia Expires August 5, 2010 [Page 9]