One document matched: draft-bernardos-netext-pmipv6-flowmob-01.txt
Differences from draft-bernardos-netext-pmipv6-flowmob-00.txt
NETEXT Working Group CJ. Bernardos, Ed.
Internet-Draft UC3M
Intended status: Standards Track October 25, 2010
Expires: April 28, 2011
Proxy Mobile IPv6 Extensions to Support Flow Mobility
draft-bernardos-netext-pmipv6-flowmob-01
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 enhancements to the Proxy
Mobile IPv6 protocol that are required to support flow mobility 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."
This Internet-Draft will expire on April 28, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Bernardos Expires April 28, 2011 [Page 1]
Internet-Draft PMIPv6 flow mobility October 2010
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. Prefix model . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Flow mobility scenarios . . . . . . . . . . . . . . . . . . . 5
4.1. Unique prefix per physical interface . . . . . . . . . . . 5
4.1.1. Unique prefix per physical interface, with full
flow granularity . . . . . . . . . . . . . . . . . . . 6
4.1.2. Unique prefix per physical interface, with prefix
granularity (partial handoff) . . . . . . . . . . . . 9
4.2. Shared prefix across physical interfaces (per-MN HNP
set) . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Message formats . . . . . . . . . . . . . . . . . . . . . . . 15
5.1. Flow Mobility Initiate (FMI) . . . . . . . . . . . . . . . 15
5.2. Flow Mobility Acknowledge (FMA) . . . . . . . . . . . . . 17
6. Local Mobility Anchor considerations . . . . . . . . . . . . . 18
6.1. Sending Flow Mobility Initiate messages . . . . . . . . . 18
6.2. Receiving Flow Mobility Acknowledge messages . . . . . . . 19
6.3. Conceptual Data Structures . . . . . . . . . . . . . . . . 20
6.4. Packet Processing considerations . . . . . . . . . . . . . 22
7. Mobile Access Gateway considerations . . . . . . . . . . . . . 22
7.1. Receiving Flow Mobility Initiate messages . . . . . . . . 22
7.2. Sending Flow Mobility Acknowledge messages . . . . . . . . 24
7.3. Conceptual Data Structures . . . . . . . . . . . . . . . . 24
7.4. Packet Processing considerations . . . . . . . . . . . . . 26
8. Mobile Node considerations . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. Authors . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . . 28
13.2. Informative References . . . . . . . . . . . . . . . . . . 28
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29
Bernardos Expires April 28, 2011 [Page 2]
Internet-Draft PMIPv6 flow mobility October 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 Expires April 28, 2011 [Page 3]
Internet-Draft PMIPv6 flow mobility October 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.
3. Prefix model
Flow mobility assumes simultaneous access to more than one network,
in a contrast to a typical handover where connectivity to a physical
medium is relinquished, and is re-established with another. There
are multiple prefix models under which a flow mobility protocol needs
to work:
1. At the time of a new attachment, the MN obtains a new prefix or a
new set of prefixes. This is the default behavior with RFC 5213.
2. At the time of a new 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).
3. At the time of a new attachment, the MN obtains a combination of
prefix(es) in use and new prefix(es). This is a hybrid of the
above two 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 the above, scenario 2 needs extensions to RFC 5213 signaling at
Bernardos Expires April 28, 2011 [Page 4]
Internet-Draft PMIPv6 flow mobility October 2010
the time of a new attachment. Subsequently, no further signaling may
be necessary between the LMA and the MAG. The scenario 1 requires
flow mobility signaling whenever the LMA determines the need for
relocating flows between the different attachments. The scenario 3
requires flow mobility signaling whenever the LMA determines the need
for 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 the MN is going to receive traffic. As a result of a flow
mobility operation, these prefixes might not be limited to those
delegated by the MAG upon attachment of the connected interface, and
therefore signalling is required.
The extensions described in this document support any of the three
aforemention prefix models.
4. Flow mobility scenarios
Flow mobility signaling takes place whenever the LMA decides to move
a flow from one access to another. At this point, either the prefix
corresponding to the flow is already valid on the target MAG, or it
needs to be signaled. If the prefix is already valid, then the LMA
simply relocates the flow to the target MAG; no specific signaling is
required. For convenience, this scenario is called "shared prefix"
scenario.
If, at the time LMA decides to perform flow handover, the prefix
corresponding to the flow is not valid on the target MAG, the LMA
decides invoke flow mobility signaling specified in this document.
For convenience, this scenario is called "unique prefix" scenario,
since the the target prefix was "unique" to begin with.
When there is signaling involved, the granularity of the flow
mobility by default is at the prefix level. This means, the MAG only
needs to be able to support just the signaled prefix for forwarding
traffic, and is not involved detailed flow-level inspection. The
granularity of flow mobility MAY include detailed flow descriptors
beyond the prefix alone, and MAG implementations MAY support flow-
level inspection.
4.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
Bernardos Expires April 28, 2011 [Page 5]
Internet-Draft PMIPv6 flow mobility October 2010
(multiple mobility sessions) -- one per physical interface -- as well
as routing entries -- one per assigned prefix. This scenario is
shown in Figure 1.
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.
4.1.1. Unique prefix per physical interface, with full flow granularity
In this particular sub-scenario, full flow mobility management
granularity is supported, meaning that the LMA is able to perform
per-flow routing through different MAGs (e.g., in the example above,
HTTP traffic/particular flow intended to pref1::lif can be routed
through MAG1, while VoIP traffic/particular flow intended to the same
MN IP addess -- pref1::lif -- can be routed via MAG2).
Bernardos Expires April 28, 2011 [Page 6]
Internet-Draft PMIPv6 flow mobility October 2010
In this scenario, the LMA controls 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
FMI message contains (as explained in further detail in Section 5.1),
the MN-Identifier, the Flow Identification Mobility option (specified
in [I-D.ietf-mext-flow-binding]) which can convey prefix or full flow
information, 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,flow_info(Y),add] | |
| |---------------->| | |
| | FMA | | |
| |<----------------| | |
| LMA moves | | |
| flow Y | | |
| | (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 2: Flow mobility signaling for the unique prefix per physical
Bernardos Expires April 28, 2011 [Page 7]
Internet-Draft PMIPv6 flow mobility October 2010
interface scenario, with full granularity
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 a Flow
Mobility Option referring to flow Y. This option is defined in
[I-D.ietf-mext-flow-binding] as well as the Traffic selector sub-
option, which can be used to fully match a particular flow or just
the MN prefix information required by the MAG to be able to route
packets to the MN (the MAG by default is only aware of the prefixes
delegated to the MN by the LMA upon the MN's interface attachment to
the MAG, but is not aware of other MN's prefixes assigned to
different interfaces). 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
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.
Bernardos Expires April 28, 2011 [Page 8]
Internet-Draft PMIPv6 flow mobility October 2010
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, with full
flow granularity
Figure 3 shows the state of the different network entities after
moving flow Y in the previous example.
4.1.2. Unique prefix per physical interface, with prefix granularity
(partial handoff)
In this particular sub-scenario, only prefix mobility management
granularity is supported (partial handover), meaning that it involves
only transferring one (or some, but not all) of the prefixes that are
allocated to an existing interface to a newly powered on interface.
This is particularly useful if the second interface is a newly
connected interface, since that means there is no need for a new
prefix to be allocated to the second interface. It is also useful in
deployments where the operator requires only granularity of prefix
instead of 5-tuples for flow mobility management, possibily due to it
being less complex and having less impact to existing infrastructure.
One example of operators needing only prefix granularity is 3GPP.
In such partial transfer of prefix(es) scenario (refered to as
"partial handoff"), the target MAG will initiate the partial handoff
Bernardos Expires April 28, 2011 [Page 9]
Internet-Draft PMIPv6 flow mobility October 2010
trigger using the PBU message towards the LMA. The PBU will carry
the prefix(es) to be transferred in single or multiple HNP options.
The partial handoff PBU message will additionally carry a new handoff
indication option to indicate to the LMA that this PBU is for partial
handoff of sub set of prefix(es). The LMA upon seeing this PBU from
the target MAG with the partial handoff trigger embedded will update
its binding cache entries. The LMA will remove the transferred
prefix(es) from the binding cache associated with the connected
interface and create a new binding cache for the newly powered on
interface. The LMA may optionally send a message to source MAG 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 LMA. An example of the
signaling sequence is shown in Figure 4.
Bernardos Expires April 28, 2011 [Page 10]
Internet-Draft PMIPv6 flow mobility October 2010
+-----+ +------+ +------+ +-----+
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
| | | perform a L2 attachment
| | | |<-----------if2
| | PBU(pref2,HI=IANA-1) | |
| |<--------------------------------| |
| | PBA(pref2,HI=IANA-1) | |
| |-------------------------------->| |
| 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 4: Message Sequence for Partial Handoff to a New Interface
In Figure 4, MAG1 is considered to proxy/advertise the two prefixes
pref1 and pref2 that are assigned to if1 of the mobile node. From
Figure 4 it can be seen that 2 flows (flow x, flow y) tied to
prefixes pref1 and pref2 respectively are present. When the MN
detects the availability of another access (e.g. WLAN access), it
performs L2 attachment with MAG2 via this new access. MAG2 may
receive a partial handoff trigger together with the L2 attachment.
This trigger can be sent by other network entities (e.g. context
transfer from MAG1 or a policy server) or sent via a layer 2 (L2)
trigger from the MN during attachment. This partial handoff trigger
will indicate transfer of pref2.
When MAG2 receives the trigger for transfer of pref2, it will send a
Bernardos Expires April 28, 2011 [Page 11]
Internet-Draft PMIPv6 flow mobility October 2010
PBU message to the LMA with pref2 in the HNP option and a new value
IANA-1 for the HI option. This new Handoff Indicator value IANA-1
indicates that this is a partial handoff to a new interface. When
the LMA receives this PBU message, it will perform the following
actions. The LMA will first locate an existing binding cache entry
for mobile node with pref2. If the binding cache entry is present,
the LMA will remove the pref2 from this existing entry, and insert
the pref2 in the newly created binding cache entry for if2.
MAG1 can optionally be informed to stop proxying for the pref2. This
can be done by LMA sending a BRI notification to MAG1 to revoke
pref2. MAG1 upon receiving the BRI will send a BRA back to the LMA
as shown in Figure 4.
After the partial handoff is completed, the new binding cache entry
created for if2 will have pref2 assigned and the binding cache entry
for if1 will have pref1. This is shown in Figure 5.
LMA Binding Cache
+---+ =======================
|LMA| MN, if1, pref1, MAG1
+---+ MN, if2, pref2, MAG2
//\\
+---------//--\\-------------+
( // \\ ) 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)
|---|if1|if2|----| pref2::/64 p2p-iface-with-MN1
+---+---+ ::/0 LMA
MN
Figure 5: After Partial Handoff of pref2
Bernardos Expires April 28, 2011 [Page 12]
Internet-Draft PMIPv6 flow mobility October 2010
4.2. Shared prefix across physical interfaces (per-MN HNP set)
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 6. Extensions
to base PMIPv6 protocol as defined in RFC5213 are required to allow
the LMA decide to assign the same prefix to a different interface of
an MN already attached to the PMIPv6 domain.
There are different options that might be used to enable this
scenario. While this is still TBD, one simple approach that can be
assumed is the following. The LMA MAY know by using any mechanisms
out-of-the-scope of this document that an MN has to be assigned the
same prefix upon attachment of different interfaces (e.g. by
consulting the MN's profile).
LMA Binding Cache
+---+ =======================
|LMA| MN1, if1, pref1, MAG1
+---+ MN1, if2, pref1, MAG2
//\\
+---------//--\\-------------+
( // \\ ) PMIPv6 domain
( // \\ )
+------//--------\\----------+
// \\
// \\
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
| |
| +-------+ |
| | I P | |
| +-------+ |
| | lif | |
| +---+---+ |
|---|if1|if2|----|
+---+---+
MN1
Figure 6: Shared prefix across physical interfaces scenario
In Figure 6, 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
Bernardos Expires April 28, 2011 [Page 13]
Internet-Draft PMIPv6 flow mobility October 2010
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.
+-----+ +------+ +------+ +-----+
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 (optional) | |
| | FMI[MN1-ID,flow_info(Y),add] | |
| |---------------->| | |
| | FMA | | |
| |<----------------| | |
| LMA moves | | |
| flow Y | | |
| | (optional) | |
| | FMI[MN1-ID,flow_info(Y),del] | |
| |-------------------------------->| |
| | | FMA | |
| |<--------------------------------| |
| flow Y to | flow Y to | flow Y to |
| pref1:lif | pref1:lif | pref1:lif |
|<----------->|<--------------->|<-------------------------->if1
| | | | |
Figure 7: Flow mobility signaling for the shared prefix across
physical interfaces scenario
An example of the signaling sequence is shown in Figure 7. 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 Expires April 28, 2011 [Page 14]
Internet-Draft PMIPv6 flow mobility October 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 8: Shared prefix across physical interfaces scenario
Figure 8 shows the state of the different network entities after
moving flow Y in the previous example.
5. Message formats
5.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 Expires April 28, 2011 [Page 15]
Internet-Draft PMIPv6 flow mobility October 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 Expires April 28, 2011 [Page 16]
Internet-Draft PMIPv6 flow mobility October 2010
MUST contain the MN-ID, followed by one or more Flow
Identification Mobility options [I-D.ietf-mext-flow-binding].
5.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 Expires April 28, 2011 [Page 17]
Internet-Draft PMIPv6 flow mobility October 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 Flow Identification Mobility options
[I-D.ietf-mext-flow-binding].
6. 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.
6.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 Flow Identification Mobility
option. This 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 Flow Identification
Mobility 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.
Bernardos Expires April 28, 2011 [Page 18]
Internet-Draft PMIPv6 flow mobility October 2010
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 Flow Identification Mobility 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 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 Flow Identification
Mobility 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.
6.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.
Bernardos Expires April 28, 2011 [Page 19]
Internet-Draft PMIPv6 flow mobility October 2010
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
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 sub-options are forwarded via the
appropriate MAG. How this is done is left up to the
implementation of the LMA.
6.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
Bernardos Expires April 28, 2011 [Page 20]
Internet-Draft PMIPv6 flow mobility October 2010
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 sub-
option. This information SHOULD be stored in a format 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
Bernardos Expires April 28, 2011 [Page 21]
Internet-Draft PMIPv6 flow mobility October 2010
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.
6.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 sub-
options inside the Flow Identification Mobility option carried in the
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.
7. Mobile Access Gateway considerations
This section details the MAG operations necessary to implement this
specification.
7.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 Flow Identification Mobility options.
Any Flow Mobility Initiate not satisfying all of these tests MUST be
silently ignored.
Bernardos Expires April 28, 2011 [Page 22]
Internet-Draft PMIPv6 flow mobility October 2010
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
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 sub-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 7.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 7.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
Bernardos Expires April 28, 2011 [Page 23]
Internet-Draft PMIPv6 flow mobility October 2010
rules specified in Section 7.2.
7.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 Flow Identification 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 7.4.
7.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
Bernardos Expires April 28, 2011 [Page 24]
Internet-Draft PMIPv6 flow mobility October 2010
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 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 sub-
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 Expires April 28, 2011 [Page 25]
Internet-Draft PMIPv6 flow mobility October 2010
7.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 sub-
options inside the Flow Identification Mobility options carried in
the 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.
It might happen that the LMA initiates the movement of a flow, by
sending the FMI/FMA signalling, but there is no traffic to the MN.
In that case, the MN cannot learn which is the uplink interface that
should be used. In order to avoid problems in this particular
situation, the MAG SHOULD allow uplink traffic to pass through --
even if it does not match the flow filters stored in the FMC (at
least for traffic that would be sent through that MAG in case flow
mobility was not enabled).
8. 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 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.
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.
9. IANA Considerations
TBD.
Bernardos Expires April 28, 2011 [Page 26]
Internet-Draft PMIPv6 flow mobility October 2010
10. Security Considerations
TBD.
11. Authors
This document reflects contributions from the following authors (in
alphabetical order).
Kuntal Chowdhury
E-mail: Kchowdhu@cisco.com
Vijay Devarapalli
E-mail: vijay@wichorus.com
Sri Gundavelli
E-mail: sgundave@cisco.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
Bernardos Expires April 28, 2011 [Page 27]
Internet-Draft PMIPv6 flow mobility October 2010
Behcet Sarikaya
E-mail: sarikaya@ieee.org
Frank Xia
E-mail: xiayangsong@huawei.com
12. Acknowledgments
The authors would like to thank Juan-Carlos Zuniga, Pierrick Seite,
Julien Laganier for all the discussions on this topic.
13. References
13.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.
[RFC5846] Muhanna, A., Khalil, M., Gundavelli, S., Chowdhury, K.,
and P. Yegani, "Binding Revocation for IPv6 Mobility",
RFC 5846, June 2010.
13.2. Informative References
[I-D.ietf-mext-flow-binding]
Tsirtsis, G., Soliman, H., Montavont, N., Giaretta, G.,
and K. Kuladinithi, "Flow Bindings in Mobile IPv6 and NEMO
Basic Support", draft-ietf-mext-flow-binding-11 (work in
progress), October 2010.
[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-01 (work in
progress), October 2010.
Bernardos Expires April 28, 2011 [Page 28]
Internet-Draft PMIPv6 flow mobility October 2010
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 April 28, 2011 [Page 29]
| PAFTECH AB 2003-2026 | 2026-04-24 06:44:18 |