NETEXT WG Y. Han Internet-Draft KUT Intended status: Informational B. Ahn Expires: July 1, 2010 Y. An Network Research Division, ETRI December 28, 2009 Network-controlled and Host-initiated Flow Management in PMIPv6 draft-han-netext-nchi-flowmngt-00 Abstract Multihomed mobile nodes are capable of simultaneous attachment to multiple access networks. In this case, a PMIPv6-enabled local mobility anchor should distribute the application traffic to a proper access network which the mobile nodes wish to receive from. This document specifies how mobile nodes send their desire to the attached mobile access gateway, which then relays it to a local mobility anchor. 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 July 1, 2010. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. Han, et al. Expires July 1, 2010 [Page 1] Internet-Draft Host Flow Management in PMIPv6 December 2009 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Normative References . . . . . . . . . . . . . . . . . . . 6 5.2. Informative References . . . . . . . . . . . . . . . . . . 6 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Han, et al. Expires July 1, 2010 [Page 2] Internet-Draft Host Flow Management in PMIPv6 December 2009 1. Introduction The PMIPv6 (Proxy Mobile IPv6) [RFC5213] protocol provides local mobility management to a mobile node (MN) without requiring any modification of the MN. If an MN has multiple interfaces and does simultaneous attachment to multiple access networks, it is expected that a proper interface can be chosen by the MN to deliver the data. For the multihomed MN, the local mobility anchor (LMA) will assign different home network prefix(es) (HNPs) to multiple interfaces of the MN and manage the MN's binding state properly. The problem is if the MN wishes to receive a flow traffic bound to HNP1 through interface1 (IF1), but LMA does not know such a MN's wish exactly in real-time manner. By multiple CoA [RFC5648] and flow identifier [I-D.draft-ietf-mext-flow-binding] supports, the Mobile IPv6 [RFC3775] is extended to allow the binding of a particular flow to a care-of address without affecting other flows using the same home address. In this schemes, an MN itself sends the binding identifier and the associated flow identifier to the home agent. Therefore, the home agent becomes to know the exact MN's intention about flow distribution and each flow of the MN's multiple interfaces can be separately forwarded according to the binding identifier and the flow identifier managed in the binding cache. [I-D.draft-koodli-netext-flow-handover] specifies a protocol between the LMA and a mobile access gateway (MAG) to handover one or more service flows from an interface to another. In this scheme, when a new service flow arrives at the LMA, the LMA verifies whether the flow is "best-mapped" to MN's interfaces that could serve them. This verification serves as a flow handover trigger which is delivered to MAG. While this scheme allows the LMA to have the flow handover control logic, [I-D.draft-hui-netext-service-flow-identifier] lets a MAG control the flow handover. The latter document defines a new option, called Service Flow Identifier option, to carry the service flow identifier and service flow attributes in the Proxy Binding Update and Acknowledgement messages. An MAG binds MN's each service flow to the proper HNP, and notifies the created flow binding information to LMA. Although the above proposals specify good network-controlled protocols to bind service flows to MN's interface, they do not describe how to receive the MN's intention about flow distribution. Actually, the pure network-controlled protocol excluding the MN's involvement completely cannot support such a function. However, host-controlled MIPv6 does well support it and the home agent can distribute service flows according to MN's intention in a real-time Han, et al. Expires July 1, 2010 [Page 3] Internet-Draft Host Flow Management in PMIPv6 December 2009 manner. This document specifies how MNs send their intention about flow distribution to the attached MAG, which then relays it to a local mobility anchor. The proposed scheme does not violate the PMIPv6's inherent policy. That is, basic flow mobility management follows the network-controlled flow managment protocol which will be made as IETF standard based on [I-D.draft-koodli-netext-flow-handover] and [I-D.draft-hui-netext-service-flow-identifier], so that creation and management of flow binding are performed in network-side nodes (MAG or LMA). There are no messages newly defined in this document. MN just notifies its intention to MAG by exchanging the existing router solicitation and advertisement messages with MAG. 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 RFC 2119 [RFC2119]. The terminology in this document is based on the definitions in [RFC5213], [RFC5648], and [I-D.draft-ietf-mext-flow-binding]. 3. Protocol Operation In PMIPv6, an MN is not directly involved with mobility management and the binding information is created and managed by an MAG and the LMA. Therefore, an MN cannot be also involved with flow binding creation and management. The LMA or the MAG will perform the operations based on [I-D.draft-koodli-netext-flow-handover] or [I-D.draft-hui-netext-service-flow-identifier]. When a flow binding is initially created in network-side, the MAG or the LMA determines which interface of the MN is "best-mapped" to the current service flow based usually on the MN policy, which is stored in somewhere in operator network. When the flow binding information is exchanged by the MAG and the LMA by using a protocol defined by [I-D.draft-koodli-netext-flow-handover] or [I-D.draft-hui-netext-service-flow-identifier], the MAG sends a router advertisement message to the MN in unicast manner (in PMIPv6, router advertisement message should be sent in unicase manner). This router advertisement message carries the created flow identifier and the corresponding flow information tuple (including the IPv6 HNP/IPv4 HoA, transport protocol port numbers and QoS parameters for uplink and downlink). When the MN receives such a router advertisement message, it stores the flow binding information internally. Han, et al. Expires July 1, 2010 [Page 4] Internet-Draft Host Flow Management in PMIPv6 December 2009 Sometimes, an MN wishes to move a service flow from the current interface to other interface. This flow handover can be caused by the MN-internal decision or user's interim decision, etc. At this time, the MN sends the router solicitation message to the MAG via the new interface from which the MN wishes to receive the flow traffic. In PMIPv6, the MAG acts as the default router on the point-to-point link shared with the MN. So, the router solicitation message will be directly sent to the MAG. This router solicitation message carries the flow identifier and the corresponding flow information tuple of the service flow which the MN intends to move from the current interface to the new interface. When receiving such a router solicitation including service flow information, MAG does perform the network-controlled flow handover operations based on [I-D.draft-koodli-netext-flow-handover] or [I-D.draft-hui-netext-service-flow-identifier]. The following Figure 1 depicts the proposed procedure. MN-IF1 MN-IF2 Previous MAG New MAG LMA | | | | | |-----New Attachment----->| | | | | |-----------PBU------------>| | | |<----------PBA-------------| | | | | | | | | Network-controlled | |~~~~New Service Flow~~~~>|<=Flow Binidng Management=>|<~~ New |<--Router Advertisement--| | | Service | (Flow Binding Info.) | | | Flow | | |<~~~~~~Service Flow~~~~~~~>| |<~~~~~Service Flow~~~~~~>| | | | | | | | | | | | | | | | | | | |---Router Solicitation-->| Network- | | | (Flow Binding Info.) | controlled | | | | |<=== Flow ===>| | | | | Binding | | | | | Management | | | | | | | | | |<~~~Service~~>| | |<~~~~~Service Flow~~~~~~>| Flow | | | | | | The proposed MN-initiated flow distribution Figure 1 Han, et al. Expires July 1, 2010 [Page 5] Internet-Draft Host Flow Management in PMIPv6 December 2009 4. Security Considerations TBD 5. References 5.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. [RFC5648] Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, "Multiple Care-of Addresses Registration", RFC 5648, October 2009. 5.2. Informative References [I-D.hui-netext-service-flow-identifier] Hui, M., Chen, G., and H. Deng, "Service Flow Identifier in Proxy Mobile IPv6", draft-hui-netext-service-flow-identifier-01 (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. [I-D.koodli-netext-flow-handover] Koodli, R. and K. Chowdhury, "Flow Handover for Proxy Mobile IPv6", draft-koodli-netext-flow-handover-01 (work in progress), October 2009. Han, et al. Expires July 1, 2010 [Page 6] Internet-Draft Host Flow Management in PMIPv6 December 2009 Authors' Addresses Youn-Hee Han KUT Gajeon-Ri, 307, Byeongcheon-Myeon Cheonan, Chungnam Korea Phone: +82 41 560 1486 Email: yhhan@kut.ac.kr Byung-Jun Ahn Network Research Division, ETRI Jeonmin-Dong, Yusung-Go Deajoen, Chungnam Korea Email: bjahn@etri.re.kr Yoon-Young An Network Research Division, ETRI Jeonmin-Dong, Yusung-Go Deajoen, Chungnam Korea Email: yyahn@etri.re.kr Han, et al. Expires July 1, 2010 [Page 7]