Host Initiation for Flow Mobility in PMIPv6
draft-han-netext-host-initiation-flow-mobility-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 of flow movement to an attached mobile access gateway, which then relays it to a local mobility anchor.

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 June 27, 2011.

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 Simplified BSD License.

Table of Contents

1.  Introduction
2.  Terminology
3.  Protocol Operation
4.  Security Considerations
5.  References
    5.1.  Normative References
    5.2.  Informative References
§  Authors' Addresses

1.  Introduction

The PMIPv6 (Proxy Mobile IPv6) [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.) 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 mobile access gateways (MAGs), it is expected that a proper interface can be chosen by the local mobility anchor (LMA) to deliver the data. Currently, NETEXT WG tries to make a standard of the flow mobility management in PMIPv6. By the flow mobility it means that the mobility management function classifies the packets at flow level and distributes them to the proper interface(s) of an MN, and then applies the same policy to the packets that has the same flow information.

There are two proposals [I-D.draft-bernardos-netext-pmipv6-flowmob], [I-D.draft-trung-netext-flow-mobility-support] for supporting the flow mobility in PMIPv6. However, the two proposals allow only network-side functionalities (LMA or MAG) to control the flow mobility and distribute flows to proper interfaces of MNs. A problem of them is that the MN wishes to receive a flow traffic through a particular interface1, but LMA does not know such a MN's wish exactly in real-time manner. By the multiple CoA registration [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.) and the flow mobility support [I-D.draft-ietf-mext-flow-binding], the Mobile IPv6 [RFC3775] (Johnson, D., Perkins, C., and J. Arkko, “Mobility Support in IPv6,” June 2004.) 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 the host-based flow mobility, 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-bernardos-netext-pmipv6-flowmob] specifies a protocol between the LMA and MAGs to handover one or more service flows from an interface to another. Flow mobility signaling takes place whenever the LMA decides to move a flow. There are two flow mobility scenarios: "shared prefix" and "unique prefix". While no specific signaling is required for flow mobility in the shared prefix scenario, flow information including required prefix(es) should be exchanged between the LMA and MAGs to support flow mobility in the unique prefix scenario. [I-D.draft-trung-netext-flow-mobility-support] also specifies a flow mobility protocol between the LMA and MAGs, and the LMA is also the decision functionality for flow movement in the proposal. It proposes two types of signaling: "proactive" and "reactive". In proactive signaling, all the prefixes are shared over all MAGs in advanced and thus additional signaling for flow movement is not needed. In reactive signaling, prefix information is delivered from LMA to MAG when it should be required to a particular MAG to tunnel a new flow moved from an old MAG.

Although the above proposals specify good network-controlled protocols to bind flows to MN's interface, they do not describe how to receive the MN's intention about flow distribution. Actually, a pure network-controlled protocol excluding the MN's involvement 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 manner.

This document specifies how MNs send their intention about flow distribution to the attached MAG, which then relays it to the LMA. The proposed scheme does not violate the PMIPv6's inherent policy. That is, basic flow mobility management follows the network-controlled flow management protocol which will be made as IETF standard, so that creation and management of flow binding are performed in network-side functionalities (LMA or MAG). 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

The terminology in this document is based on the definitions in [RFC5213] (Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, “Proxy Mobile IPv6,” August 2008.), [RFC5648] (Wakikawa, R., Devarapalli, V., Tsirtsis, G., Ernst, T., and K. Nagami, “Multiple Care-of Addresses Registration,” October 2009.), 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 management. The LMA or the MAG will perform the operations based on the future IETF standard for network-based flow mobility.

When a flow binding is initially created in network-side, the LMA (or MAGs) 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. After the flow binding information is exchanged by the MAG and the LMA by using a protocol defined by the future IETF standard, the MAG sends a router advertisement message to the MN in unicast manner (in PMIPv6, router advertisement message should be sent in unicast manner). This router advertisement message carries the created flow identifier and the corresponding flow information tuple (for example, 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.

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 or user's decision. 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 of the 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 the future IETF standard for flow mobility. If the future IETF standard does not have a protocol where MAG initiates the flow mobility, it is needed that MAG forwards the MN's flow mobility intention to the LMA. It is noted that the MN's intention should be analyzed at the LMA and the LMA can allow or disallow the flow mobility.

The following Figure 1 depicts the proposed procedure.

MN-IF1          MN-IF2         New MAG        Old MAG            LMA
  |               |              |              |                |
  |--------New Attachment------->|              |                |
  |               |              |-------------PBU-------------->|
  |               |              |<------------PBA---------------|
  |               |              |              |                |
  |               |              |      Network-controlled       |
  |               |              |<===Flow Binidng Management===>|
  |<----Router Advertisement-----|              |                |
  | (Flow-ID, Flow Binding Info.)|              |                |
  |               |              |<~~~~~~~~~Service Flow~~~~~~~~>|
  |<~~~~~~~Service Flow~~~~~~~~~>|              |                |
  |               |              |              |                |
  |               |              |              |                |
  |               |              |              |                |
  |               |-----Router Solicitation---->|    Network-    |
  |               |          (Flow-ID)          |   controlled   |
  |               |              |              |<==== Flow ====>|
  |               |              |              |     Binding    |
  |               |              |              |   Management   |
  |               |              |              |                |
  |               |              |              |<~~~~Service~~~>|
  |               |<~~~~~~~Service Flow~~~~~~~~>|      Flow      |
  |               |              |              |                |

The proposed MN-initiated flow mobility

4.  Security Considerations

TBD

5.  References

5.1. Normative References

5.2. Informative References

Authors' Addresses