One document matched: draft-larsson-netext-pmipv6-sma-flow-mobility-00.txt
NetExt Working Group C. Larsson
Internet-Draft M. Eriksson
Intended status: Standards Track P. Arvidsson
Expires: September 5, 2009 Ericsson Research
March 4, 2009
Simultaneous Multi-Access and Flow Mobility Support for PMIPv6
draft-larsson-netext-pmipv6-sma-flow-mobility-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 5, 2009.
Copyright Notice
Copyright (c) 2009 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 in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Larsson, et al. Expires September 5, 2009 [Page 1]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
Abstract
This document specifies how flow mobility can be realized for a
mobile node with multiple network interfaces, for which the network
provides mobility support by means of Proxy Mobile IPv6 (PMIPv6). By
introducing a "Primary Prefix", the mobile node is able to maintain
IP data sessions when moving between different network interfaces.
This document introduces a new set of ICMP and Mobility Header
messages. It requires modifications of the mobile node. However,
since support for simultaneous multi-access and flow mobility
requires modifications of the mobile node anyway, the modifications
suggested in this document are considered to be modest.
The suggested enhancement is fully backwards compatible with the base
Proxy Mobile IPv6 specification. The mobile node may be an IPv4-only
node, IPv6-only node, or a dual-stack node.
Larsson, et al. Expires September 5, 2009 [Page 2]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 6
2.1. Conventions . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . 6
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Allocation of Primary Prefix . . . . . . . . . . . . . . 7
3.2. Attaching additional network interfaces . . . . . . . . 8
3.3. Registration of Routing Rules . . . . . . . . . . . . . 9
3.4. Mobile Node movement . . . . . . . . . . . . . . . . . . 10
3.5. Sending packets to/from the Mobile Node . . . . . . . . 11
4. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 15
4.1. Acquiring Primary Prefix . . . . . . . . . . . . . . . . 15
4.2. Receiving Primary Prefix . . . . . . . . . . . . . . . . 15
4.3. Prefix and BID Binding Registration . . . . . . . . . . 15
4.4. Prefix and BID Binding Registration Acknowledgement . . 16
4.5. Sending/Receiving Routing Rule Update . . . . . . . . . 17
4.6. Sending/Receiving Routing Rule Update Acknowledgement . 17
5. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 19
5.1. Extensions to BUL Entry Data Structure . . . . . . . . . 19
5.2. Acquiring Primary Prefix . . . . . . . . . . . . . . . . 19
5.3. Receiving Primary Prefix . . . . . . . . . . . . . . . . 19
5.4. Relaying of Binding Registring between BID and Prefix . 20
5.5. Relaying Routing Rules Registration . . . . . . . . . . 20
5.6. Mobile Node De-registration . . . . . . . . . . . . . . 22
6. Local Mobility Agent Operation . . . . . . . . . . . . . . . . 23
6.1. Extensions to BC Entry Data Structure . . . . . . . . . 23
6.2. Recieving Proxy Primary Prefix Request . . . . . . . . . 23
6.3. Prefix and BID Binding Registration . . . . . . . . . . 23
6.4. Sending Proxy Primary Prefix Update . . . . . . . . . . 24
6.5. Registration of Routing Rules . . . . . . . . . . . . . 24
7. New ICMP and Mobility Header messages . . . . . . . . . . . . 25
7.1. New ICMP Messages . . . . . . . . . . . . . . . . . . . 25
7.1.1. ICMP Primary Prefix Request . . . . . . . . . . 25
7.1.2. ICMP Primary Prefix Acknowledgement . . . . . . 26
7.1.3. ICMP Primary Prefix Binding Update . . . . . . . 27
7.1.4. ICMP Primary Prefix Binding Acknowledgement . . 29
7.1.5. ICMP Routing Rules Update . . . . . . . . . . . 30
7.1.6. ICMP Routing Rules Acknowledgement . . . . . . . 31
7.2. New Mobility Header Messages . . . . . . . . . . . . . . 32
7.2.1. Proxy Primary Prefix Request Message . . . . . . 32
7.2.2. Proxy Primary Prefix Acknowledgement Message . . 34
7.2.3. Proxy Primary Prefix BU Message . . . . . . . . 35
7.2.4. Proxy Primary Prefix BA Message . . . . . . . . 37
7.2.5. Proxy Primary Prefix Update Message . . . . . . 38
7.2.6. Proxy Primary Prefix Update Ack Message . . . . 39
7.2.7. Proxy Routing Rules Update Message . . . . . . . 40
Larsson, et al. Expires September 5, 2009 [Page 3]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
7.2.8. Proxy Routing Rules Ack Message . . . . . . . . 42
8. Security Considerations . . . . . . . . . . . . . . . . . . . 44
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 46
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 47
11.1. Normative References . . . . . . . . . . . . . . . . . . 47
11.2. Informative References . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 48
Larsson, et al. Expires September 5, 2009 [Page 4]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
1. Introduction
Proxy Mobile IPv6 (PMIPv6) allows a mobile node to connect to a
PMIPv6 domain through multiple network interfaces. When the multi-
interfaced mobile node connects to the PMIPv6 domain, the Local
Mobility Anchor (LMA) must allocate a new mobility session for each
of the attached interfaces. The LMA may allocate more than one home
network prefix for a given interface of the mobile node. All the
prefixes associated with a given interface must be managed as part of
one mobility session, associated with that interface.
The PMIPv6 specification does not specify how to maintain sessions
that must survive loss of network connectivity. A typical scenario
is when a user has a laptop with both WLAN and 3GPP network
interfaces. Multiple IP data sessions have been established, some of
the sessions over WLAN and the remaining sessions over 3GPP. When
the user moves out of WLAN coverage, sessions initiated over the WLAN
access will be terminated according to PMIPv6. Another example would
be that the user in the previous scenario remains within the WLAN
coverage, but due to traffic congestion over the WLAN access either
the mobile node or the network decides to move some or all data
sessions from the WLAN to the 3GPP access network.
The above examples are just two examples when support for
simultaneous multi-access and flow mobility would be beneficial for
the end user and the network operator. One potential solution to the
above problems is to implement Mobile IPv6 (MIPv6) in the mobile
node, as described in [RFC3775]. However, when there are reasons for
not implementing a mobility management solution in the mobile node,
the solution described in this specification is preferable.
Larsson, et al. Expires September 5, 2009 [Page 5]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
2. Conventions and Terminology
2.1. Conventions
In this document, several words are used to signify the requirements
of the specification. These words are often capitalized. 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].
2.2. Terminology
All the general mobility-related terms used in this document are to
be interpreted as defined in the Mobile IPv6 base specification
[RFC3775] and the Proxy Mobile IPv6 base specification [RFC5213].
This document frequently uses the following terms:
Primary Prefix
A network prefix which allows simultaneous use of multiple
accesses and flow mobility. It is bound to a virtual
interface, and Routing Rules are used to place flows on
available physical interfaces.
Routing Rules
Rules that control over which available physical interface
each primary prefix flow is transferred.
Larsson, et al. Expires September 5, 2009 [Page 6]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
3. Overview
To facilitate simultaneous multi-access and flow mobility, an
additional prefix, the so called "Primary Prefix", is allocated to
the mobile node. An address derived from the Primary Prefix is used
as permanent IP address for applications to bind their sockets to.
Applications that must sustain partial loss of network connectivity
should use an address derived from this Primary Prefix.
Simultaneous multi-access and flow mobility implies that there must
exist functionality in the mobile node that can decide how different
data flows should be sent over available network interfaces. A
session can be identified by several parameters. In
[I-D.larsson-mext-flow-distribution-rules], a set of parameters for
identifying sessions are defined. All parameters needed to identify
a session constitute a so called Routing Rule. Additionally,
[I-D.larsson-mext-flow-distribution-rules] explains how each routing
rule is associated with a BID. How routing rules are generated and
how the associations between BIDs and Home Network Prefixes are
created is outside the scope of this document. This document assumes
that this information is available and explains how to make use of
it.
To achieve simultaneous multi-access and flow mobility, some
modifications to the mobile node are required. This specification
enables the mobile node to request a Primary Prefix and to establish,
for each Home Network Prefix assigned to the mobile node, a binding
to a unique Binding Identifier (BID) [I-D.ietf-monami6-multiplecoa].
It also allows either the mobile node or the network (via the LMA) to
update the routing rules required for simultaneous multi-access and
flow mobility. Finally, it allows the network to update Mobile
Access Gateways about the mobile node's Primary Prefix to ensure that
packet forwarding between the LMA and the mobile node is working
properly.
3.1. Allocation of Primary Prefix
A mobile node with support for simultaneous multi-access sends a
request to the access network asking for a Primary Prefix. If the
network is a PMIP enabled network, the MAG, when receiving the ICMP
Primary Prefix Request, sends a "Proxy Primary Prefix Request" to the
LMA asking for a Primary Prefix to be allocated to the mobile node.
Upon receiving the Proxy Primary Prefix Request the LMA allocates the
Primary Prefix and creates a new Binding Cache entry for the Primary
Prefix. The LMA then sends a "Proxy Primary Prefix Acknowledgement"
back to the MAG. Upon receiving the "Proxy Primary Prefix
Acknowledgement" the MAG updates its Binding Update List entry.
Larsson, et al. Expires September 5, 2009 [Page 7]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
Additionally, it ensures that packets with a source address derived
from the Primary Prefix arriving from the mobile node are accepted
and tunneled towards the LMA. The MAG will also accept and forward
packets from the LMA to the mobile node in which the destination
address of the inner packet is inside the Primary Prefix.
The MAG sends an "ICMP Primary Prefix Acknowledgement" back to the
mobile node. Once the mobile node receives the acknowledgement the
prefix is allocated to a "virtual interface". Addresses derived from
the Primary Prefix are then used for sessions that needs to sustain
movement between different physical network interfaces. The Home
Network Prefix, allocated as described in [RFC5213], can still be
used, but these sessions can not be moved between different physical
network interfaces.
MN MAG LMA
| | |
|-------->| | 1. ICMP Primary Prefix Request
| | |
| |------->| 2. Proxy Primary Prefix Request
| | |
| |<-------| 3. Proxy Primary Prefix Acknowledgement
| | |
|<--------| | 4. ICMP Primary Prefix Acknowledgement
| | |
Figure 1: Allocation of Primary Prefix
3.2. Attaching additional network interfaces
As the mobile node attaches new interfaces to the PMIPv6 domain, each
interface is assigned a new set of prefixes according to [RFC5213].
According to [I-D.ietf-monami6-multiplecoa] a multi-homed node that
registers multiple care-of addresses to the same HoA must associate
each new CoA with a unique BID. The analogue is true for a mobile
node with support for flow mobility, but instead of using the CoA the
Home Network Prefixes assigned to the network interface are used.
Consequently, the mobile node will send information about the current
binding between the Home Network Prefix and the BID to the LMA. In
Mobile IPv6, the binding between the BID and the CoA is associated
with the Home Address. In this case, the association between the BID
and the Home Network Prefix is instead associated with the Primary
Prefix.
When a mobile node decides to register a binding between a BID and a
Home Network Prefix, it allocates a BID for the Home Network Prefix
Larsson, et al. Expires September 5, 2009 [Page 8]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
and sends a request to the LMA (via the MAG) with the binding
information. The MAG forwards the message to the LMA, which
establish the required binding between the BID and the Home Network
Prefix. Information about the binding is stored in the Binding Cache
Entry for the Primary Prefix. The LMA then acknowledge the request
and indicates the status of the binding request in the reply.
Upon receiving the acknowledgement from the LMA, the MAG ensures that
it accepts packets using the Primary Prefix in the same way as
packets using the Home Network Prefix. I.e., the MAG ensures that
packets, with a source address derived from the Primary Prefix,
arriving from the mobile node are accepted and tunneled towards the
LMA. The MAG will also accept and forward packets from the LMA to
the mobile node in which the destination address of the inner packet
is inside the Primary Prefix. The MAG finally acknowledge the
request back to the mobile node.
MN MAG LMA
| | |
|-------->| | 1. ICMP Primary Prefix Binding Update
| | |
| |------->| 2. Proxy Primary Prefix Binding Update
| | |
| |<-------| 3. Proxy Primary Prefix Binding Acknowledgement
| | |
|<--------| | 4. ICMP Primary Prefix Binding Acknowledgement
| | |
Figure 2: Attaching additional network interfaces
3.3. Registration of Routing Rules
How the flows are sent over the different physical interfaces can be
decided either by the network or in the mobile node. According to
[I-D.larsson-mext-flow-distribution-rules], each routing rule is
associated with a BID. The current active set of routing rules must
be known by both the network (LMA) and the mobile node.
If the mobile node creates the routing rules, the Routing Rules
Update message is initiated from the mobile node and the sequence
diagram is as depicted below. At the LMA the Routing Rules are
stored in the Binding Cache entry for the Primary Prefix.
Larsson, et al. Expires September 5, 2009 [Page 9]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
MN MAG LMA
| | |
|-------->| | 1. ICMP Routing Rules Update
| | |
| |------->| 2. Proxy Routing Rules Update
| | |
| |<-------| 3. Proxy Routing Rules Acknowledgement
| | |
|<--------| | 4. ICMP Routing Rules Acknowledgement
| | |
Figure 3: Mobile node initiating Routing Rules Update
Once the LMA has accepted the routing rules, a "Proxy Routing Rules
Acknowledgement" is sent back to the MAG. The MAG does not store any
information about the Routing Rules. It only holds information about
the Primary Prefix for the mobile node. The MAG forwards the
acknowledgement from the LMA to the mobile node. If the Routing
Rules update message was successful, the mobile node can start to
forward the packets accordingly. In case of an unsuccessful Routing
Rules Update, the flows will remain on existing network interfaces.
If the network creates the routing rules, the Routing Rules Update
message is initiated from the LMA and the sequence diagram is as
depicted below. At the LMA, the Routing Rules are stored in the
Binding Cache Entry for the Primary Prefix.
MN MAG LMA
| | |
| |<-------| 1. Proxy Routing Rules Update
| | |
|<--------| | 2. ICMP Routing Rules Update
| | |
|-------->| | 3. ICMP Routing Rules Acknowledgement
| | |
| |------->| 4. Routing Rules Acknowledgement
| | |
Figure 4: LMA initiating Routing Rules Update
3.4. Mobile Node movement
As the mobile node moves to a new MAG in the PMIPv6 domain this is a
movement that is transparent for the mobile node. Hence, if the
mobile node has allocated a Primary Prefix this information must also
be known by the new MAG to ensure that it can route packets to/from
Larsson, et al. Expires September 5, 2009 [Page 10]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
the mobile node.
The new MAG sends a Proxy Binding Update according to [RFC5213]. the
LMA, when processing the PBU, looks into its Binding Cache to see if
a Primary Prefix has been allocated to this mobile node. If this is
the case the LMA includes a Primary Prefix option in the PBA sent to
the MAG. If no Primary Prefix has been allocated to the mobile node
then an ordinary PBA according to [RFC5213] is sent to the MAG.
Upon receiving the PBA from the LMA the MAG ensures that it accepts
packets using the Primary Prefix in the same way as packets using the
Home Network Prefix. I.e., the MAG ensures that packets, with a
source address derived from the Primary Prefix, arriving from the
mobile node are accepted and tunneled towards the LMA. The MAG will
also accept and forward packets from the LMA to the mobile node in
which the destination address of the inner packet equals the Primary
Prefix.
MN MAG LMA
| | |
|-------->| | 1. MN attaches to a new MAG
| | |
| |------->| 2. PBU
| | |
| |<-------| 3. PBA (incl. Primary Prefix option)
| | |
| | |
Figure 5: New MAG learns Primary Prefix
3.5. Sending packets to/from the Mobile Node
To explain how traffic is sent from and to a mobile node, a scenario
is drawn with the following assumptions:
o The mobile node has two active network interfaces, interface 1
(IF1) connected to MAG1 and interface 2 (IF2) connected to MAG2.
o Home Network Prefix 1 (HNP1) has been allocated to IF1 and Home
Network Prefix 2 (HNP2) has been allocated to IF2.
o Since this mobile node has support for simultaneous multi-access
and flow mobility, it has requested and successfully been
allocated a Primary Prefix (PP). This Primary Prefix is typically
allocated to a virtual interface and used by applications when
connecting to a socket.
Larsson, et al. Expires September 5, 2009 [Page 11]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
o A set of Routing Rules with associated Binding Identifiers and the
relation between each Home Network Prefix and BID have been
created, either by the mobile node or the network. The actual
procedure for creating these relations are outside the scope of
this document. This information has been stored both at the
mobile node and in the LMA. How this information is transferred
between the mobile node and the LMA is described in Sections 3.2
and 3.3.
List of Routing Rules:
Routing Rule A <--> BID1
Routing Rule B <--> BID2
Relation between BID and Home Network Prefix:
BID1 <--> HNP1
BID2 <--> HNP2
o The Mobile Node (MN) is communicating with a Correspondent Node
(CN).
The below figure outlines the described example. There exist a set
of routing rules, each one associated with a BID, and a binding list
describing how each Home Network Prefix is associated with a BID. In
the LMA, this information is stored with the Primary Prefix. How
this information is stored in the mobile node is implementation
dependent and outside the scope of this document.
Larsson, et al. Expires September 5, 2009 [Page 12]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
+----+
| CN |
+----+
| LMA Binding Cache:
| ==================
+-------+ MN-ID: HNP1; ...
| LMA | MN-ID: HNP2; ...
+-------+ MN-ID: PP;
/ \ Routing Rule A <--> BID1;
/ \ Routing Rule B <--> BID2;
/ \ HNP1 <--> BID1;
/ \ HNP2 <--> BID2;
+------+ +------+
| MAG1 | | MAG2 |
+------+ +------+
\ /
\ /
\ /
+-----------+
IF1: HNP1 | IF1 | IF2 | IF2: HNP2
+-----+-----+
| PP |
+-----------+
Mobile Node
Figure 6: Network
When the mobile node sends a packet to the CN, the source address of
the packet is an address derived from the Primary Prefix and the
destination address is the address of the CN. As the mobile node
processes the outgoing packet, it will get a match on one of the
routing rules. This Routing Rule is associated with a BID, which in
turn is associated with a Home Network Prefix assigned to one of the
physical network interfaces.
At this stage, the mobile node knows on which interface to send the
packet and it transmits the packet on this interface. The MAG
receiving the packet recognizes the prefix of the source address as
the Primary Prefix and tunnels the packet towards the same LMA as it
would have done for any of the Home Network Prefixes advertised on
this link.
When the LMA receives the tunneled packet, it decapsulates it and
routes it towards the CN.
When an LMA receives a packet from a CN, it will search the Binding
Cache for an entry. In this specific case, this entry will be an
Larsson, et al. Expires September 5, 2009 [Page 13]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
entry holding the Primary Prefix. The LMA matches the incoming
packet against the Routing Rules stored in the found BC entry. As a
result of this matching a Routing Rule is found. This Routing Rule
is associated with a BID, which in turn is associated with a Home
Network Prefix. The Binding Cache entry for the Home Network Prefix
holds all information required for tunneling the packet towards the
MAG.
When the MAG receives the tunneled packet, it decapsulates it and
verifies that the prefix in the destination address is inside the
Primary Prefix of the mobile node. It then forwards the packet to
the mobile node.
Larsson, et al. Expires September 5, 2009 [Page 14]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
4. Mobile Node Operation
This section defines the mobile node operation.
4.1. Acquiring Primary Prefix
When a mobile node decides that it has a need for simultaneous multi-
access it will start the procedure of acquiring a Primary Prefix.
This decision is typically made by either the user or an automated
access selection system, but exactly how is outside the scope of this
document. The following steps MUST be taken by the mobile node in
order to initiate the Primary Prefix Acquiring process.
o The mobile node MUST construct an ICMP Primary Prefix Request
message. In this message the mobile node MUST set the HNP field
to a valid HNP that it earlier received from the network. The
value of the BID MUST be set by the mobile node to a value that it
want to identify the binding between the HNP and Primary Prefix.
The sequence number field must be set to a valid sequence number.
o The mobile node MUST send this message to the next hop router on
the access where the HNP set in the message is configured.
4.2. Receiving Primary Prefix
On receiving a ICMP Primary Prefix Acknowledgment a mobile node MUST
process the message as described below.
o The mobile node MUST verify that the message received is a
response to a previously sent ICMP Primary Prefix Request. This
done by comparing the HNP and sequence number fields with the
fields stored when sending the message. If the values does not
match the mobile node MUST NOT proceed with any of the steps
listed below.
o The mobile node MUST create a virtual interface (or equivalent) to
which it sets an address generated from the Primary Prefix
received. It MUST also set up the local binding between the
Primary Prefix and the HNP. This binding will be identified by
the BID.
4.3. Prefix and BID Binding Registration
Generally, there is no requirement for the mobile node to use SMA
support in order to provide backwards compatibility with the PMIPv6
[RFC5213]. In the case such decision is taken by a mobile node, MN
will initiate procedure described in Section XXX. This procedure
will result in a single binding of one of HNP used for sending
Larsson, et al. Expires September 5, 2009 [Page 15]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
Primary Prefix Request message. Later on a mobile node MAY decide to
create bindings for other interfaces in the MN. This may happen due
to the fact that new interfaces will be configured in the MN, which
did not exist before. Another example is that MN did not have many
flows active simultaneously and there were no need to send them
through different interfaces. If mobile node sends ICMP Primary
Prefix BU message:
o it MUST set the HNP field to a valid HNP that it earlier received
from the network. The value of the BID MUST be set by the mobile
node to a value that it want to identify the binding between the
HNP and Primary Prefix. The sequence number field must be set to
a valid sequence number
o The mobile node MUST send this message to the next hop router on
the access where the HNP set in the message is configured.
4.4. Prefix and BID Binding Registration Acknowledgement
Upon receiving ICMP Primary Prefix BA message, MN MUST verify the
following:
o The message received is a response to a previously sent ICMP
Primary Prefix BU. This done by comparing the HNP and sequence
number fields with the fields stored when sending the message. If
the values does not match the mobile node MUST NOT proceed with
any of the steps listed below.
o The mobile node MUST verify the status code of the received
message. If status code indicates success of the operation,
mobile node MUST update its binding cache with the correspondent
BID and HNP values.
o Mobile node MUST verify if the current Routing Rules set is
consistent with the acknowledged Primary Prefix BU message.
o If the Routing Rules set not consistent with the currently
established bindings, the mobile node MUST initiate procedure for
Routing Rules update.
In the case, ICMP Primary Prefix BA message indicate failure of
operation, the mobile node SHOULD make an attempt to retransmit the
ICMP Primary Prefix BU message. The recommended number of
retransmissions is TBD.
Larsson, et al. Expires September 5, 2009 [Page 16]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
4.5. Sending/Receiving Routing Rule Update
This document assumes that Routing Rules
[I-D.larsson-mext-flow-distribution-rules,
I-D.eriksson-mext-mipv6-routing-rules] can be sent bidirectionally,
i.e. by mobile node, due to changes of policies or interfaces
availability in mobile node, or by LMA, due to changes of policies at
the network side. The Routing Rules update message exchange is
identical in either direction.
Bindings updates and Routing Rules exchange between mobile nodes and
LMA is entirely decoupled and does not necessarily require both
updates following each other. The reason for that is access
selection policies control over what kind of update and when this
update should take place. For example, if a mobile node or network
makes a decision of moving a flow from one interface to another,
there is no need for binding update, because BIDs and HNPs are not
changed. The Routing Rules update procedure should take place only
if there are no any conditional rules
[I-D.larsson-mext-flow-distribution-rules,
I-D.eriksson-mext-mipv6-routing-rules] specified earlier, or there
are no any rules at all, which will conduct flows appropriately. On
the other hand, if, for example, one of interfaces will be de-
configured in the mobile host, and there were no traffic going
through that interface, there is no need to change Routing Rules.
Rather only bindings have to be synchronized between mobile node and
LMA.
Mobile node MUST NOT send Routing Rules Update messages if there is
no any Primary Prefix configured in the mobile node.
Mobile node MUST send Routing Rules Update message whenever it
discovers inconsistency between currently installed bindings and
routing rules. An ICMP message is used for this purpose, see Section
XXX. Routing Rules are associated with a host,independently on how
many interfaces are active in the host. Thus, along with the Routing
Rules, the mobile node MUST send a Primary Prefix, which will be
associated with the Routing Rules.
4.6. Sending/Receiving Routing Rule Update Acknowledgement
Upon receiving ICMP Routing Rules Update Ack message, mobile node
MUST verify that the sequence number in this message corresponds to
the one sent in ICMP Routing Rules Update message. Mobile node MUST
examine the status code in the ICMP Routing Rules Update Ack message.
If the status code indicates success, the mobile node will continue
its operation as normal, i.e. keep flow distribution among interfaces
according to the latest updates of BIDs and RRs. If status code
Larsson, et al. Expires September 5, 2009 [Page 17]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
indicates failure, mobile node SHOULD start retransmission of ICMP
Routing Rules Update message. The recommended number of
retransmissions is TBD. If mobile node fails to update Routing
Rules, it MUST fail over to any (up to mobile node) consistent
combination of interfaces bindings and Routing Rules set.
Larsson, et al. Expires September 5, 2009 [Page 18]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
5. Mobile Access Gateway Operation
This section explains the mobile access gateway operation.
5.1. Extensions to BUL Entry Data Structure
As described in Section 6.1 of [RFC5213] every Mobile Access Gateway
MUST maintain a Binding Update List. Each entry in this list
represents a mobile node's mobility binding with its Local Mobility
Anchor. To support this specification the Binding Update List entry
data structure MUST be extended with the following fields:
Primary Prefix
A list of Primary Prefixes of the mobile node.
5.2. Acquiring Primary Prefix
On receiving a ICMP Primary Prefix Request the Mobile Access Gateway
MUST process the message as specified below.
o The Mobile Access Gateway MUST construct a Proxy Primary Prefix
Request message. This message MUST contain the HNP and BID fields
set to the value of the corresponding fields of the received ICMP
Primary Prefix Request. The message MUST also contain the MN-ID
from the BUL entry associated with this mobile node.
o The Mobile Access Gateway MUST send the message constructed to the
IPv6 address of the Local Mobility Anchor that is contained in the
BUL entry associated with this mobile node.
5.3. Receiving Primary Prefix
On receiving a Proxy Primary Prefix Acknowledgement a Mobile Access
Gateway MUST process the message as specified below.
o The Mobile Access Gateway MUST read the Primary Prefix field of
the received message and set up its ingress filter so that any
packet from the Primary Prefix can pass. It MUST also set up
tunneling for the Primary Prefix to the Local Mobility Anchor and
add it to the list of Primary Prefixes in the BUL entry
corresponding to the mobile node.
o The Mobile Access Gateway MUST send a ICMP Primary Prefix
Acknowledgement message to the mobile node's link local address.
This message MUST contain the Primary Prefix, HNP, BID and
sequence number received in the Primary Prefix Binding
Acknowledgement.
Larsson, et al. Expires September 5, 2009 [Page 19]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
5.4. Relaying of Binding Registring between BID and Prefix
On receiving an ICMP Primary Prefix Binding Update Request a Mobile
Access Gateway MUST process the message as specified below.
o The Mobile Access Gateway MUST construct a Proxy Primary Prefix
Binding Update message. It MUST set the BID, HNP Primary Prefix
and sequence number fields of this message to the values of the
corresponding fields in the received ICMP Primary Prefix Request.
The MN-ID field of the Proxy Primary Prefix Binding Update message
MUST be set to the value of the MN-Identifier found in the
corresponding BUL entry.
o The Mobile Access Gateway MUST send the message constructed to the
IPv6 address of the Local Mobility Anchor that is contained in the
BUL entry associated with this mobile node.
On receiving an Proxy Primary Prefix Binding Update Response a Mobile
Access Gateway MUST process the message as specified below.
o The Mobile Access Gateway MUST read the Primary Prefix field of
the received message and set up its ingress filter so that any
packet from the Primary Prefix can pass. It MUST also set up
tunneling for the Primary Prefix to the Local Mobility Anchor and
add it to the list of Primary Prefixes in the BUL entry
corresponding to the mobile node.
o The Mobile Access Gateway MUST add the Primary Prefix received to
the Primary Prefix field of the corresponding BUL entry. If the
Primary Prefix is already in the list it should not be added.
o The Mobile Access Gateway MUST setup its ingress filter so that it
allows packets sent from the Primary Prefix to be received and
forwarded on the interface that the mobile node is connected to.
o The Mobile Access Gateway MUST send a ICMP Primary Prefix Binding
Acknowledgement message to the mobile node's link local address.
This message MUST contain the sequence number and the status field
received in the Primary Prefix Binding Update Response.
5.5. Relaying Routing Rules Registration
On receiving an ICMP Routing Rules Update Request a Mobile Access
Gateway MUST process the message as specified below.
o The Mobile Access Gateway MUST construct a Proxy Routing Rules
Update message. It MUST set the Primary Prefix and sequence
number fields of this message to the values of the corresponding
Larsson, et al. Expires September 5, 2009 [Page 20]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
fields in the received ICMP Primary Prefix Request. It MUST also
copy the Routing Rules payload of the received message to the
Routing Rules payload field of the newly constructed message. The
MN-ID field of the Primary Prefix Binding Update message MUST be
set to the value of the MN-Identifier field found in the
corresponding BUL entry.
o The Mobile Access Gateway MUST send the message constructed to the
IPv6 address of the Local Mobility Anchor that is contained in the
BUL entry associated with this mobile node.
On receiving a Proxy Routing Rules Acknowledgment a Mobile Access
Gateway MUST process the message as specified below.
o The Mobile Access Gateway MUST send a ICMP Routing Rules Update
Acknowledgement message to the mobile node's link local address.
This message MUST have the sequence number and the status field
set to the values received in the Proxy Routing Rules Update
Acknowledgment. It MUST also copy the Routing Rules payload of
the received message to the Routing Rules payload field of the
newly constructed message.
On receiving a Proxy Routing Rules Update Request a Mobile Access
Gateway MUST process the message as specified below.
o The Mobile Access Gateway MUST construct a ICMP Routing Rules
Update message. It MUST set the Primary Prefix and sequence
number fields of this message to the values of the corresponding
fields in the received ICMP Primary Prefix Request. It MUST also
copy the Routing Rules payload of the received message to the
Routing Rules payload field of the newly constructed message.
o The Mobile Access Gateway MUST send the message constructed to the
link local address of the mobile node that is contained in the BUL
entry associated with this mobile node.
On receiving a ICMP Routing Rules Acknowledgment a Mobile Access
Gateway MUST process the message as specified below.
o The Mobile Access Gateway MUST send a Proxy Routing Rules Update
Acknowledgement message to the IPv6 address of the Local Mobility
Anchor. This message MUST have the sequence number and the status
field set to the values received in the Proxy Routing Rules Update
Acknowledgment. It MUST also MN-ID field set to the value of MN-
Identifier field from the corresponding BUL entry.
Larsson, et al. Expires September 5, 2009 [Page 21]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
5.6. Mobile Node De-registration
When a Mobile Node moves away from a domain handled by a specific MAG
and moves to another MAG this will trigger the MAG to de-register the
Mobile Node from the LMA. When this is done, the MAG will remove its
BUL entry for the Mobile Node. This MUST trigger the following
procedure in the MAG.
o For every Primary Prefix in the Primary Prefix list the MAG MUST
remove any ingress filtering exceptions and tunnel state set up
for this address.
Larsson, et al. Expires September 5, 2009 [Page 22]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
6. Local Mobility Agent Operation
This section defines the local mobility anchor operation.
6.1. Extensions to BC Entry Data Structure
In addition to binding cache entries specified in [RFC5213] LMA,
supporting simultaneous multi-access operation, must create a binding
cache entry for the primary prefix allocated for the MN. This entry
must contain at least one BID mapped to the MN's care-of-address.
The actual binding contains in the Proxy Primary Prefix Request: BID
assigned to the care-of-address, which will be received by LMA in
Primary Prefix Allocation Request message. Once BC entry for Primary
Prefix allocated, LMA MUST insert references into this BC entry when
new Proxy Primary Prefix BU messages will arrive. The life time of
the Primary Prefix BC entry is determined by existence of references
to HNP BC entries in the Primary Prefix BC entry. Once the last
reference will disappear, LMA SHOULD start a timer for the Primary
Prefix BC timeout. After the timer expiration the Primary Prefix BC
entry MUST be deleted from LMA's binding cache.
6.2. Recieving Proxy Primary Prefix Request
Upon receiving Proxy Primary Request Message LMA MUST allocate
Primary prefix, which theoretically may be in the range 1 - 128 bits
and insert a new BC entry corresponding to the allocated Primary
prefix (see Section XXX). This entry MUST have a reference to the BC
entry created earlier for the HNP contained in the Proxy Primary
Prefix Request message. As a result of this operation LMA sends
Proxy Primary Acknowledgement message with the result status code
field set. This document defines two values of the status code: 0 -
success, and 1 - failure. Later, the failure codes may be extended
with additional values describing more precisely details of failure.
6.3. Prefix and BID Binding Registration
Allocation of HNP prefixes to MN by LMA is performed according to the
procedure described in [RFC5213]. The MN, which already received
primary prefix may send BID registration at any time for some
particular interface. For the purpose of backwards compatibility
with [RFC5213], it is not mandatory for the SMA enabled MN to send
BID registration for multiple interfaces configured in the MN. The
only BID registration, which will be performed, is with regard to
sending Primary Prefix Request message as described in Section XXX.
By sending Primary Prefix message, mobile node indicates the fact
that it wishes to start operation in simultaneous multi-access mode
and creates at least one binding for a chosen interface. Upon
receiving Proxy Primary Prefix BU message, LMA MUST create a
Larsson, et al. Expires September 5, 2009 [Page 23]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
reference in the binding cache entry corresponding to the primary
prefix and HNP sent in the Proxy Primary Prefix BU message. As the
result of this operation, LMA MUST reply with the Proxy Primary
Prefix BA message containing resulting status code in the Status
field of the message. Status code values defined by this document
described in Section XXX.
6.4. Sending Proxy Primary Prefix Update
If LMA receives Proxy BU message, as specified in [RFC5213],
indicating the fact that a mobile node moved to a different MAG, LMA
MUST perform additional operations in the case the mobile node is SMA
enabled and has previously configured Primary Prefix.
o LMA MUST check in its BC if there is a Primary Prefix BC entry for
the mobile node on behalf of which new MAG sent Proxy BU message.
If yes, then
o LMA MUST check if there is a reference to the HNP BC entry of the
HNP, which is moved to the new MAG. If yes, then
o LMA MUST send Proxy Primary Prefix Update message to the new MAG
6.5. Registration of Routing Rules
Initial setup and consequent update of Routing Rules in LMA and MN is
performed by Proxy Routing Rules Update message received by LMA if
mobile node initiates operation, or sent by LMA if network initiates
change of Routing rules. In both cases, the format of the Proxy
Routing Rules Update message is identical. If LMA receives the Proxy
Routing Rules Update it has to act in accordance with
[I-D.eriksson-mext-mipv6-routing-rules] and associate new Routing
Rules set with the Primary Prefix BC entry in LMA. All inbound
traffic directed to Primary Prefix MUST be handled in accordance with
the Routing Rules associated with the Primary Prefix BC entry in LMA.
Larsson, et al. Expires September 5, 2009 [Page 24]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
7. New ICMP and Mobility Header messages
A set of new ICMP messages are required for the communication between
the mobile node and the MAG. Additionally, new Mobility Header
messages are required as well as modifications to existing Mobility
Header messages.
7.1. New ICMP Messages
7.1.1. ICMP Primary Prefix Request
The ICMP Primary Prefix Request message is used by a mobile node to
initiate allocation of a primary prefix. The mobile node sends the
ICMP Primary Prefix Request message to the MAG. The source address
of the packet is xxx and the destination address of the packet is the
yyy address.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved | HNP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure nn: ICMP Primary Prefix Request Message
Type
TBD by IANA
Code
0
Checksum
The ICMP checksum [RFC4443].
Sequence #
A 16-bit unsigned integer used by the receiving node to sequence
ICMP Primary Prefix Request messages and by the sending node to
match a returned ICMP Primary Prefix Acknowledgement with this
Larsson, et al. Expires September 5, 2009 [Page 25]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
ICMP Primary Prefix Request.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
HNP Length
8-bit unsigned integer indicating the length of the IPv6 Home
Network Prefix.
Home Network Prefix
The home network prefix that will be bound to the new Primary
Prefix allocated by the LMA.
7.1.2. ICMP Primary Prefix Acknowledgement
The ICMP Primary Prefix Acknowledgement message is sent by the MAG to
the mobile node to confirm the result of the allocation request. If
the allocation was successful the status value is set to 0, otherwise
an appropriate error code is set.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved | PP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Primary Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure nn: ICMP Primary Prefix Acknowledgement
Type
TBD by IANA
Code
TBD
Larsson, et al. Expires September 5, 2009 [Page 26]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
Checksum
The ICMP checksum [RFC4443].
Sequence #
The Sequence Number in the ICMP Primary Prefix Acknowledgement
is copied from the Sequence Number field in the ICMP Primary
Prefix Request. It is used by the mobile node in matching this
ICMP Primary Prefix Acknowledgement with an outstanding ICMP
Primary Prefix Request.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
PP Length
8-bit unsigned integer indicating the length of the IPv6 Primary
Prefix.
Primary Prefix
The primary prefix that was allocated by the LMA to the mobile
node.
7.1.3. ICMP Primary Prefix Binding Update
The ICMP Primary Prefix Binding Update message is sent by the mobile
node to the MAG to bind a home network prefix to a Binding Identifier
(BID).
Larsson, et al. Expires September 5, 2009 [Page 27]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Length | Sequence # | HNP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Identifier (BID) | Reserved | PP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Primary Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure nn: ICMP Primary Prefix Binding Update
Type
TBD by IANA
Code
0
Checksum
The ICMP checksum [RFC4443].
Total Length
The total length of the message in units of octets starting from
and including the Type field.
Sequence #
A 16-bit unsigned integer used by the receiving node to sequence
ICMP Primary Prefix Binding Update messages and by the sending
node to match a returned ICMP Primary Prefix Binding
Acknowledgement with this ICMP Primary Prefix Binding Update.
Larsson, et al. Expires September 5, 2009 [Page 28]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
HNP Length
8-bit unsigned integer indicating the length of the IPv6 Home
Network Prefix.
Home Network Prefix
The home network prefix that will be associated with the Binding
Identifier listed in this message.
Binding Identifier (BID)
The Binding Identifier associated with the Home Network Prefix.
This document preserves the established relation between a BID
and CoA, as defined in [I-D.ietf-monami6-multiplecoa], but
instead of using the CoA the Home Network Prefix is used.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
PP Length
8-bit unsigned integer indicating the length of the IPv6 Primary
Prefix.
Primary Prefix
The primary prefix for which the BID - Home Network Prefix
binding is valid.
7.1.4. ICMP Primary Prefix Binding Acknowledgement
The ICMP Primary Prefix Binding Acknowledgement message is sent by
the MAG to the mobile node to confirm the binding between the BID and
the Home Network Prefix.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure nn: ICMP Primary Prefix Binding Acknowledgement
Type
TBD by IANA
Larsson, et al. Expires September 5, 2009 [Page 29]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
Code
TBD
Checksum
The ICMP checksum [RFC4443].
Sequence #
The Sequence Number in the ICMP Primary Prefix Binding
Acknowledgement is copied from the Sequence Number field in the
ICMP Primary Prefix Binding Update. It is used by the mobile
node in matching this ICMP Primary Prefix Binding
Acknowledgement with an outstanding ICMP Primary Prefix Binding
Update.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
7.1.5. ICMP Routing Rules Update
This message is sent either by the mobile node or by the MAG to
update the routing rules. The direction depends on whether the
mobile node or the network is responsible for updating of the routing
rules.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved | PP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Primary Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Rules ...
+-+-+-+-+-+-+-+-+-+-+-+-+
Figure nn: ICMP Routing Rules Update
Larsson, et al. Expires September 5, 2009 [Page 30]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
Type
TBD by IANA
Code
TBD
Checksum
The ICMP checksum [RFC4443].
Sequence #
The Sequence Number is either generated by the mobile node when
the ICMP Routing Rule Update message is originated from the
mobile node or copied from the Sequence Number field in the ICMP
Routing Rules Update message to the ICMP Routing Rules
Acknowledgement when received from the MAG.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
PP Length
8-bit unsigned integer indicating the length of the IPv6 Primary
Prefix.
Primary Prefix
The primary prefix that was allocated by the LMA to the mobile
node.
Routing Rules
A set of Routing Rules in ASCII text format according to
[I-D.larsson-mext-flow-distribution-rules]. The set of routing
rules is associated with the primary prefix.
7.1.6. ICMP Routing Rules Acknowledgement
This message is sent either by the MAG or the mobile node to confirm
the result of a previously sent ICMP Routing Rules Update. The
direction depends on whether the mobile node or the network is
responsible for updating of the routing rules. The result of the
operation is indicated in the Code field.
Larsson, et al. Expires September 5, 2009 [Page 31]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure nn: ICMP Routing Rules Acknowledgement
Type
TBD by IANA
Code
TBD
Checksum
The ICMP checksum [RFC4443].
Sequence #
If the ICMP Routing Rules Acknowledgement message is received
from the MAG then the Sequence Number is used by the mobile node
in matching this ICMP Routing Rules Acknowledgement with an
outstanding ICMP Routing Rules Update. If the ICMP Routing
Rules Acknowledgement message is sent from the mobile node then
the Sequence Number in the ICMP Routing Rules Acknowledgement is
copied from the Sequence Number field in the ICMP Routing Rules
Update message. It is used by the receiving node in matching
this ICMP Routing Rules Acknowledgement with an outstanding ICMP
Routing Rules Update.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
7.2. New Mobility Header Messages
A set of new Mobility Header messages are needed to map incoming ICMP
messages to messages that can be transferred between the MAG and the
LMA. The Mobility Header messages uses the format defined in
[RFC3775].
7.2.1. Proxy Primary Prefix Request Message
If a mobile node decides to allocate a Primary Prefix (by sending an
ICMP Primary Prefix Request), then the Proxy Primary Prefix Request
message is sent by the MAG to the LMA requesting it to allocate a
Primary Prefix for the mobile node. In doing so it forwards the
Larsson, et al. Expires September 5, 2009 [Page 32]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
parameters in the received ICMP message and additionally adds the
Mobile Node Identifier (MN-ID).
The Proxy Primary Prefix Request message uses the MH Type value TBD.
When this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Binding Identifier (BID) | HNP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MN-ID Length | Subtype | MN-ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure nn: Proxy Primary Prefix Request
Sequence #
A 16-bit value specifying the sequence number of the message.
The sequence number is a continuous number generated by the
mobile node. It is copied from the Sequence Number field in the
received ICMP Primary Prefix Request.
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Binding Identifier (BID)
Binding Identifier as specified in
[I-D.ietf-monami6-multiplecoa].
HNP Length
This field specifies the Home Network Prefix length. The value
can be in the range of 1-128 according to [RFC5213].
Larsson, et al. Expires September 5, 2009 [Page 33]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
Home Network Prefix
The home network prefix that will be associated with the Binding
Identifier parameter in this message.
MN-ID Length
A 8-bit value specifying the length of the MN-ID.
Subtype
A 8-bit value specifying type of MN-ID followed this field. The
type of MN-ID is defined in [RFC4283].
MN-ID
Variable length filed containing data according to the Subtype
field in the message.
7.2.2. Proxy Primary Prefix Acknowledgement Message
The Proxy Primary Prefix Acknowledgement is used to acknowledge
receipt of a Proxy Primary Prefix Request. This message indicates
success or failure of the operation in LMA and contains the Primary
Prefix for the mobile node in case of success.
The Proxy Primary Prefix Acknowledgement has the MH Type value TBD.
When this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | MN-ID Length | Subtype | PP Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. MN-ID .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. Primary Prefix .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure nn: Proxy Primary Prefix Acknowledgement
Larsson, et al. Expires September 5, 2009 [Page 34]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
Sequence #
A 16-bit value specifying Sequence Number of the message. The
Sequence Number is is copied from the Sequence Number field in
the Proxy Primary Prefix Request. It is used by the MAG in
matching this Proxy Primary Prefix Acknowledgement with an
outstanding Proxy Primary Prefix Request.
Status
A 16-bit value specifying the result of the Primary Prefix
allocation in LMA. This document defines two values:
0 - Success
1 - Failure.
MN-ID Length
A 8-bit value specifying length of MN-ID.
Subtype
A 8-bit value specifying type of MN-ID followed this field. The
type of MN-ID is defined in [RFC4283].
PP Length
This field specifies the Home Network Prefix length. The value
can be in the range of 1-128 according to [RFC5213].
MN-ID
Variable length filed containing data according to the Subtype
field in the message.
Primary Prefix
If the allocation was successful this field includes the Primary
Prefix allocated by LMA for the mobile node. In case of an
allocation failure this field is omitted.
7.2.3. Proxy Primary Prefix BU Message
The Proxy Primary Prefix Binding Update requests a new binding
between a BID and a Home Network Prefix in the mobile node. This
message is sent from the MAG to the LMA when the MAG receives an ICMP
Primary Prefix Binding Update from the mobile node. In doing so it
forwards the parameters in the received ICMP message and additionally
adds the Mobile Node Identifier (MN-ID).
The Proxy Primary Prefix Binding Update message uses the MH Type
value TBD. When this value is indicated in the MH Type field, the
format of the Message Data field in the Mobility Header is as
follows:
Larsson, et al. Expires September 5, 2009 [Page 35]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Binding Identifier (BID) | MN-ID Length | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HNP Length | PP Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Primary Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. MN-ID .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure nn: Proxy Primary Prefix Binding Update
Sequence #
A 16-bit value specifying the sequence number of the message.
The sequence number is a continuous number generated by the
mobile node. It is copied from the Sequence Number field in the
received ICMP Primary Prefix Binding Update.
Binding Identifier (BID)
Binding Identifier as specified in
[I-D.ietf-monami6-multiplecoa].
MN-ID Length
A 8-bit value specifying the length of the MN-ID.
Larsson, et al. Expires September 5, 2009 [Page 36]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
Subtype
A 8-bit value specifying type of MN-ID followed this field. The
type of MN-ID is defined in [RFC4283].
HNP Length
This field specifies the Home Network Prefix length. The value
can be in the range of 1-128 according to [RFC5213].
PP Length
This field specifies the Primary Prefix length. The value can
be in the range of 1-128 according to [RFC5213]..
Reserved
This field is unused. It MUST be initialized to zero by the
sender and MUST be ignored by the receiver.
Home Network Prefix
The Home Network Prefix associated with the Binding Identifier
parameter in this message.
Primary Prefix
The Primary Prefix for which the binding between the BID and the
Home Network Prefix is valid for.
MN-ID
Variable length filed containing data according to the Subtype
field in the message.
7.2.4. Proxy Primary Prefix BA Message
The Proxy Primary Prefix Binding Acknowledgement is used to
acknowledge receipt of a Proxy Primary Prefix Binding Update. This
message indicates whether the binding was successful or not.
The Proxy Primary Prefix Binding Acknowledgement has the MH Type
value TBD. When this value is indicated in the MH Type field, the
format of the Message Data field in the Mobility Header is as
follows:
Larsson, et al. Expires September 5, 2009 [Page 37]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved | MN-ID Length | SubType |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. MN-ID .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure nn: Proxy Primary Prefix Binding Acknowledgement
Sequence #
A 16-bit value specifying the Sequence Number of the message.
The Sequence Number is is copied from the Sequence Number field
in the Proxy Primary Prefix Binding Update. It is used by the
MAG in matching this Proxy Primary Prefix Binding
Acknowledgement with an outstanding Proxy Primary Prefix Binding
Update.
Status
A 16-bit value specifying the result of the binding request.
This document defines two values:
0 - Success
1 - Failure.
MN-ID Length
A 8-bit value specifying length of MN-ID.
Subtype
A 8-bit value specifying type of MN-ID followed this field. The
type of MN-ID is defined in [RFC4283].
MN-ID
Variable length filed containing data according to the Subtype
field in the message.
7.2.5. Proxy Primary Prefix Update Message
Proxy Primary Prefix Update message is sent by LMA in the case when
an attached interface in mobile node changes to a different MAG. The
message is sent after new MAG and LMA accomplish Proxy Binding Update
procedure according to [RFC5213]. The Proxy Primary Prefix Request
message will trigger the new MAG to update its BUL accordingly.
Larsson, et al. Expires September 5, 2009 [Page 38]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
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 Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PP Length | MN ID Length | Subtype | MN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Primary Prefix .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number
This is 16 bit value specifying sequence number of the message.
The sequence number is the number generated by LMA.
Primary Prefix Length
This field specifies Primary Prefix length. The value can be in
the range 1 -128.
MN ID Length
This is 8 bit value specifying length of MN's ID defined in
[42...].
Subtype
8-bit integer specifying type of MN ID followed this field. The
type of MN ID is defined in [RFC4283].
MN ID
Variable length filed containing data according to the Subtype
field in the message.
Primary Prefix
128 bits filed containing Primary Prefix allocated previously by
LMA to the MN.
7.2.6. Proxy Primary Prefix Update Ack Message
Proxy Proxy Primary Prefix Update Ack Message is sent to LMA by MAG
receiving Proxy Primary Prefix Update Message. The message is sent
after MAG has accomplished all necessary updates of its BUL.
Larsson, et al. Expires September 5, 2009 [Page 39]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
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 Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | MN ID Length | Subtype | MN ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number
This is 16 bit value specifying sequence number of the message.
The sequence number is copied from the correspondent Proxy
Primary Prefix Update message.
Status
This is 8 bit value specifying result of the Primary Prefix
Update operation in MAG. This document defines two values: 0 -
success, and 1 - failure. Other codes giving more detailed
information about failure type can be added in the future.
MN ID Length
This is 8 bit value specifying length of MN's ID defined in
[42...].
Subtype
8-bit integer specifying type of MN ID followed this field. The
type of MN ID is defined in [RFC4283].
MN ID
Variable length filed containing data according to the Subtype
field in the message.
7.2.7. Proxy Routing Rules Update Message
The Proxy Routing Rules Update Message is sent either by the LMA or
by the MAG, as a result of a received ICMP Routing Rules Update
message. This message is bidirectional depending on whether the
mobile node or the network is responsible for updating the routing
rules..
The Proxy Routing Rules Update message uses the MH Type value TBD.
When this value is indicated in the MH Type field, the format of the
Message Data field in the Mobility Header is as follows:
Larsson, et al. Expires September 5, 2009 [Page 40]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Routing Rules Length | MN-ID Length | Subtype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PP Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. MN-ID .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Primary Prefix .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Routing Rules .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure nn: Proxy Routing Rules Update
Sequence #
This is 16 bit value specifying sequence number of the message.
The sequence number is the number copied from the correspondent
Proxy Primary Prefix BU message.
Routing Rules Length
This field specifies Routing Rules
[I-D.larsson-mext-flow-distribution-rules,
I-D.eriksson-mext-mipv6-routing-rules] length.
MN ID Length
This is 8 bit value specifying length of MN's ID defined in
[42...].
Subtype
8-bit integer specifying type of MN ID followed this field. The
type of MN ID is defined in [42...].
MN ID
Variable length filed containing data according to the Type
field in the message.
Larsson, et al. Expires September 5, 2009 [Page 41]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
Primary Prefix Length
This field specifies Primary Prefix [RFC5213] length and is
similar to HNP Length.
Primary Prefix
128 bits filed containing Primary Prefix allocated previously by
LMA and delivered in the Proxy Primary Prefix Acknowledgement
message.
Roting Rules
Routing Rules are transferred in the format specified in
[I-D.larsson-mext-flow-distribution-rules,
I-D.eriksson-mext-mipv6-routing-rules].
7.2.8. Proxy Routing Rules Ack Message
Proxy Routing Rules Ack Message is sent by LMA to inform involved
nodes - MAG and MN about the result of operation of Routing Rules
Update.
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 Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | MN ID Length | Subtype | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. MN ID .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Sequence Number
This is 16 bit value specifying sequence number of the message.
The sequence number is the number copied from the correspondent
Proxy Primary Prefix BU message.
Status
This is 16 bit value specifying result of the Primary Prefix BU
operation in LMA. This document defines two values: 0 -
success, and 1 - failure. Other codes giving more detailed
information about failure type can be added in the future.
MN ID Length
This is 8 bit value specifying length of MN's ID defined in
[42...].
Larsson, et al. Expires September 5, 2009 [Page 42]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
Subtype
8-bit integer specifying type of MN ID followed this field. The
type of MN ID is defined in [42...].
MN ID
Variable length filed containing data according to the Type
field in the message.
Larsson, et al. Expires September 5, 2009 [Page 43]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
8. Security Considerations
TBD.
Larsson, et al. Expires September 5, 2009 [Page 44]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
9. IANA Considerations
This memo includes the following request to IANA.
Larsson, et al. Expires September 5, 2009 [Page 45]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
10. Acknowledgements
The authors would like to thank Yuri Ismailov for his contributions
to this draft.
Larsson, et al. Expires September 5, 2009 [Page 46]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K.
Chowdhury, "Mobile Node Identifier Option for Mobile IPv6
(MIPv6)", RFC 4283, November 2005.
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control
Message Protocol (ICMPv6) for the Internet Protocol
Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
11.2. Informative References
[I-D.eriksson-mext-mipv6-routing-rules]
Eriksson, M., Larsson, C., and R. Kuntz, "Mobile IPv6 Flow
Routing over Multiple Care-of Addresses",
draft-eriksson-mext-mipv6-routing-rules-00 (work in
progress), June 2008.
[I-D.ietf-monami6-multiplecoa]
Wakikawa, R., Devarapalli, V., Ernst, T., and K. Nagami,
"Multiple Care-of Addresses Registration",
draft-ietf-monami6-multiplecoa-11 (work in progress),
January 2009.
[I-D.larsson-mext-flow-distribution-rules]
Larsson, C., Eriksson, M., Mitsuya, K., Tasaka, K., and R.
Kuntz, "Flow Distribution Rule Language for Multi-Access
Nodes", draft-larsson-mext-flow-distribution-rules-02
(work in progress), February 2009.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Larsson, et al. Expires September 5, 2009 [Page 47]
Internet-Draft SMA & Flow Mobility Support for PMIPv6 March 2009
Authors' Addresses
Conny Larsson
Ericsson Research
Isafjordsgatan 14E
Stockholm SE-164 80
Sweden
Phone: +46 10 714 8458
Email: conny.larsson@ericsson.com
Michael Eriksson
Ericsson Research
Isafjordsgatan 14E
Stockholm SE-164 80
Sweden
Phone: +46 10 717 5888
Email: michael.eriksson@ericsson.com
Petter Arvidsson
Ericsson Research
Isafjordsgatan 14E
Stockholm SE-164 80
Sweden
Phone: +46 10 717 1803
Email: petter.p.arvidsson@ericsson.com
Larsson, et al. Expires September 5, 2009 [Page 48]
| PAFTECH AB 2003-2026 | 2026-04-24 01:24:53 |