Host Initiation for Flow Mobility in PMIPv6

The PMIPv6 (Proxy Mobile IPv6) 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 and the flow mobility support [I-D.draft-ietf-mext-flow-binding], the Mobile IPv6 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.

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. The terminology in this document is based on the definitions in , , and [I-D.draft-ietf-mext-flow-binding].

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.

| | | | | |-------------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

TBD