NetExt Working Group P. Loureiro
Internet-Draft M. Liebsch
Intended status: Standards Track NEC
Expires: September 9, 2010 March 8, 2010
Proxy Mobile IPv6 Localized Routing
draft-loureiro-netext-pmipv6-ro-02.txt
Abstract
The IETF specified Proxy Mobile IPv6 as protocol for network-based
mobility management. In Proxy Mobile IPv6, mobile nodes are attached
to the network through Mobility Access Gateways and registered with a
Local Mobility Anchor. Traffic from and to the mobile node traverses
the mobile node's Local Mobility Anchor, irrespective of the location
of the mobile node's corresponding communication endpoint. This
document specifies a protocol extension to Proxy Mobile IPv6 which
allows the set up and maintenance of a localized routing path between
two communicating mobile nodes' Mobility Access Gateways without
traversing the mobile nodes' Local Mobility Anchor(s). The protocol
component of a rendezvous control point ensures stable maintenance of
routing states during handover in scenarios with multiple mobility
anchors, where states for the two communication endpoints are
distributed between these anchors.
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 9, 2010.
Loureiro & Liebsch Expires September 9, 2010 [Page 1]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. General Procedure . . . . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7
4.1. Setup of Localized Routing - Single LMA . . . . . . . . . 7
4.2. Setup of Localized Routing - Multiple LMAs . . . . . . . . 8
4.3. Maintenance during Handover - Single LMA . . . . . . . . . 9
4.4. Maintenance during Handover - Multiple LMAs . . . . . . . 10
4.5. Extension of the Localized Routing Lifetime . . . . . . . 11
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 13
5.1. Protocol Messages . . . . . . . . . . . . . . . . . . . . 13
5.2. Message Options . . . . . . . . . . . . . . . . . . . . . 14
6. IPv4 Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. Localized routing for IPv4 Home Addresses . . . . . . . . 16
6.2. IPv4 transport network . . . . . . . . . . . . . . . . . . 16
7. Extension for MAG requested Localized Routing . . . . . . . . 17
8. Summary of achievements to meet LR Requirements . . . . . . . 18
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
10. Security Considerations . . . . . . . . . . . . . . . . . . . 20
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
12.1. Normative References . . . . . . . . . . . . . . . . . . . 22
12.2. Informative References . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
Loureiro & Liebsch Expires September 9, 2010 [Page 2]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
1. Introduction
The IETF specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as solution
for network-based mobility management. In PMIPv6, Mobile Nodes (MNs)
are registered with a Local Mobility Anchor (LMA) maintaining a
binding between the MN's Home Network Prefix (HNP) and its locator,
which is represented by the currently used Mobility Access Gateway
(MAG). The MAG's IP address serves as Proxy Care-of Address (Proxy
CoA) and is bound to the MN's HNP. Downlink packets, which address
the MN's HNP, are forwarded by the MN's LMA by means of an IP tunnel
to the MN's current MAG, which terminates the tunnel and delivers the
packet to the MN by means of link-layer or point-to-point mechanisms.
Uplink packets are tunneled by the MN's MAG to the LMA and then
forwarded to the Internet.
The PMIPv6 architecture implies that all packets being sent or
received by a MN traverse the associated LMA, irrespective of where
an MN's correspondent communication endpoint is connected. In case
two MNs attach to the same PMIPv6 domain, the routing path for the
local communication between these nodes may be sub-optimal, as
packets traverse the MNs' LMA(s) [I-D.ietf-netext-pmip6-lr-ps]. This
document specifies an extension to PMIPv6 as per [RFC5213] to set up
a localized path and associated routing states for local
communication between the two MNs' MAGs within a PMIPv6 domain and to
maintain these routing states during the MNs' handover.
The specified protocol for localized routing follows the network-
based mobility management paradigm [RFC4831] and does not require any
signaling from the MNs to establish a localized routing path between
the two MNs' MAGs. The present protocol is based on
[I-D.abeille-netlmm-proxymip6ro] and supports reliable set up and
maintenance of localized routes independent of whether both MNs
attach to the same or different LMA and MAG. The protocol relies on
a route optimization controller (ROC) function, which is associated
with each LMA. In case both MNs are registered with different LMAs,
only one selected LMA takes over the control to maintain states on
PMIPv6 components during an MN's handover. Hence, the LMA which
controls the set up and update of localized routing states represents
the rendezvous control point for the route update procedure.
Coordination of the route update procedure from a rendezvous point
ensures stable maintenance of localized routing during one or both
MNs' handover without running into a race condition situation.
Loureiro & Liebsch Expires September 9, 2010 [Page 3]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
2. Conventions and 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 RFC 2119 [RFC2119].
This document uses the terminology of RFC 5213 [RFC5213]. The
following terms are used in the context of this draft:
o Mobile Node (MN): Mobile Node without IP mobility support, which
is attached to a Mobility Access Gateway (MAG) and registered with
a Local Mobility Anchor (LMA) according to the PMIPv6
specification RFC 5213 [RFC5213]
o Correspondent Node (CN) - Correspondent Node with or without IP
mobility support. The CN represents the communication peer of an
MN, which is attached to a MAG and registered with an LMA
according to the PMIPv6 specification.
o Source MN - Mobile Node associated with the LMA/MAG that triggers
the localized routing procedure.
o Destination MN - Mobile Node associated with the LMA/MAG that did
not initiate the localized routing procedure.
o Localized Routing - Result of signaling to set up routing states
on relevant network entities to allow forwarding of data packets
between an MN and a CN within a single PMIPv6 domain without
traversing the MN's LMA and without traversing the CN's mobility
anchor.
o Localized Routing States - Information for localized routing on
relevant forwarding entities on the optimized data path between an
MN and a CN. Such information includes route entries and may
include further information about the MN and the CN, such as IDs.
o RO Trigger - This function is assigned to a network entity, which
first detects that localized routing can be established between
the MAGs of two MNs.
o RO Control - This function is an integral part of an LMA which
supports the set up and maintenance of localized routing. In case
localized routing needs to be set up between two nodes, which are
registered with different LMAs, only one LMA takes over the
control to set up and maintain localized routing. The controlling
LMA is selected during the initial establishment of a localized
routing path and is responsible for coordinating subsequent
updates of localized routing states due to movements of the MNs.
Loureiro & Liebsch Expires September 9, 2010 [Page 4]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
3. General Procedure
According to the PMIPv6 protocol [RFC5213], all traffic generated by
an MN attached to a MAG is routed through this MAG to the respective
LMA. In the case of Figure 1 all traffic from MN to CN is routed
through MAG1 to LMA1 and then through LMA2 and MAG3 towards CN. The
detection of the possibility to establish a localized path can then
be assigned to the LMA of MN (LMA1) and it may be determined by
analyzing the source/destination addresses of MN and CN, for example.
Referring to the reference architecture illustrated in Figure 1, LMA1
will detect the possibility to establish a localized forwarding path
between the two MNs and functions as RO Trigger, whereas the role of
the RO Controller is assigned to the peer LMA (LMA2). In the case of
both MNs being associated to the same LMA and different MAGs, the
role of RO Controller and RO Trigger is assigned to the same LMA.
The RO Controller coordinates the setup of the localized path at the
involved MAGs and is also responsible for updating the localized
routing states in case of handover of one of the MNs.
The specific case of setting up localized routing in the scenario of
multiple LMAs possibly requires the resolution of a destination MN's
IP address into the routable IP address of the destination MN's LMA.
This is due to the fact that, upon traffic inspection and detection
of the possibility of route localization, the LMA can only acquire
the IP address of both MNs from the data packet but not the IP
address of the peer LMA. An approach to solve this issue is out of
scope of this document but discussed in
[I-D.liebsch-dime-pmip6-lmaresolve].
After states for localized routing have been established, these
states are assigned a Lifetime, which can be extended. Upon
expiration of the Lifetime, MAGs and LMAs delete the associated
localized routing states.
Lifetime refreshing for localized routing states is done
independently by each MAG at the respective LMA. A detailed policy
when to update localized routing states is out of scope of this
specification, but can be based on the result of probes for ongoing
traffic. To avoid expiration of localized routing states, MAGs can
refresh the associated lifetime and inform the respective LMA about
the lifetime extension by means of a Refresh message.
Loureiro & Liebsch Expires September 9, 2010 [Page 5]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
Internet Backbone
........................
: :
| |
+----+ +----+
|LMA1|-----------------|LMA2|
+----+ +----+
| |
| |
+-----+------+ +----+
| | |
+----+ +----+ +----+
|MAG1| |MAG2| |MAG3|
+----+ +----+ +----+
: :
+---+ +---+
|MN | |CN |
+---+ +---+
Figure 1: Reference Architecture
Two different modes of operation can be supported for the currently
specified protocol. The proxy mode, in which messages between MAGs
are relayed through the LMAs, and the direct mode, in which the MAGs
are allowed to exchange signaling messages directly at the cost of
having to setup security associations between them but requiring a
smaller number of message exchanging to setup the localized paths.
The present draft focuses on the direct mode, although future
versions of the document might consider the specification of the
proxy mode. Considerations on the proxy mode can be checked in
[I-D.abeille-netlmm-proxymip6ro].
Loureiro & Liebsch Expires September 9, 2010 [Page 6]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
4. Protocol Overview
In order to support the set up and maintenance of the localized
routing procedure, this document introduces the following new
signaling messages:
o RO Trigger - This message is sent from an LMA to inform another
LMA that it must initiate a localized routing procedure towards a
MAG associated to it. It's only used on scenarios with more than
one LMA.
o RO Trigger Ack - This message is sent from an LMA to inform
another LMA about the success of the localized routing path
establishment. It's only used on scenarios with more than one
LMA.
o RO Init - This message is sent from an LMA to a MAG in order to
inform it that it should setup RO according to the received
information. It triggers the MAG to contact the peer MAG in order
to setup the localized reverse path.
o RO Init Ack - This message is sent from MAG to LMA in order to
inform the status of the localized routing initiation setup.
o RO Setup - This message is sent from MAG to MAG and informs the
receiving MAG that it should setup a localized routing path
according to the received information.
o RO Setup Ack - This message is sent from MAG to MAG in order to
inform the status of the RO setup.
o RO Refresh - This message is sent from MAG to LMA in order to
refresh the lifetime of an existing localized routing state.
o RO Refresh Ack - This message is sent from LMA to MAG in order to
inform the status of the lifetime refresh request.
All the scenarios considered in the following chapters assume that
traffic is initiated from MN towards CN.
4.1. Setup of Localized Routing - Single LMA
For the scenario of Figure 2, two mobile nodes are assumed to be
registered with the same LMA and associated with different MAGs (MAG1
and MAG2). When traffic starts from the mobile node attached to MAG1
towards the mobile node attached to MAG2, it is detected by LMA1 and
it triggers route localization. LMA1 sends a RO Init (1.) message
immediately to MAG2 because it recognizes that the target mobile node
Loureiro & Liebsch Expires September 9, 2010 [Page 7]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
is registered to itself so it knows the destination MAG (MAG2). At
this point MAG2 starts activating the localized routing states for
the traffic towards MAG1 and instructs MAG1 to do the same on the
inverse path by sending RO Setup (2.). If everything succeeds on the
side of MAG1 it sends back RO Setup Ack (3.) to MAG2 with a
successful code and MAG2 finally notifies LMA1 of the completion of
the procedure by sending RO Init Ack (4.) back to LMA1. In case of
failure to setup the forwarding state at MAG2 it should send
immediately RO Init Ack with a failure code back to LMA1 instead of
sending RO Setup to MAG1.
+----+ +----+ +----+
|MAG1| |LMA1| |MAG2|
+----+ +----+ +----+
| | |
| [Trigger] |
| | |
| [RO Control] |
| | |
| |------1.RO Init-------->|
| | |
|<-----------------2. RO Setup--------------------|
|------------------3. RO Setup Ack--------------->|
| |<----4. RO Init Ack-----|
| | |
| | |
Figure 2: Route Optimization Setup - Single LMA
Note: For the case of single LMA scenarios, the role of Trigger and
RO Control is always assigned to the same LMA.
4.2. Setup of Localized Routing - Multiple LMAs
In Figure 3, two mobile nodes are registered with different LMAs
(LMA1 and LMA2) and attached to two different MAGs (MAG1 and MAG2).
LMA1 detects the possibility of localizing the route and since there
are currently no associated states it triggers LMA2 by sending RO
Trigger (1.) and assigns the role of RO Control to LMA2. The
remaining of the signaling is similar to Figure 2 with the exception
that LMA2 must inform LMA1 of the final result of the procedure with
RO Trigger Ack (6.).
Loureiro & Liebsch Expires September 9, 2010 [Page 8]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
+----+ +----+ +----+ +----+
|MAG1| |LMA1| |LMA2| |MAG2|
+----+ +----+ +----+ +----+
| | | |
| [Trigger] | |
| | | |
| |---1.RO Trigger----->| |
| | | |
| | [RO Control] |
| | | |
| | |----2.RO Init------->|
|<---------------------3. RO Setup-----------------------------|
|----------------------4. RO Setup Ack------------------------>|
| | |<---5. RO Init Ack---|
| |<-6. RO Trigger Ack--| |
| | | |
| | | |
Figure 3: Route Optimization Setup - Multiple LMAs
4.3. Maintenance during Handover - Single LMA
In Figure 4, it is assumed that there is already a localized path
established between the mobile node attached to pMAG1 and the mobile
node attached to MAG2, it is also assumed that the MN performs an
handover to nMAG1. When LMA1 receives the PBU (1.) from nMAG1 it
recognizes that there are active route localized states for that
mobile node that need to be installed at nMAG1 and updated at MAG2,
so it proceeds to send RO Init (3.) to MAG2 following the same
procedure as in Figure 2. The localized routing states at pMAG1 can
be left to expire together with the BUL entry or can be explicitly
deleted if there is a mechanism that allows for MN detachment
detection.
Loureiro & Liebsch Expires September 9, 2010 [Page 9]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
+-----+ +-----+ +----+ +----+
|nMAG1| |pMAG1| |LMA1| |MAG2|
+-----+ +-----+ +----+ +----+
| | | |
| | [RO Control] |
| | | |
|--------------1.PBU------------------>| |
|<-------------2.PBA-------------------| |
| | | |
| | [Trigger] |
| | | |
| | |-----3.RO Init------>|
|<-------------------4. RO Setup-----------------------------|
|--------------------5. RO Setup Ack------------------------>|
| | |<--6.RO Init Ack-----|
| | | |
| | | |
Figure 4: Route Optimization Maintenance during Handover - Single LMA
4.4. Maintenance during Handover - Multiple LMAs
In Figure 5, it is assumed an already established localized path
between two MNs that are registered under different LMAs. Like in
Figure 4, the MN at pMAG1 will perform an handover to nMAG1. Upon
receiving the PBU (1.), LMA1 will recognize the existence of active
localized routing states and therefore informs LMA2 that it needs to
start updating the localized routing states by sending RO Trigger
(3.). The remaining of the signaling is similar to Figure 3 with the
exception that LMA2 must inform LMA1 of the final result of the
procedure with RO Trigger Ack (6.). Similarly to the previous case,
the localized routing states at pMAG1 can be left to expire or
deleted explicitly.
Loureiro & Liebsch Expires September 9, 2010 [Page 10]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
+-----+ +-----+ +----+ +----+ +----+
|nMAG1| |pMAG1| |LMA1| |LMA2| |MAG2|
+-----+ +-----+ +----+ +----+ +----+
| | | | |
| | | [RO Control] |
| | | | |
|-------1.PBU--------->| | |
|<------2.PBA----------| | |
| | | | |
| | [Trigger] | |
| | | | |
| | |---3.RO Trigger---->| |
| | | |----4.RO Init--->|
|<---------------------5.RO Setup-----------------------------|
|----------------------6.RO Setup Ack------------------------>|
| | | |<-7.RO Init Ack--|
| | |<--8.RO Trigger Ack-| |
| | | | |
| | | | |
Figure 5: Route Optimization Maintenance during Handover - Multiple
LMAs
Note: In the case that the MN being attached to MAG2 performs the
handover, there would be a direct RO Init message from LMA2 towards
the new MAG (no RO trigger message is sent) due to the fact that the
RO Control is assigned to LMA2.
4.5. Extension of the Localized Routing Lifetime
Upon an expiring lifetime of localized routing states, it can be
refreshed by any of the involved MAGs towards the respective LMA.
This is accomplished by sending a RO Refresh message (1.) to the LMA,
as depicted in Figure 6. The LMA replies with the status with a RO
Refresh Ack message (2.). Expired localized routing states, which
are not refreshed, are deleted and the traffic goes back to being
forwarded through the LMA.
In case of a multi-LMA scenario, MAGs can refresh the localized
routing state lifetime by sending a RO Refresh message towards the
respective LMA. The receiving LMA must reply back with the status in
a RO Refresh Ack message. As in the single-LMA scenario above,
expired localized routing states are deleted.
Loureiro & Liebsch Expires September 9, 2010 [Page 11]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
+----+ +----+ +----+
|MAG1| |LMA1| |MAG2|
+----+ +----+ +----+
| | |
| | [RO Timer]
| | |
| |<-----1.RO Refresh------|
| | |
| |----2.RO Refresh Ack--->|
| | |
| | |
Figure 6: Lifetime Extension of Localized Routing States
Loureiro & Liebsch Expires September 9, 2010 [Page 12]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
5. Message Format
5.1. Protocol Messages
This version of the protocol defines 4 new protocol commands plus
associated Acknowledgements. The protocol messages extend the set of
Mobility Header types, whereas some of these messages do not apply to
the protocol interface between a MAG and an LMA, but to the interface
between two MAGs or between two LMAs respectively.
A list of currently specified messages is given below for the
discussion of the protocol specification, whereas the detailed format
of the options will be added in an updated version of the document.
All formats of the new Mobility Header types carry a RO_Lifetime
field to signal the lifetime of a localized routing state.
All formats of the new Mobility Header types which represent an
Acknowledgement of a control message carry a Status code in the
header.
RO Trigger - Route Optimization Trigger. Including the format is
t.b.d. The following list are valid options, which must be
included with this message:
HNP Option - Home Network Prefix of Source MN.
HNP Option - Home Network Prefix of Destination MN.
MAG-ADDR Option - IPv6 address of the Source MN's MAG.
RO Trigger Ack - Route Optimization Trigger Acknowledgment.
Including the format is t.b.d. The following list are valid
options, which must be included with this message:
HNP Option - Home Network Prefix of Source MN.
HNP Option - Home Network Prefix of Destination MN.
RO Init - Route Optimization Initiation. Including the format is
t.b.d.
HNP Option - Home Network Prefix of Source MN.
HNP Option - Home Network Prefix of Destination MN.
Loureiro & Liebsch Expires September 9, 2010 [Page 13]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
MAG-ADDR Option - IPv6 address of the Source MN's MAG.
RO Init Ack - Route Optimization Initiation Acknowledgment.
Including the format is t.b.d.
HNP Option - Home Network Prefix of Source MN.
HNP Option - Home Network Prefix of Destination MN.
RO Setup - Route Optimization Setup. Including the format is t.b.d.
HNP Option - Home Network Prefix of Source MN.
HNP Option - Home Network Prefix of Destination MN.
MAG-ADDR Option - IPv6 address of the Destination MN's MAG.
RO Setup Ack - Route Optimization Setup Acknowledgment. Including
the format is t.b.d.
HNP Option - Home Network Prefix of Source MN.
HNP Option - Home Network Prefix of Destination MN.
RO Refresh - Route Optimization Refresh. Including the format is
t.b.d.
HNP Option - Home Network Prefix of Source MN.
HNP Option - Home Network Prefix of Destination MN.
RO Refresh Ack - Route Optimization Refresh Acknowledgment.
Including the format is t.b.d.
HNP Option - Home Network Prefix of Source MN.
HNP Option - Home Network Prefix of Destination MN.
5.2. Message Options
This version of the protocol defines 1 new Mobility Header option,
which is applied with the signaling messages specified in this
document. All options must meet the 32-bit boundary alignment. A
list of currently used options is given below for the discussion of
the protocol specification, whereas the detailed format of the
options will be added in an updated version of the document.
Loureiro & Liebsch Expires September 9, 2010 [Page 14]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
MAG-ADDR - IPv6 address of the source/destination MN's MAG.
Including the format is t.b.d.
To signal the IPv6 address/prefix of the source and destination MN as
communication endpoints, this specification uses the Home Network
Prefix option of [RFC5213].
To signal the IPv4 HoA of the source and destination MN as
communication endpoints, this specification uses the IPv4 Home
Address option of [RFC5555].
Loureiro & Liebsch Expires September 9, 2010 [Page 15]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
6. IPv4 Considerations
6.1. Localized routing for IPv4 Home Addresses
IPv4 or dual stack enabled hosts may be served by a PMIPv6 network
according to [I-D.ietf-netlmm-pmip6-ipv4-support]. To support the
set up and maintenance of localized routes for IPv4 Home Addresses in
PMIPv6, MAGs must add both MNs' IPv4 Home Addresses into their
conceptual data structures where they store information about the
MNs' routing states. Furthermore, MAGs must support encapsulation of
IPv4 packets and dynamically enter and update the associated
forwarding entry towards the correspondent MAG in their routing
table. For uplink traffic, MAGs must take routing decisions on the
IP address tuple represented by the source and the destination
address of the packet.
To signal the IPv4 Home Address of the two MNs, whose routing path
needs to be optimized, the localized routing protocol messages
include a IPv4 HoA option in their signaling messages. In case of
localized routing for IPv4 HoAs, the IPv4 HoA option of the source
and destination MN must be included in all signaling messages for the
setup and maintenance of the localized routing states to identify the
communication endpoints. According to the definition in this
document, the MN which originates the communication and whose IP
packet triggers the set up of a localized routing path, is considered
as the Source, whereas the recipient of this packet is considered as
the Destination.
6.2. IPv4 transport network
In case the transport network between PMIPv6 components supports IPv4
only, encapsulation of signaling messages for localized routing is
performed according to [I-D.ietf-netlmm-pmip6-ipv4-support]. The
same encapsulation modes apply to the protocol interface between
MAGs. In such case, a MAG must enable the same or a different IPv4
address as used for the signaling with the LMA for the signaling with
the correspondent MAG. The same applies to LMAs, which must enable
an IPv4 address for the signaling with a potentially correspondent
LMA. Selection of an appropriate encapsulation mode is out of scope
of this version of the specification. In case of an IPv4 transport
network which has a NAT between a MAG and an LMA or even between
MAGs, using IPv4-UDP encapsulation is recommended.
NATs between MAGs may be detected according to the NAT presence
detection scheme as described in
[I-D.ietf-netlmm-pmip6-ipv4-support], whereas instead of a PBU/PBA
handshake the RO Setup/RO Setup Ack signaling handshake is being used
to apply the detection mechanism.
Loureiro & Liebsch Expires September 9, 2010 [Page 16]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
7. Extension for MAG requested Localized Routing
Some operators may have different policies and enable detection of
the possibility to set up a localized routing path for an MN's
traffic at the MN's MAG. The protocol specified in this document
considers an LMA component to still enforce localized routing, as
required in [RFC5213], but the MN's MAG could request the setup of a
localized routing path at its LMA. In such case, the MAG can send a
request to set up a localized routing path to its LMA and indicates
the MN's and the CN's address. The RO Request command is
acknowledged by the LMA and indicates the LMA's intention to proceed
with the request (proceed, deny) with a RO Request Ack. The procedure
for MAG requested localized routing is depicted in Figure 7.
+----+ +----+ +----+
|MAG1| |LMA1| |MAG2|
+----+ +----+ +----+
| | |
[Trigger] | |
|-----1.RO Request------>| |
|<---2.RO Request Ack----| |
| [RO Control] |
| | |
| |------3.RO Init-------->|
| | |
|<-----------------4. RO Setup--------------------|
|------------------5. RO Setup Ack--------------->|
| |<----6. RO Init Ack-----|
| | |
| | |
Figure 7: MAG requested setup of a localized routing path
Loureiro & Liebsch Expires September 9, 2010 [Page 17]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
8. Summary of achievements to meet LR Requirements
Although [RFC5213] does not mandate any special requirements
regarding route optimization, it is stated that path optimization
should be enforced by the MN's LMA. The specified protocol meets
this requirement by introducing the ROC function located at the LMA
which controls the set up and update of localized routing states. By
controlling the localized routing setup and maintenance from a
dedicated LMA, a stable protocol operation is achieved in terms of
the following:
o Consistent protocol message sequence for all topologies and
mobility scenarios
o Stable Localized Routing state update in case of handover (even
for exceptional case as identified in
[I-D.ietf-netext-pmip6-lr-ps] section 3.2)
o Efficient means to handle distributed mobility states in scenarios
with multiple LMAs
Another characteristic of the proposed solution lies in the way the
setup of localized routing is performed by using inter-LMA signaling
for scenarios with multiple LMAs (A12 and A22 according to
[I-D.ietf-netext-pmip6-lr-ps]). This poses advantages in terms of
having to perform discovery of peer LMA only once during the lifetime
of the data sessions between the MN and the CN, since these nodes do
not change LMAs. This is different for MAGs, which change during the
MN's and/or the CN's handover. On the other hand, introducing for
example direct signaling between the MN's MAG and the CN's LMA may
require discovery and the dynamic setup of a new security association
every time the MN or CN perform handover.
Loureiro & Liebsch Expires September 9, 2010 [Page 18]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
9. IANA Considerations
This document defines 8 new Mobility Header types for the MH type
field in the Mobility Header. These types are described in
Section 5.1. According to the protocol specification, the Mobility
Header type identifies also the protocol interface, on which a
protocol message is being applied.
This document defines 1 new Mobility Header option. This option is
described in Section 5.2.
Loureiro & Liebsch Expires September 9, 2010 [Page 19]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
10. Security Considerations
Security threats for localized routing in network-based mobility
management comprise the danger of unauthorized set up or redirect of
an established forwarding path by a malicious node. Signaling
messages of this protocol between a MAG and an LMA as well as between
LMAs must be authenticated by means of IPsec [RFC4301]. The use of
IPsec between an LMA and a MAG follows [RFC5213].
Protection of signaling messages between an LMA and a MAG uses the
mechanisms of Encapsulating Security Payload (ESP) [RFC4301] in
transport mode with mandatory data origin authentication by means of
a non-null payload authentication algorithm. The use of encryption
is optional. The same requirements apply to signaling between LMAs
as well as between MAGs. In particular, if the network which
interconnects two LMAs and/or two MAGs is not trusted, the use of
encryption is recommended to support confidentiality protection
between LMAs and between MAGs respectively.
Loureiro & Liebsch Expires September 9, 2010 [Page 20]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
11. Contributors
This document is based on an early contribution to the NetLMM Working
Group [I-D.abeille-netlmm-proxymip6ro]. Many thanks to Julien
Abeille, who contributed a lot to the original concept of this
protocol extension to Proxy Mobile IPv6.
Loureiro & Liebsch Expires September 9, 2010 [Page 21]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
12. References
12.1. Normative References
[I-D.ietf-netext-pmip6-lr-ps]
Liebsch, M., Jeong, S., and W. Wu, "PMIPv6 Localized
Routing Problem Statement",
draft-ietf-netext-pmip6-lr-ps-02 (work in progress),
January 2010.
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-13
(work in progress), June 2009.
[I-D.liebsch-dime-pmip6-lmaresolve]
Liebsch, M., Loureiro, P., and J. Korhonen, "Local
Mobility Anchor Resolution for PMIPv6",
draft-liebsch-dime-pmip6-lmaresolve-01 (work in progress),
October 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5555] Soliman, H., "Mobile IPv6 Support for Dual Stack Hosts and
Routers", RFC 5555, June 2009.
12.2. Informative References
[I-D.abeille-netlmm-proxymip6ro]
Liebsch, M., Le, L., and J. Abeille, "Route Optimization
for Proxy Mobile IPv6",
draft-abeille-netlmm-proxymip6ro-01 (work in progress),
November 2007.
[RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility
Management (NETLMM)", RFC 4831, April 2007.
Loureiro & Liebsch Expires September 9, 2010 [Page 22]
Internet-Draft Proxy Mobile IPv6 Localized Routing March 2010
Authors' Addresses
Paulo Loureiro
NEC Laboratories Europe
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg,
Germany
Phone: +49 6221 4342177
Email: paulo.loureiro@nw.neclab.eu
Marco Liebsch
NEC Laboratories Europe
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg,
Germany
Phone: +49 6221 4342146
Email: marco.liebsch@nw.neclab.eu
Loureiro & Liebsch Expires September 9, 2010 [Page 23]