NETEXT Working Group CJ. Bernardos, Ed.
Internet-Draft UC3M
Intended status: Standards Track M. Jeyatharan
Expires: January 6, 2011 Panasonic
R. Koodli
Cisco Systems
T. Melia
Alcatel-Lucent
F. Xia
Huawei USA
July 5, 2010
Proxy Mobile IPv6 Extensions to Support Flow Mobility
draft-bernardos-netext-pmipv6-flowmob-00
Abstract
Proxy Mobile IPv6 (PMIPv6) is a network-based localized mobility
management protocol that enables mobile devices to connect to a
PMIPv6 domain and roam across gateways without changing their IP
addresses. PMIPv6 basic specification also provides limited multi-
homing support to multi-mode mobile devices. The ability of movement
of selected flows from one access technology to another is missing in
basic PMIPv6. This document describes a mechanism to support flow
mobility on a logical interface over multiple 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."
Bernardos, et al. Expires January 6, 2011 [Page 1]
Internet-Draft PMIPv6 flow mobility July 2010
This Internet-Draft will expire on January 6, 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.
Bernardos, et al. Expires January 6, 2011 [Page 2]
Internet-Draft PMIPv6 flow mobility July 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Flow mobility scenarios . . . . . . . . . . . . . . . . . . . 5
3.1. Unique prefix per physical interface . . . . . . . . . . . 5
3.2. Shared prefix across physical interfaces . . . . . . . . . 8
4. Message formats . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Flow Mobility Initiate (FMI) . . . . . . . . . . . . . . . 11
4.2. Flow Mobility Acknowledge (FMA) . . . . . . . . . . . . . 13
4.3. Traffic Selector mobility option (TS) . . . . . . . . . . 14
5. Local Mobility Anchor considerations . . . . . . . . . . . . . 15
5.1. Sending Flow Mobility Initiate messages . . . . . . . . . 15
5.2. Receiving Flow Mobility Acknowledge messages . . . . . . . 16
5.3. Conceptual Data Structures . . . . . . . . . . . . . . . . 17
5.4. Packet Processing considerations . . . . . . . . . . . . . 19
6. Mobile Access Gateway considerations . . . . . . . . . . . . . 19
6.1. Receiving Flow Mobility Initiate messages . . . . . . . . 19
6.2. Sending Flow Mobility Acknowledge messages . . . . . . . . 21
6.3. Conceptual Data Structures . . . . . . . . . . . . . . . . 21
6.4. Packet Processing considerations . . . . . . . . . . . . . 23
7. Mobile Node considerations . . . . . . . . . . . . . . . . . . 23
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23
10. Primary contributors . . . . . . . . . . . . . . . . . . . . . 23
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
Bernardos, et al. Expires January 6, 2011 [Page 3]
Internet-Draft PMIPv6 flow mobility July 2010
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 a protocol between the LMA and MAGs for
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 from different physical
interfaces regardless of the assigned prefixes on those physical
interfaces.
In particular, this document specifies how to manage "flow mobility"
state in the PMIPv6 network (i.e. LMAs and MAGs), namely creation,
refresh and cancel operation. Flow mobility is is controlled and
initiated by the LMA. The trigger causing the LMA to initiate a flow
mobility operation is out of scope of this specification.
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).
Bernardos, et al. Expires January 6, 2011 [Page 4]
Internet-Draft PMIPv6 flow mobility July 2010
LMA Address (LMAA).
Proxy Care-of Address (Proxy-CoA).
Home Network Prefix (HNP).
The following terms are defined and used in this document:
FMI (Flow Mobility Initiate). Message sent by the LMA to create,
refresh or cancel flow mobility state in the MAG. It conveys the
information required to manage the flow mobility in a PMIPv6-
Domain.
FMA (Flow Mobility Acknowledge). Message sent by the MAG in reply to
an FMI message. It provides feedback about the result of a flow
mobility creation, refresh or cancel operation requested in the
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.
Traffic Selector (TS). Mobility option carrying the flow filters
used to match packets with packet flows.
3. Flow mobility scenarios
There are two possible scenarios that can be considered: i) unique
prefix (or set of prefixes) per physical interface, ii) shared prefix
(or set of prefixes) across physical interfaces. We describe next in
more detail each of these scenarios and how flow mobility is enabled
when using PMIPv6.
3.1. Unique prefix per physical interface
In this scenario, each physical interface of the mobile node is
assigned a unique prefix (or set of prefixes). This is the default
scenario supported by Proxy Mobile IPv6 as specified in RFC 5213
[RFC5213]. The LMA maintains multiple binding cache entries
(multiple mobility sessions) -- one per physical interface -- as well
as routing entries -- one per assigned prefix. This scenario is
shown in Figure 1.
Bernardos, et al. Expires January 6, 2011 [Page 5]
Internet-Draft PMIPv6 flow mobility July 2010
LMA Binding Cache
+---+ =======================
|LMA| MN1, if1, pref1, MAG1
+---+ MN1, if2, pref2, MAG2
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| +-------+ |
| | I P | |
| +-------+ |
| | lif | |
| +---+---+ |
|---|if1|if2|----|
+---+---+
MN1
Figure 1: Unique prefix per physical interface scenario
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 each physical
interface is assigned a different prefix upon attachment (pref1 upon
attachment to MAG1 and pref2 upon attachment to MAG2), the mobile
node has two different IPv6 addresses configured on the logical
interface: pref1::lif and pref2::lif.
In this scenario, the LMA decides how flows are routed from the LMA
to the MN, and therefore, through which interface the MN receives
packets from different flows. If the LMA decides to move a
particular flow from its default path (which is determined in this
scenario by the destination prefix) to a different one, it 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 LMA can decide on which is the best MAG
that should be used to forward a particular flow when the flow is
initiated (e.g., based on application policy profiles) and/or during
the lifetime of the flow upon receiving a trigger either based on
network status or based on an event detected at the mobile node. How
this decision is taken is out of scope of this specification. The
Bernardos, et al. Expires January 6, 2011 [Page 6]
Internet-Draft PMIPv6 flow mobility July 2010
FMI message contains (as explained in further detail in Section 4.1),
the MN-Identifier, the flow selector (i.e. the n-tuple of parameters
that allow to match packets to flows) and the type of flow mobility
operation (add flow).
+-----+ +------+ +------+ +-----+
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
| | | | |
| LMA decision | | |
| to move flow Y | | |
| | FMI[MN1-ID,traffic_spec(Y),add] | |
| |---------------->| | |
| | FMA | | |
| |<----------------| | |
| LMA moves | | |
| flow Y | | |
| | (optional) | |
| | FMI[MN1-ID,traffic_spec(Y),del] | |
| |-------------------------------->| |
| | | FMA | |
| |<--------------------------------| |
| flow Y to | flow Y to | flow Y to |
| pref2:lif | pref2:lif | pref2:lif |
|<----------->|<--------------->|<-------------------------->if1
| | | | |
Figure 2: Flow mobility signaling for the unique prefix per physical
interface scenario
An example of the signaling sequence is shown in Figure 2. At the
beginning MN1 has two active flows: flow X going through interface
if1 and MAG1, and flow Y going through interface if2 and MAG2. At a
certain moment, the LMA decides to move flow Y from interface if2 to
if1. To do so, it sends a FMI message to the MAG1 where if2 (the
target interface) is attached to, including the MN-ID and the traffic
spec of flow Y. Upon reception of the message, MAG1 checks if it can
forward flow Y, adds the required forwarding state so packets
belonging to flow Y are delivered via the if1, and replies back to
the LMA with an FMA message. Upon reception of this FMA message from
MAG1, the LMA moves flow Y towards MAG1. Optionally, the LMA may
Bernardos, et al. Expires January 6, 2011 [Page 7]
Internet-Draft PMIPv6 flow mobility July 2010
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.
LMA Binding Cache LMA flowmob state
+---+ ======================= ===================
|LMA| MN1, if1, pref1, MAG1 MN1, flow X, MAG1
+---+ MN1, if2, pref2, MAG2 MN1, flow Y, MAG1
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\ MAG1 routing state
+----+ +----+ ================================
|MAG1| |MAG2| (dest) (next hop)
+----+ +----+ pref1::/64 p2p-iface-with-MN1
| | ::/0 LMA
| +-------+ | pref2::/64 p2p-iface-with-MN1
| | I P | |
| +-------+ | MAG2 routing state
| | lif | | ================================
| +---+---+ | (dest) (next hop)
|---|if1|if2|----| pref2::/64 p2p-iface-with-MN1
+---+---+ ::/0 LMA
MN1
Figure 3: Unique prefix per physical interface scenario
Figure 3 shows the state of the different network entities after
moving flow Y in the previous example.
3.2. Shared prefix across physical interfaces
In this scenario, physical interfaces of the mobile node are assigned
the same prefix (or set of prefixes). The LMA maintains multiple
binding cache entries (multiple mobility session) -- one per physical
interface -- but they share the same HNP. How the shared prefix is
routed by the LMA when there is no flow-specific state is left up to
the implementation. This scenario is shown in Figure 4. How the LMA
decides whether to assign the same prefix or a different one is TBD.
Bernardos, et al. Expires January 6, 2011 [Page 8]
Internet-Draft PMIPv6 flow mobility July 2010
LMA Binding Cache
+---+ =======================
|LMA| MN1, if1, pref1, MAG1
+---+ MN1, if2, pref1, MAG2
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| +-------+ |
| | I P | |
| +-------+ |
| | lif | |
| +---+---+ |
|---|if1|if2|----|
+---+---+
MN1
Figure 4: Shared prefix across physical interfaces scenario
In Figure 4, 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.
In this scenario, the LMA also decides how flows are routed from the
LMA to the MN, and therefore, through which interface the MN receives
packets from different flows.
Bernardos, et al. Expires January 6, 2011 [Page 9]
Internet-Draft PMIPv6 flow mobility July 2010
+-----+ +------+ +------+ +-----+
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
| | | | |
| LMA decision | | |
| to move flow Y | | |
| | FMI[MN1-ID,traffic_spec(Y),add] | |
| |---------------->| | |
| | FMA | | |
| |<----------------| | |
| LMA moves | | |
| flow Y | | |
| | (optional) | |
| | FMI[MN1-ID,traffic_spec(Y),del] | |
| |-------------------------------->| |
| | | FMA | |
| |<--------------------------------| |
| flow Y to | flow Y to | flow Y to |
| pref1:lif | pref1:lif | pref1:lif |
|<----------->|<--------------->|<-------------------------->if1
| | | | |
Figure 5: Flow mobility signaling for the shared prefix across
physical interfaces scenario
An example of the signaling sequence is shown in Figure 5. The
operation is analogous to the case of a unique prefix per physical
interface. Note that in this scenario, if the target MAG does not
need to perform flow-specific actions (e.g., QoS or accounting), the
FMI/FMA signaling could be avoided, as no new routing state is
required to forward a moved flow (since the prefix assigned to all
physical interfaces is the same).
Bernardos, et al. Expires January 6, 2011 [Page 10]
Internet-Draft PMIPv6 flow mobility July 2010
LMA Binding Cache LMA flowmob state
+---+ ======================= ===================
|LMA| MN1, if1, pref1, MAG1 MN1, flow X, MAG1
+---+ MN1, if2, pref1, MAG2 MN1, flow Y, MAG1
//\\
+---------//--\\-------------+
( // \\ ) 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 6: Shared prefix across physical interfaces scenario
Figure 6 shows the state of the different network entities after
moving flow Y in the previous example.
4. Message formats
4.1. Flow Mobility Initiate (FMI)
The LMA sends an FMI message to a MAG to inform about a particular
flow movement. It is a Mobility Header message.
Bernardos, et al. Expires January 6, 2011 [Page 11]
Internet-Draft PMIPv6 flow mobility July 2010
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:
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:
Bernardos, et al. Expires January 6, 2011 [Page 12]
Internet-Draft PMIPv6 flow mobility July 2010
MUST contain the MN-ID, followed by one or more Traffic Selector
mobility options.
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.
128: Reason unspecified.
129: MN not attached.
130: Sequence number out of window.
Bernardos, et al. Expires January 6, 2011 [Page 13]
Internet-Draft PMIPv6 flow mobility July 2010
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 Traffic Selector mobility options in the same order as in the
FMI message.
4.3. Traffic Selector mobility option (TS)
The Traffic Selector is a new mobility option that carries the
parameters used to match packets for a specific flow mobility
binding. The LMA MUST include 1 or more traffic selector mobility
options in an FMI 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Len | TS format | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Traffic Selector ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+
Option Type:
To be assigned by IANA.
Option Length:
Variable.
TS format:
An 8-bit unsigned integer indicating the Traffic Selector Format.
Value "0" is reserved and SHOULD NOT be used.
Reserved:
Bernardos, et al. Expires January 6, 2011 [Page 14]
Internet-Draft PMIPv6 flow mobility July 2010
An 8-bit reserved field. It SHOULD be set to zero by the sender
and ignored by the receiver.
Traffic Selector:
A variable length field, the format and content of which is out of
the scope of this specification. The binary formats defined in
[I-D.ietf-mext-binary-ts] MAY be used.
5. Local Mobility Anchor considerations
This specification allows the LMA to control the distribution of
specific traffic flows on different physical interfaces. This
section details the LMA operations necessary to implement this
specification.
5.1. Sending Flow Mobility Initiate messages
This specification allows the LMA to control and dynamically change
the path used to deliver packets belonging to specific flows. This
enables the LMA to have different forwarding rules for particular
flows, in addition to the routes created upon regular PMIPv6
registration.
When creating a new Flow Mobility Cache entry (i.e. adding a new
forwarding rule to allow flow traffic follow a different path from
the one created upon regular PMIPv6 registration for the same
destination prefix), the LMA includes the information needed to match
the data packets to a specific flow in a Traffic Selector (TS)
mobility option. This TS option MUST be included in an FMI message.
This FMI message MUST have the cancel ('C') and refresh ('R') flags
set to zero indicate that the FMI refers to a new flow. The FMA
message MUST also include the MN-Identifier option of the mobile node
the flow information refers to. More than one TS options MAY be
included in the FMI message, but all of them MUST be subject to the
same type of operation (e.g., creation of new mobility state). The
LMA MUST create the corresponding Flow Mobility Cache entry upon
receiving an FMA message with Status set to Success.
When canceling existing Flow Mobility state in the network (i.e.
falling back to the default packet forwarding based solely on per HNP
destination tunnels between LMA and MAG), the LMA sends an FMI
message including the TS option(s) that refer to the flow(s) whose
associated state is to be removed. This FMI message MUST have the
cancel ('C') flag set to 1, and MUST include the MN-Identifier
option. The LMA MAY decide to remove the corresponding Flow Mobility
Cache entry at the MAG by sending this explicit signaling or by
Bernardos, et al. Expires January 6, 2011 [Page 15]
Internet-Draft PMIPv6 flow mobility July 2010
relying on the expiration of the associated timers.
The LMA MUST refresh the flow mobility state (i.e. FMC entry) at the
MAG to prevent the MAG to stop forwarding specific flows upon
expiration of the associated timers. When refreshing flow mobility
state, the LMA sends an FMI message including the TS option(s) that
refer to the flow(s) whose associated state is to be refreshed. This
FMI message MUST have the refresh ('R') flag set to 1, and MUST also
include the MN-Identifier option.
EDITOR's NOTE: Retransmissions and Rate Limiting considerations TBD.
The IPv6 source address of an FMI message MUST be the LMA Address
(LMAA). The destination IPv6 address of the FMI message MUST be set
to the Proxy-CoA of the MAG which will create/cancel/refresh flow
mobility state as indicated in the FMI message.
Security considerations stated in Section 4 of [RFC5213] "Proxy
Mobile IPv6 Protocol Security" apply also for the signalling
specified in this document.
EDITOR's NOTE: Additional authentication and security requirements
(if any) TBD.
5.2. Receiving Flow Mobility Acknowledge messages
Upon receiving a packet carrying a Flow Mobility Acknowledge, an LMA
MUST validate the packet according to the following tests:
o The packet meets the authentication requirements for Flow Mobility
Acknowledges defined in Section XXX (TBD).
o The IPv6 source address of the packet corresponds to the address
of a MAG known by the LMA (NOTE: this is probably redundant once
the security details are included).
o The Sequence Number field matches the Sequence Number sent by the
LMA to this destination address in an outstanding Flow Mobility
Initiate.
Any Flow Mobility Acknowledge not satisfying all of these tests MUST
be silently ignored.
When an LMA receives a packet carrying a valid Flow Mobility
Acknowledge, the LMA MUST examine the Status field as follows:
o If the Status field indicates that the Flow Binding Initiate was
accepted (the Status field is less than 128), then the LMA MUST
Bernardos, et al. Expires January 6, 2011 [Page 16]
Internet-Draft PMIPv6 flow mobility July 2010
update the corresponding entry (or entries) in its Flow Mobility
Cache, to indicate that the Flow Mobility Initiate has been
acknowledged. The LMA MUST then stop retransmitting the FMI
message. In addition, if the value specified in the Lifetime
field in the FMA is less than the Lifetime value sent in the FMI
being acknowledged, the LMA MUST substract the difference between
these two values from the remaining lifetime for the flow binding
as maintained in the corresponding Flow Mobility Cache entry.
LMAs SHOULD send a new FMI well before the expiration of this
period in order to extend the lifetime. This helps to avoid
disruptions in communications which might otherwise be caused by
network delays or clock drift.
o If the Status Field indicates that the flow binding operation was
rejected (the Status field is greater than or equal to 128), then
the LMA can take steps to correct the cause of the error and
retransmit the FMI (with a new Sequence Number value) subject to
the rate limiting restrictions specified in Section XXX. If this
is decided not to be done or it fails, then the LMA SHOULD record
in its Flow Mobility Cache that future FMIs SHOULD NOT be sent to
this destination. These considerations are of particular
importance in case of creation/refresh of flow mobility state.
o Additionally, for those Flow Mobility Cache entries that are newly
created (not refreshed), the LMA MUST perform the actions required
to ensure that the data packets matching the flow filters carried
in the Traffic Selector options are forwarded via the appropriate
MAG. How this is done is left up to the implementation of the
LMA.
5.3. Conceptual Data Structures
Each Local Mobility Anchor MUST maintain a Flow Mobility Cache. The
Flow Mobility Cache MAY be implemented in any manner consistent with
the external behavior described in this document. When sending a
packet, the Flow Mobility Cache is searched before the Neighbor
Discovery conceptual Destination Cache.
Each Flow Mobility Cache entry conceptually contains the following
fields:
o The MN-Identifier of the mobile node for the flow this entry
refers to. This field is used as primary key for searching the
cache for update operations (deletion, refresh, cancel).
o The flow filter information carried in the Traffic Selector
mobility option. This information SHOULD be stored in a format
Bernardos, et al. Expires January 6, 2011 [Page 17]
Internet-Draft PMIPv6 flow mobility July 2010
that allows the LMA to forward packets matching the filter to the
corresponding MAG (as indicated by the Proxy-CoA field stored in
the Flow Mobility Cache entry).
o The Proxy-CoA for which that the FMI carrying the information
about this flow was sent.
o The tunnel interface identifier (tunnel-if-id) of the bi-
directional between the LMA and the MAG that MUST be used when
forwarding packets belonging to the flow this entry refers to.
This is internal to the local mobility anchor. The tunnel
interface identifier is acquired during the tunnel creation in the
standard Proxy Mobile IPv6 registration.
o The initial value of the Lifetime field sent in the FMI.
o The remaining lifetime of that flow binding. The lifetime value
is initialized from the Lifetime field in the FMA that created or
last modified this entry and is decremented until it reaches zero,
at which time this entry MUST be deleted from the Flow Mobility
Cache.
o The maximum value of the Sequence Number field received in
previous FMAs for this flow. The Sequence Number field is 16 bits
long. Sequence Number values MUST be compared modulo 2**16 as
explained in Section 9.5.1 of [RFC3775].
o The time at which an FMI was last sent regarding to this flow, as
needed to implement the rate limiting restriction for sending
FMIs.
o The state of any retransmissions needed for FMIs referring to this
flow. This state includes the time remaining until the next
retransmission attempt for the FMI and the current state of the
exponential back-off mechanism for retransmissions.
o A flag specifying whether or not future FMIs should be sent to
this destination.
The Flow Mobility Cache is used to determine whether a particular
packet belongs to a flow which has flow mobility state created -- and
therefore needs to be processed separately from the rest of the
packets -- or it can just be sent using normal packet processing
rules as specified in RFC 5213.
Bernardos, et al. Expires January 6, 2011 [Page 18]
Internet-Draft PMIPv6 flow mobility July 2010
5.4. Packet Processing considerations
The LMA MUST be able to forward packets matching the flow filters
stored in the Flow Mobility Cache (carried in Traffic Selector
mobility options inside FMIs) via the corresponding bi-directional
tunnel.
For those packets with no matching Flow Mobility Cache, default
PMIPv6 data forwarding considerations MUST be followed.
How the LMA ensures per-flow forwarding is left up to the particular
implementation of the LMA.
6. Mobile Access Gateway considerations
This section details the MAG operations necessary to implement this
specification.
6.1. Receiving Flow Mobility Initiate messages
This specification allows the MAG to deliver packets whose
destination address could not match any destination network hosted at
any interface of the MAG (i.e. a connected interface for that prefix)
or sent by a mobile node with no matching binding. This enables the
MAG to deliver/forward packets to/from IPv6 addresses that would not
be known by a MAG not conforming to this specification.
Upon receiving a packet carrying a Flow Mobility Initiate, a MAG MUST
validate the packet according to the following tests:
o The packet meets the authentication requirements for Flow Mobility
Initiates defined in Section XXX (TBD).
o The IPv6 source address of the packet corresponds to the address
of an LMA known by the MAG (NOTE: this is probably redundant once
the security details are included).
o The FMI contains one and only one MN-Identifier mobility option
and one or more Traffic Selector mobility options.
Any Flow Mobility Initiate not satisfying all of these tests MUST be
silently ignored.
In addition, if there is already a Flow Mobility Cache entry for that
flow and the Sequence Number field stored in the entry is the same or
greater than the sequence number carried in the FMI, then the MAG
MUST send back an FMA with status code 127, and the last accepted
Bernardos, et al. Expires January 6, 2011 [Page 19]
Internet-Draft PMIPv6 flow mobility July 2010
sequence number in the Sequence Number field of the FMA.
When a MAG receives a packet carrying a valid Flow Mobility Initiate,
the MAG MUST perform the following packet examinations:
o If the MN-Identifier value carried into the FMI does not match any
MN known to be connected to the receiving MAG, the MAG MUST send
back an FMA with status code 129.
o If the format used in any of the Traffic Selector mobility options
is not supported by the receiving MAG, the MAG MUST send back an
FMA with status code 131.
o If the cancel ('C') flag is set to zero, it indicates that the FMI
refers to new flow(s). The MAG SHOULD check in the Flow Mobility
Cache if there is an entry referring to the flow(s) carried in the
FMI. If there is already an entry for a flow with Lifetime
greater than 0, then the the MAG SHOULD send back an FMA with
status code 133.
The MAG MUST create the corresponding Flow Mobility state entry,
and send back an FMA with status code 0 following the rules
specified in Section 6.2.
o If the refresh ('R') flag is set to 1, it indicates that the FMI
refers to existing flow(s) whose state is to be refreshed. The
MAG SHOULD check in the Flow Mobility Cache if there is an entry
referring to the flow(s) carried in the FMI. If there is no
entry, then the the MAG SHOULD send back an FMA with status code
132.
The MAG MUST update the corresponding Flow Mobility state entry or
entries, and send back an FMA with status code 0 following the
rules specified in Section 6.2.
o If the cancel ('C') flag is set to 1, it indicates that the FMI
refers to existing flow(s) whose state is to be removed. The MAG
SHOULD check in the Flow Mobility Cache if there is an entry
referring to the flow(s) carried in the FMI. If there is no
entry, then the the MAG SHOULD send back an FMA with status code
132.
The MAG MUST remove the corresponding Flow Mobility state entry or
entries, and send back an FMA with status code 0 following the
rules specified in Section 6.2.
Bernardos, et al. Expires January 6, 2011 [Page 20]
Internet-Draft PMIPv6 flow mobility July 2010
6.2. Sending Flow Mobility Acknowledge messages
When constructing a packet carrying a Flow Mobility Acknowledge, the
MAG MUST follow the following rules:
o Security considerations stated in Section 4 of [RFC5213] "Proxy
Mobile IPv6 Protocol Security" apply also for the signalling
specified in this document.
o EDITOR's NOTE: Additional authentication and security requirements
(if any) TBD.
o The IPv6 source address of the packet corresponds to the egress
interface of the MAG used to send the FMA to the LMA. (NOTE: this
is probably redundant once the security details are included).
o The IPv6 destination address MUST be set to the source address of
the FMI being acknowledged.
o The Sequence Number field MUST be copied from the Sequence Number
given in the FMI.
o The Lifetime field MUST be set to the remaining lifetime for the
flow binding and MUST NOT be greater than the Lifetime value
specified in the FMI. The MAG MAY decide to include a Lifetime
value shorter than the one received in the FMI.
o The values of the 'C' and 'R' flags MUST be copied from the values
given in the FMI.
o The Traffic Selector mobility options MUST be copied from the ones
given in the FMI.
When a valid FMI is received, the MAG MUST update the Flow Mobility
Cache entries accordingly as specified above. In addition, the MAG
MUST perform the actions required to allow packets received from the
LMA matching the flow filters stored in the Flow Mobility Cache to be
delivered to the corresponding connected MN. How this forwarding is
performed is up to the implementation of the MAG. Some
considerations are included in Section 6.4.
6.3. Conceptual Data Structures
Each Mobile Access Gateway MUST maintain a Flow Mobility Cache. The
Flow Mobility Cache MAY be implemented in any manner consistent with
the external behavior described in this document. When sending a
packet, the Flow Mobility Cache is searched before the Neighbor
Discovery conceptual Destination Cache.
Bernardos, et al. Expires January 6, 2011 [Page 21]
Internet-Draft PMIPv6 flow mobility July 2010
Each Flow Mobility Cache entry conceptually contains the following
fields:
o The MN-Identifier of the mobile node for the flow this Flow
Mobility Cache entry refers to. This field is used as primary key
for searching the cache for update operations (deletion, refresh,
cancel).
o The flow filter information carried in the Traffic Selector
mobility option. This information SHOULD be stored in a format
that allows the MAG to deliver packets matching the filter to the
corresponding MN (using the right interface where the MN is
locally connected).
o The Proxy-CoA from which that the FMA carrying the information
about this flow was sent.
o The tunnel interface identifier (tunnel-if-id) of the bi-
directional between the LMA and the MAG that MUST be used when
forwarding packets sent by the MN and belonging to the flow this
entry refers to. This is internal to the MAG. The tunnel
interface identifier is acquired during the tunnel creation in the
standard Proxy Mobile IPv6 registration.
o The interface identifier of the local interface of the MAG that
MUST be used when delivering packets sent to the MN and matching
the flow this entry refers to. This is internal to the MAG.
o The remaining lifetime of that flow binding. The lifetime value
is initialized from the Lifetime field in the FMI that created or
last modified this entry and is decremented until it reaches zero,
at which time this entry MUST be deleted from the Flow Mobility
Cache.
o The maximum value of the Sequence Number field received in
previous FMIs for this flow. The Sequence Number field is 16 bits
long. Sequence Number values MUST be compared modulo 2**16 as
explained in Section 9.5.1 of [RFC3775].
The Flow Mobility Cache is used to determine whether a particular
packet belongs to a flow which has flow mobility state created -- and
therefore needs to be processed separately from the rest of the
packets -- or it can just be sent using normal packet processing
rules as specified in RFC 5213.
Bernardos, et al. Expires January 6, 2011 [Page 22]
Internet-Draft PMIPv6 flow mobility July 2010
6.4. Packet Processing considerations
The MAG MUST be able to forward packets matching the flow filters
stored in the Flow Mobility Cache (carried in Traffic Selector
mobility options inside FMIs) via the corresponding bi-directional
tunnel.
For those packets with no match Flow Mobility Cache, default PMIPv6
data forwarding considerations MUST be followed.
How the MAG ensures per-flow forwarding is left up to the particular
implementation of the MAG.
7. 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.bernardos-netext-ll-statement]. In particular, it is assumed
that the logical interface at the MN "replicates" the behavior
observed for downlink packets on a per-flow basis. This means that
if packets belonging to flow X are received from interface if1, then
the MN sends packets belonging to that flow (in the uplink) also
using if1. 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.
8. IANA Considerations
TBD.
9. Security Considerations
TBD.
10. Primary contributors
This document reflects contributions from the following authors (in
alphabetical order).
Bernardos, et al. Expires January 6, 2011 [Page 23]
Internet-Draft PMIPv6 flow mobility July 2010
Kuntal Chowdhury
Vijay Devarapalli
E-mail: vijay@wichorus.com
Kent Leung
E-mail: kleung@cisco.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
Sri Gundavelli
E-mail: sgundave@cisco.com
11. Acknowledgments
TBD.
12. References
12.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.
Bernardos, et al. Expires January 6, 2011 [Page 24]
Internet-Draft PMIPv6 flow mobility July 2010
12.2. Informative References
[I-D.bernardos-netext-ll-statement]
Bernardos, C., Zuniga, J., and T. Melia, "Applicability
Statement on Link Layer implementation/Logical Interface
over Multiple Physical Interfaces",
draft-bernardos-netext-ll-statement-01 (work in progress),
March 2010.
[I-D.ietf-mext-binary-ts]
Tsirtsis, G., Giaretta, G., Soliman, H., and N. Montavont,
"Traffic Selectors for Flow Bindings",
draft-ietf-mext-binary-ts-04 (work in progress),
February 2010.
Authors' Addresses
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/
Mohana Dahamayanthi Jeyatharan
Panasonic Singapore Laboratories Pte Ltd
Blk 1022 Tai Seng Ave #06-3530
Tai Seng Industrial Estate Singapore 534415
SG
Phone: +65 65505494
Email: mohana.jeyatharan@sg.panasonic.com
Rajeev Koodli
Cisco Systems
USA
Email: rkoodli@cisco.com
Bernardos, et al. Expires January 6, 2011 [Page 25]
Internet-Draft PMIPv6 flow mobility July 2010
Telemaco Melia
Alcatel-Lucent
Route de Villejust
Nozay, Ile de France 91620
FR
Email: Telemaco.Melia@alcatel-lucent.com
Frank Xia
Huawei USA
1700 Alma Dr. Suite 500
Plano, TX 75075
USA
Phone: +1 972-509-5599
Email: xiayangsong@huawei.com
Bernardos, et al. Expires January 6, 2011 [Page 26]