Proxy Mobile IPv6 Extensions to Support Flow Mobility
draft-ietf-netext-pmipv6-flowmob-02
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (netext WG) | |
|---|---|---|---|
| Author | Carlos J. Bernardos | ||
| Last updated | 2011-10-30 (Latest revision 2011-09-07) | ||
| Stream | Internet Engineering Task Force (IETF) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | WG state | WG Document | |
| Document shepherd | Basavaraj Patil | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-ietf-netext-pmipv6-flowmob-02
NETEXT Working Group CJ. Bernardos, Ed.
Internet-Draft UC3M
Intended status: Standards Track October 30, 2011
Expires: May 2, 2012
Proxy Mobile IPv6 Extensions to Support Flow Mobility
draft-ietf-netext-pmipv6-flowmob-02
Abstract
Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy
Mobile IPv6 domain through different interfaces. However, the
ability of movement of selected flows from one access technology to
another is missing in the basic Proxy Mobile IPv6 protocol. This
document describes enhancements to the Proxy Mobile IPv6 protocol
that are required to support network based flow mobility over
multiple physical interfaces.
This document assumes that the mobile node implements the logical
interface model, therefore allowing the support of traffic flows on
different physical interfaces regardless of the assigned prefixes on
these physical interfaces.
Requirements Language
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].
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 May 2, 2012.
Copyright Notice
Bernardos Expires May 2, 2012 [Page 1]
Internet-Draft PMIPv6 flow mobility October 2011
Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview of the PMIPv6 flow mobility extensions . . . . . . . 4
3.1. Use case scenarios . . . . . . . . . . . . . . . . . . . . 4
3.2. Basic Operation . . . . . . . . . . . . . . . . . . . . . 6
3.2.1. MN sharing a common set of prefixes on all MAGs . . . 6
3.2.2. MN with different sets of prefixes on each MAG . . . . 9
4. Message formats . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Flow Mobility Initiate (FMI) . . . . . . . . . . . . . . . 13
4.2. Flow Mobility Acknowledge (FMA) . . . . . . . . . . . . . 14
5. Conceptual Data Structures . . . . . . . . . . . . . . . . . . 15
5.1. Multiple Care-of Address Registration . . . . . . . . . . 15
5.2. Flow Mobility Cache . . . . . . . . . . . . . . . . . . . 16
6. Mobile Node considerations . . . . . . . . . . . . . . . . . . 17
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
Bernardos Expires May 2, 2012 [Page 2]
Internet-Draft PMIPv6 flow mobility October 2011
1. Introduction
Proxy Mobile IPv6 (PMIPv6), specified in [RFC5213], provides network
based mobility management to hosts connecting to a PMIPv6 domain.
PMIPv6 introduces two new functional entities, the Local Mobility
Anchor (LMA) and the Mobile Access Gateway (MAG). The MAG is the
entity detecting Mobile Node's (MN) attachment and providing IP
connectivity. The LMA is the entity assigning one or more Home
Network Prefixes (HNPs) to the MN and is the topological anchor for
all traffic belonging to the MN.
PMIPv6 allows an MN to connect to the same PMIPv6 domain through
different interfaces. The "logical interface" at the IP layer may
enable packet transmission and reception over different physical
media. This technique can be used to achieve flow mobility, i.e.,
the movement of selected flows from one access technology to another.
It is assumed that an IP layer interface can simultaneously and/or
sequentially attach to multiple MAGs (possibly over multiple media).
This document specifies protocol extensions to Proxy Mobile IPv6
between the LMA and MAGs to enable distributing specific traffic
flows on different physical interfaces. This document assumes that a
"logical interface" at the mobile node is capable of supporting
traffic flows on different physical interfaces regardless of the
assigned prefixes on those physical interfaces.
In particular, this document specifies how to enable "flow mobility"
in the PMIPv6 network (i.e. LMAs and MAGs). Flow mobility is
enabled by assigning the required prefixes on the different accesses.
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 [RFC2119].
The following terms used in this document are defined in the Proxy
Mobile IPv6 [RFC5213]:
Local Mobility Agent (LMA).
Mobile Access Gateway (MAG).
Proxy Mobile IPv6 Domain (PMIPv6-Domain).
LMA Address (LMAA).
Bernardos Expires May 2, 2012 [Page 3]
Internet-Draft PMIPv6 flow mobility October 2011
Proxy Care-of Address (Proxy-CoA).
Home Network Prefix (HNP).
The following terms used in this document are defined in the Multiple
Care-of Addresses Registration [RFC5648] and Flow Bindings in Mobile
IPv6 and Network Mobility (NEMO) Basic Support [RFC6089]:
Binding Identification Number (BID).
Flow Identifier (FID).
Traffic Selector (TS).
The following terms are defined and used in this document:
FMI (Flow Mobility Initiate). Message sent by the LMA to the MAG
conveying the information required to enable flow mobility in a
PMIPv6-Domain. This message is only needed when the prefixes
initially assigned to the mobile node by the different MAGs are
different.
FMA (Flow Mobility Acknowledge). Message sent by the MAG in reply to
an FMI message.
FMC (Flow Mobility Cache). Conceptual data structure maintained by
the LMA and the MAG to support the flow mobility management
operations described in this document.
3. Overview of the PMIPv6 flow mobility extensions
3.1. Use case scenarios
Flow mobility assumes simultaneous access to more than one network,
in contrast to a typical handover where connectivity to a physical
medium is relinquished, and is re-established with another. In order
to support flow mobility in a PMIPv6 network, it is required to be
able to to tie the different PMIPv6 mobility sessions (one per
interface) to a logical interface which is hiding one or more
physical interfaces [I-D.ietf-netext-logical-interface-support]. In
this specification, it is assumed that the LMA knows that the MN
supports the logical interface and it can handle the same prefix(es)
or different prefix(es) on both access networks. How this is done is
outside of the scope of this specification.
The different mobility scenarios in which a mobile node may be
involved can share the same set of prefixes or have different ones:
Bernardos Expires May 2, 2012 [Page 4]
Internet-Draft PMIPv6 flow mobility October 2011
1. At the time of a new network attachment, the MN obtains the same
prefix or the same set of prefixes as already assigned to an
existing session. This is not the default behavior in RFC 5213,
and the LMA needs to be able to provide the same assignment even
for the simultaneous attachment (as opposed to the handover
scenario only).
2. At the time of a new network attachment, the MN obtains a new
prefix or a new set of prefixes for the new session. This is the
default behavior with RFC 5213.
3. At the time of a new network attachment, the MN obtains a
combination of prefix(es) in use and new prefix(es). This is a
hybrid of the two above-mentioned scenarios. The local policy
determines whether the new prefix is exclusive to the new
attachment or it can be assigned to an existing attachment as
well.
Among these, scenario 1 needs extensions to RFC 5213 signaling at the
time of a new attachment, to ensure that the same prefix (or set of
prefixes) is assigned to all the interfaces of the same mobile node
that are simultaneously attached. Subsequently, no further signaling
is necessary.
Scenario 2 requires flow mobility signaling to enable relocating
flows between the different attachments, so the MAGs are aware of the
prefixes for which the MN is going to receive traffic, and local
routing entries are configured accordingly.
Scenario 3 requires flow mobility signaling to enable relocating
flows for the new prefix(es) which are not shared across attachments.
In all the scenarios, the MAGs should be aware of the prefixes for
which is going to receive uplink (UL) or downlink (DL) traffic.
These prefixes might not be limited to those delegated by the MAG
upon attachment of the connected interface, and therefore in these
cases, signaling is required.
Once the network is configured with the right set of prefixes, the
actual flow mobility can take place at any time thereafter (e.g., by
redirecting DL or UL packets from one access to another).
The extensions described in this document support any of these
aforementioned scenarios.
Bernardos Expires May 2, 2012 [Page 5]
Internet-Draft PMIPv6 flow mobility October 2011
3.2. Basic Operation
This section describes how the PMIPv6 extensions described in this
document enable flow mobility support.
3.2.1. MN sharing a common set of prefixes on all MAGs
This scenario corresponds to the use case scenario number 1 described
in Section 3.1. When a multi-interfaced mobile node connects to a
PMIPv6-domain, it performs regular attachment and as a result is able
to configure an IP address (or a set of IP addresses) on the logical
interface hiding the different physical interfaces. If the LMA
assigns a common prefix (or set of prefixes) to the different
physical interfaces attached to the domain, then all the MAGs already
have all the routing knowledge required to forward UL or DL packets,
and the LMA does not need to perform any kind of signaling in order
to move flows across the different physical interfaces.
As described in [I-D.ietf-netext-logical-interface-support], there
should be a local policy in place that ensures that packets are
forwarded coherently. This SHOULD be enforced by the logical
interface engine [I-D.ietf-netext-logical-interface-support]. For
unidirectional outbound communications, there SHOULD also be a policy
at the mobile node defining which physical interface is used to send
the traffic. For bidirectional outbound communications, there SHOULD
be also such a policy, but its content must be consistent with the
policy at the network-side (the details about how this consistency is
ensured are out of the scope of this document).
In case the MAGs needs to be configured to support flow mobility,
because of packet policing, packet enforcement, charging or similar
reasons, the LMA can re-use the signaling defined later in this
document to convey this information.
Bernardos Expires May 2, 2012 [Page 6]
Internet-Draft PMIPv6 flow mobility October 2011
LMA Binding Cache
+---+ =======================
|LMA| MN1, if1, pref1, MAG1
+---+ MN1, if2, pref1, MAG2
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| +-------+ |
| | I P | |
| +-------+ |
| | lif | |
| +---+---+ |
|---|if1|if2|----|
+---+---+
MN1
Figure 1: Shared prefix across physical interfaces scenario
Next, an example of how flow mobility works in this case is shown.
In Figure 1, a mobile node (MN1) has two different physical
interfaces (if1 and if2), grouped in a unique logical interface
(lif). Each physical interface is attached to a different MAG, both
of them anchored and controlled by the same LMA. Since both physical
interfaces are assigned the same prefix (pref1) upon attachment to
the MAGs, the mobile node has one single IPv6 addresses configured on
the logical interface: pref1::lif. Initially, flow X goes through
MAG1 and flow Y through MAG2. At certain point, flow Y can be moved
to also go through MAG1. As shown in Figure 2, no signaling between
the LMA and the MAGs is needed.
Bernardos Expires May 2, 2012 [Page 7]
Internet-Draft PMIPv6 flow mobility October 2011
+-----+ +------+ +------+ +-----+
Internet | LMA | | MAG1 | | MAG2 | | MN1 |
+-----+ +------+ +------+ +-----+
| | | | |
| flow X to | flow X to | flow X to |
| pref1::lif | pref1::lif | pref1::lif |
|<----------->|<--------------->|<-------------------------->if1
| flow Y to | flow Y to | flow Y to |
| pref1::lif | pref1::lif | pref1::lif |
|<----------->|<------------------------------->|<---------->if2
| | | | |
| =============================================================
| || decision to move flow Y ||
| =============================================================
| | | | |
| flow Y to | flow Y to | flow Y to |
| pref1::lif | pref1::lif | pref1::lif |
|<----------->|<--------------->|<-------------------------->if1
| | | | |
Figure 2: Flow mobility message sequence with common set of prefixes
Figure 3 shows the state of the different network entities after
moving flow Y in the previous example. This documents re-uses some
of the terminology and mechanisms of the flow bindings and multiple
care-of address registration specifications. Note, that in this case
the BIDs shown in the figure are assigned locally by the LMA, since
there is no signaling required in this scenario. In any case,
alternative implementations of flow routing at the LMA could be used,
as it does not impact on the operation of the solution in this case.
Bernardos Expires May 2, 2012 [Page 8]
Internet-Draft PMIPv6 flow mobility October 2011
LMA Binding Cache LMA flowmob state
(BID, MN-ID, ATT, HNP, PCoA) (BID, TS)
+---+ ========================== ===================
|LMA| 1, MN1, if1, pref1, MAG1 1, flow X
+---+ 2, MN1, if2, pref1, MAG2 1, flow Y
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\ MAG1 routing state
+----+ +----+ ================================
|MAG1| |MAG2| (dest) (next hop)
+----+ +----+ pref1::/64 p2p-iface-with-MN1
| | ::/0 LMA
| +-------+ |
| | I P | | MAG2 routing state
| +-------+ | ================================
| | lif | | (dest) (next hop)
| +---+---+ | pref1::/64 p2p-iface-with-MN1
|---|if1|if2|----| ::/0 LMA
+---+---+
MN1
Figure 3: Data structures with common set of prefixes
3.2.2. MN with different sets of prefixes on each MAG
A different flow mobility scenario happens when the LMA assigns
different sets of prefixes to physical interfaces of the same mobile
node. This covers the second and third use case scenarios described
in Section 3.1. In this case, specific signaling is required between
the LMA and the MAG to support this scenario. Two different
possibilities are considered next.
The first possibility corresponds to the use case scenario number 2
described in Section 3.1, in which a multi-interfaced MN obtains a
different set of prefixes on each attachment. Signaling is required
when a flow is to be moved from its original interface to a new one.
Since the LMA cannot send a PBA message which has not been triggered
in response to a received PBU message, new signaling messages are
defined to cover this case. The trigger for the flow movement can be
on the mobile node (e.g., by using layer-2 signaling, by explicitly
start sending flow packets via a new interface, etc.) or on the
network (e.g., based on congestion and measurements performed at the
network).
Bernardos Expires May 2, 2012 [Page 9]
Internet-Draft PMIPv6 flow mobility October 2011
If the flow is being moved from its default path (which is determined
by the destination prefix) to a different one, the LMA constructs a
Flow Mobility Initiate (FMI) message. This message is sent to the
new target MAG, i.e. the one selected to be the used in the
forwarding of the flow. The FMI message contains (as explained in
further detail in Section 4.1), the MN-Identifier, the Flow
Identification Mobility option (specified in [RFC6089]) which can
convey prefix or full flow information, and the type of flow mobility
operation (add flow). Optionally, the LMA may send another FMI
message, this time to remove the flow Y state at MAG2. Otherwise the
flow state at MAG2 will be removed upon timer expiration. The
message sequence is shown in Figure 4.
+-----+ +------+ +------+ +-----+
Internet | LMA | | MAG1 | | MAG2 | | MN1 |
+-----+ +------+ +------+ +-----+
| | | | |
| flow X to | flow X to | flow X to |
| pref1::lif | pref1::lif | pref1::lif |
|<----------->|<--------------->|<-------------------------->if1
| flow Y to | flow Y to | flow Y to |
| pref2::lif | pref2::lif | pref2::lif |
|<----------->|<------------------------------->|<---------->if2
| | | | |
| =============================================================
| || decision to move flow Y ||
| =============================================================
| | | | |
| | FMI[MN1-ID,flow_info(Y),add] | |
| |---------------->| | |
| | FMA | | |
| |<----------------| | |
| | (optional) | |
| | FMI[MN1-ID,flow_info(Y),del] | |
| |-------------------------------->| |
| | | FMA | |
| |<--------------------------------| |
| flow Y to | flow Y to | flow Y to |
| pref2::lif | pref2::lif | pref2::lif |
|<----------->|<--------------->|<-------------------------->if1
| | | | |
Figure 4: Flow mobility message sequence when the LMA assigns
different sets of prefixes per physical interface (FMI signaling)
The state in the network after moving a flow, for the case the LMA
assigns a different set of prefixes is shown in Figure 5.
Bernardos Expires May 2, 2012 [Page 10]
Internet-Draft PMIPv6 flow mobility October 2011
LMA Binding Cache LMA flowmob state
(BID, MN-ID, ATT, HNP, PCoA) (BID, TS)
+---+ ============================ ===================
|LMA| 1, MN1, if1, pref1, 1, flow X
+---+ pref2, MAG1 1, flow Y
//\\ 2, MN1, if2, pref2, MAG2
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\ MAG1 routing state
+----+ +----+ ================================
|MAG1| |MAG2| (dest) (next hop)
+----+ +----+ pref1::/64 p2p-iface-with-MN1
| | pref2::/64 p2p-iface-with-MN1
| +-------+ | ::/0 LMA
| | I P | |
| +-------+ | MAG2 routing state
| | lif | | ================================
| +---+---+ | (dest) (next hop)
|---|if1|if2|----| pref2::/64 p2p-iface-with-MN1
+---+---+ ::/0 LMA
MN1
Figure 5: Data structures when the LMA assigns a different set of
prefixes
The second possibility corresponds to the use case scenario number 3
described in Section 3.1, in which upon new physical interface
attachment, the MN obtains a combination of prefix(es) in used and
new prefix(es). Here, the mobile node is already attached to the
PMIPv6-Domain via MAG1. At a certain moment, the mobile node
attaches a new interface (if2) to MAG2. MAG2 sends a PBU which is
then used by the LMA to enable flow mobility. In this case, we
consider that flows are moved with a prefix granularity, meaning that
flows are moved by moving prefixes among the different MAGs the
mobile node is attached to. In this example, flow Y is bound to
pref2::/64 and therefore the flow can be moved by just binding
pref2::/64 to MAG2. This is done by including the prefix in the PBA
message. The scenario is shown in Figure 6.
Optionally, a message can be sent to MAG1 to remove the transferred
prefix(es). This message can be a Binding Revocation Indication
message [RFC5846] with the P bit set to indicate that this is
revocation of PMIP prefix(es). After processing BRI, the source MAG
will send a Binding Revocation Acknowledgement (BRA) message back to
the LMA.
Bernardos Expires May 2, 2012 [Page 11]
Internet-Draft PMIPv6 flow mobility October 2011
In case flow mobility is needed with a finer granularity than full
prefix (e.g., flow level), this is done by including in the PBA a
Flow Identification Mobility option (specified in [RFC6089]) which
can convey full flow information. The MAG can also include the Flow
Identification Mobility option in the PBU message that it sends to
the LMA. This serves as a request for the LMA to consider the flow
policy rules specified in the option. In this case no prefix is
removed from any MAG because the movement is performed at flow level.
+-----+ +------+ +------+ +-----+
Internet | LMA | | MAG1 | | MAG2 | | MN |
+-----+ +------+ +------+ +-----+
| | | | |
| flow X to | flow X to | flow X to |
| pref1::lif | pref1::lif | pref1::lif |
|<----------->|<--------------->|<-------------------------->if1
| flow Y to | flow Y to | flow Y to |
| pref2::lif | pref2::lif | pref2::lif |
|<----------->|<--------------->|<-------------------------->if1
| | | | |
| | | | |
| | | MN powers on if2 and
| | | performs L2 attachment
| | | |<-----------if2
| | | PBU | |
| |<--------------------------------| |
| | PBA (pref2) | | |
| |-------------------------------->| |
| LMA moves pref2 to new | | |
| binding cache entry for if2 | | |
| | | | |
| | | | |
| | (optional) | | |
| | BRI[pref2] | | |
| |---------------->| | |
| | BRA | | |
| |<----------------| | |
| flow y to | flow y to | flow y to |
| pref2::lif | pref2::lif | pref2::lif |
|<----------->|<------------------------------->|<---------->if2
| | | | |
Figure 6: Flow mobility message sequence with different set of
prefixes per physical interface (PBU signaling)
Bernardos Expires May 2, 2012 [Page 12]
Internet-Draft PMIPv6 flow mobility October 2011
4. Message formats
4.1. Flow Mobility Initiate (FMI)
The LMA sends an FMI message to a MAG to enable flow mobility. It is
a Mobility Header message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I|C|R| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number:
A monotonically increasing integer. Set by the LMA sending then
initiate message, and used to match a reply in the acknowledge.
'I' (initiate) flag:
Set to 1, indicates it is an FMI message.
'C' (cancel) flag:
When set to 1, indicates a request to remove state about the flow
(cancel flow mobility). If set to 1, the Lifetime field MUST be
set to 0.
'R' (refresh) flag:
When set to 1, indicates a request to refresh state about the
flow. If the 'C' flag is set to 1, this flag should be set to 0
by the sender and ignored by the receiver.
Reserved:
This field is unused. MUST be set to zero by the sender.
Lifetime:
Bernardos Expires May 2, 2012 [Page 13]
Internet-Draft PMIPv6 flow mobility October 2011
The requested time in seconds for which the LMA asks the MAG keep
flow-specific state. A value of all one bits (0xffff) represents
infinity.
Mobility Options:
MUST contain the MN-ID, followed by one or more Flow
Identification Mobility options [RFC6089].
4.2. Flow Mobility Acknowledge (FMA)
The MAG sends an FMI message to the LMA as a response to the FMI
message. It is a Mobility Header message.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|I| Reserved | Status | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number:
A monotonically increasing integer. Copied from the value set by
the sending LMA in the FMI message being acknowledged by this FMA
message.
'I' flag:
Set to 0, indicates it is an FMA message.
Reserved:
This field is unused. MUST be set to zero by the sender.
Status:
0: Success.
Bernardos Expires May 2, 2012 [Page 14]
Internet-Draft PMIPv6 flow mobility October 2011
128: Reason unspecified.
129: MN not attached.
130: Sequence number out of window.
131: Traffic Selector format unsupported.
132: No existing Flow Mobility Cache entry.
133: Already existing Flow Mobility Cache entry.
Lifetime:
The requested time in seconds for which the MAG keeps flow-
specific state. A value of all one bits (0xffff) represents
infinity.
Mobility Options:
When Status code is 0, MUST contain the MN-ID, followed by one or
more Flow Identification Mobility options [RFC6089].
5. Conceptual Data Structures
5.1. Multiple Care-of Address Registration
The LMA is extended to allow a mobile node to register multiple proxy
care of address (Proxy-CoA). The LMA maintains multiple binding
cache entries for a MN. The number of binding cache entries for an
MN is equal to the number of the MN's interfaces attaching to any
MAGs.
+---------+-----+-------+------+-----------+------------+
| BID-PRI | BID | MN-ID | ATT | HNP(s) | Proxy-CoA |
+---------+-----+-------+------+-----------+------------+
| 20 | 1 | MN1 | WiFi | HNP1,HNP2 | IP1 (MAG1) |
| 30 | 2 | MN1 | 3GPP | HNP1,HNP3 | IP2 (MAG2) |
+---------+-----+-------+------+-----------+------------+
Figure 7: Extended Binding Cache
Figure 7 shows two Binding Cache Entries of the MN1 when it is
attached to the network using two different access technologies.
Both of the two attachments share HNP1 and are bounded to two
different Proxy-CoAs.
Bernardos Expires May 2, 2012 [Page 15]
Internet-Draft PMIPv6 flow mobility October 2011
5.2. Flow Mobility Cache
Each LMA maintains a flow mobility cache (FMC) as shown in Figure 8.
This table contains entry for each flow sent from the MN. A flow
binding entry includes the following fields:
o Flow Identifier Priority (FID-PRI).
o Flow Identifier (FID).
o Traffic Selector (TS).
o Binding Identifier (BID).
o Action.
o Active/Inactive.
+---------+-----+-----+------+---------+----------+
| FID-PRI | FID | TS | BIDs | Action | A/I |
+---------+-----+-----+------+---------+----------+
| 10 | 2 | TCP | 1 | Forward | Active |
| 20 | 4 | UDP | 1,2 | Forward | Inactive |
+---------+-----+-----+------+---------+----------+
Figure 8: Flow Mobility Cache
The BID field contains the identifier of the binding cache entry
which packets matching the flow information described in the TS field
will be forwarded to. When a flow is decided to be moved, the
affected BID(s) of the table are updated.
Similar to flow binding described in [RFC6089], each flow binding
entry points to a specific binding cache entry identifier (BID).
When a flow is moved, the LMA simply updates the pointer of the flow
binding entry with the BID of the interface to which the flow will be
moved. The traffic selector (TS) in flow binding table is defined as
in [RFC6088]. TS is used to classify the packets of flows basing on
specific parameters such as service type, source and destination
address, etc. The packets matching with the same TS will be applied
the same forwarding policy. FID-PRI is the order of precedence to
take action on the traffic. Action may be forward or drop. If a
binding entry becomes 'Inactive' it does not affect data traffic. An
entry becomes 'Inactive' only if all of the BIDs are deregistered.
The Mobile Access Gateway MAY also maintain a similar data structure.
In case no full flow mobility state is required at the MAG, the
Bernardos Expires May 2, 2012 [Page 16]
Internet-Draft PMIPv6 flow mobility October 2011
Binding Update List (BUL) data structure is enough and no extra
conceptual data entries are needed. In case full per-flow state is
required at the MAG, it should keep a similar structure to the FMC
(details TBD).
6. Mobile Node considerations
This specification assumes the MN implements the logical interface
model. The "logical interface" at the IP layer hides the use of
different physical media from the IP stack, enabling the MN to send
and receive packets over different interfaces. This document assumes
the MN behaves as stated in the applicability statement document
[I-D.ietf-netext-logical-interface-support]. In particular, it is
assumed that -- for the case of bidirectional traffic -- the logical
interface at the MN "replicates" the behavior observed for downlink
packets on a per-flow basis. This means that the MN sends UL Flow X
on the same interface which received the DL Flow X. It also means
that if the LMA moves flow X during its lifetime, the MN will follow
that change, upon the reception of packets of flow X via a different
interface.
This specification only supports flow mobility between different
physical interfaces belonging to the same logical interface. If an
MN has several logical interfaces, flow mobility across different
logical interfaces is not supported.
7. IANA Considerations
TBD.
8. Security Considerations
TBD.
9. Authors
This document reflects contributions from the following authors (in
alphabetical order).
Kuntal Chowdhury
E-mail: Kchowdhu@cisco.com
Bernardos Expires May 2, 2012 [Page 17]
Internet-Draft PMIPv6 flow mobility October 2011
Vijay Devarapalli
E-mail: vijay@wichorus.com
Sri Gundavelli
E-mail: sgundave@cisco.com
Youn-Hee Han
E-mail: yhhan@kut.ac.kr
Yong-Geun Hong
E-mail: yonggeun.hong@gmail.com
Mohana Dahamayanthi Jeyatharan
E-mail: mohana.jeyatharan@sg.panasonic.com
Rajeev Koodli
E-mail: rkoodli@cisco.com
Kent Leung
E-mail: kleung@cisco.com
Telemaco Melia
E-mail: Telemaco.Melia@alcatel-lucent.com
Bruno Mongazon-Cazavet
E-mail: Bruno.Mongazon-Cazavet@alcatel-lucent.com
Chan-Wah Ng
E-mail: chanwah.ng@sg.panasonic.com
Behcet Sarikaya
E-mail: sarikaya@ieee.org
Tran Minh Trung
E-mail: trungtm2909@gmail.com
Bernardos Expires May 2, 2012 [Page 18]
Internet-Draft PMIPv6 flow mobility October 2011
Frank Xia
E-mail: xiayangsong@huawei.com
10. Acknowledgments
The authors would like to thank Juan-Carlos Zuniga, Pierrick Seite,
Julien Laganier for all the discussions on this topic.
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.
[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.
[RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K.,
and P. Yegani, "Binding Revocation for IPv6 Mobility",
RFC 5846, June 2010.
[RFC6088] Tsirtsis, G., Giarreta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings", RFC 6088,
January 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.
11.2. Informative References
[I-D.ietf-netext-logical-interface-support]
Melia, T. and S. Gundavelli, "Logical Interface Support
for multi-mode IP Hosts",
draft-ietf-netext-logical-interface-support-03 (work in
progress), September 2011.
Bernardos Expires May 2, 2012 [Page 19]
Internet-Draft PMIPv6 flow mobility October 2011
Author's Address
Carlos J. Bernardos (editor)
Universidad Carlos III de Madrid
Av. Universidad, 30
Leganes, Madrid 28911
Spain
Phone: +34 91624 6236
Email: cjbc@it.uc3m.es
URI: http://www.it.uc3m.es/cjbc/
Bernardos Expires May 2, 2012 [Page 20]