Network Working Group Q. Wu
Internet-Draft B. Sarikaya
Intended status: Standards Track Huawei
Expires: August 16, 2010 February 12, 2010
An Extension to Proxy Mobile IPv6 for Local Routing Optimization
draft-wu-netext-local-ro-05
Abstract
This document extends local routing in Proxy Mobile IPv6 (PMIPv6) and
defines a localized routing optimization protocol between Mobility
Access Gateways within a single provider domain. The protocol
supports operation over IPv4 transport networks, IPv4 home address
mobility and handover. The Local mobility anchor initiated and
mobile access gateway initiated local routing are allowed to setup
local routing path between the mobile and correspondent node by
sending messages to the corresponding mobile access gateway or local
mobility anchor. If the MN & CN are anchored with two different LMAs
then the MN-LMA must discover which LMA the CN is registered with
before an optimized local routing path can be established. Mobile
Access Gateways create and refresh bindings using proxy binding
update and acknowledgement messages.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified,
and derivative works of it may not be created, and it may not be
published except as an Internet-Draft.
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.
Wu & Sarikaya Expires August 16, 2010 [Page 1]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
This Internet-Draft will expire on August 16, 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.
Wu & Sarikaya Expires August 16, 2010 [Page 2]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. PMIP6 Local Routing OptimizationScenario Analysis . . . . . . 5
4. Local Routing Optimization Protocol Overview . . . . . . . . . 6
4.1. MAG-initiated Local Routing Optimization . . . . . . . . . 7
4.1.1. Handover Considerations . . . . . . . . . . . . . . . 9
4.2. LMA-initiated Local Routing Optimization . . . . . . . . . 10
4.2.1. Handover Considerations . . . . . . . . . . . . . . . 11
5. Processing Considerations . . . . . . . . . . . . . . . . . . 12
5.1. Mobile Access Gateway Considerations . . . . . . . . . . . 12
5.2. Local Mobility Anchor Considerations . . . . . . . . . . . 15
6. IPv4 Support . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. IPv4 HoA Support . . . . . . . . . . . . . . . . . . . . . 17
6.2. IPv4 Transport Support . . . . . . . . . . . . . . . . . . 17
7. Inter-LMA Local Routing Considerations . . . . . . . . . . . . 18
7.1. MAG-initiated Inter-LMA Local Routing . . . . . . . . . . 18
8. Conceptual Data Structure Extensions . . . . . . . . . . . . . 19
8.1. Binding Update List Extensions . . . . . . . . . . . . . . 19
8.2. Binding Cache Entry Extensions . . . . . . . . . . . . . . 20
8.3. Routing Table Entry Extensions . . . . . . . . . . . . . . 20
9. Local Routing Optimization Message Format . . . . . . . . . . 21
9.1. Local Routing Optimization Mobility Option . . . . . . . . 21
9.2. The Local Routing Optimization Request (LROREQ) Message . 22
9.3. Local Routing Optimization Response Message (LRORSP) . . . 23
9.4. MN-CNs Pair Mobility Option . . . . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . . 26
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
13.1. Normative References . . . . . . . . . . . . . . . . . . . 27
13.2. Informative References . . . . . . . . . . . . . . . . . . 27
Appendix A. Future Extension . . . . . . . . . . . . . . . . . . 28
A.1. LMA Route Optimization Start Message . . . . . . . . . . . 28
A.1.1. LMA Route Optimization Start Request Message . . . . . 28
A.1.2. LMA Route Optimization Start Response Message . . . . 29
A.2. LMA Initiated Inter-LMA Local Routing . . . . . . . . . . 30
A.2.1. IPv4 Support Consideration . . . . . . . . . . . . . . 31
A.3. LMA Initiated operation for Inter-LMA Local Routing . . . 31
Appendix B. Change Notes . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Wu & Sarikaya Expires August 16, 2010 [Page 3]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
1. Introduction
Proxy Mobile IPv6 (PMIP6) [RFC5213] allows the Mobility Access
Gateway (MAG) to optimize packet delivery by locally routing packets
within one MAG instead of reverse tunneling them to the mobile node's
Local Mobility Anchor (LMA). However, it does not address the
optimization of routing between two Mobile Access Gateways sharing
the same LMA or registered to different Local Mobility Anchors; nor
does it define how local routing optimization capability is detected,
the entity that initiates local routing optimization, or how to
determine whether local routing optimization is permitted.
This document defines local routing optimization mobility messages
and options for PMIPv6 that are intended to assist the Mobile Access
Gateways to negotiate and setup a local routing path between each
other. The new local routing optimization mobility options allow the
LMA and the MAG to discover whether local routing is allowed and, if
som what form it may take. The local routing optimization protocol
can be initiated by either of the PMIPv6 managed nodes and provides a
flexible negotiation mechanism for local routing.
As RFC 5213 [RFC5213] warns, use of local routing may affect
accounting and traffic policies relating to the mobile node, LMA
routing policies, and security policies. The general aim of the
proposals in this document is to provide better manageability of
local routing services and local routing service provisioning from
the point of view of both operators and service providers within one
Provider domain.
2. Terminology
The keywords "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].
The document uses the terminology specified in RFC 5213 [RFC5213]and
RFC 3775 [RFC3775] In addition, this document defines the following
terms:
Local routing (LR)
When local routing is active, traffic between the MN and the CN
does not pass through the LMA and is routed directly between the
MAG(s) to which the MN and CN are attached. Local routing may
only take place between Mobile Access Gateways within a single
provider domain.
Wu & Sarikaya Expires August 16, 2010 [Page 4]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
Local Routing Optimization Request (LROREQ):
A message initiated by the MAG or LMA to which the Mobile Node is
attached requesting the MAG or LMA to which the Mobile Node or the
Correspondent Node is attached to establish a local routing path
between the MN and CN.
Local Routing Optimization Response (LRORSP):
A reply message from a MAG or LMA confirming the local routing
optimization results.
3. PMIP6 Local Routing OptimizationScenario Analysis
Figure 1 shows the reference architecture for PMIP6 local routing
optimization. In this architecture, local communication between
PMIPv6 managed nodes (i.e., MAGs) is constrained within a single
Provider domain, as described in [I-D.ietf-netext-pmip6-lr-ps]. In
the architecture, LMA1 and LMA2 may be the same LMA.
+---------+
============|LMA1/LMA2|============
// +---------+ \\
|| ||
|| ||
|| +-----------+
+-----------+ | IPv4/IPv6 |
| IPv4/IPv6 | | Network |
| Network | +-----------+
+-----------+ ||
|| ||
|| +-----------+ ||
+------+ |IPv4/IPv6 | +------+
| MAG1 |=============================| MAG2 |
+------+ | Network | +------+
| | +-----------+ | |
+-----+ +-----+ +-----+ +-----+
| | | |
+----+ +-----+ +-----+ +-----+
| MN | | CN1 | | CN2 | | CN3 |
+----+ +-----+ +-----+ +-----+
{IPv4-MN-HoA1} {IPv4-CN1-HoA2} {IPv4-CN2-HoA3} {IPv6-CN3-HoA4}
{IPv6-MN-HoA1} {IPv6-CN2-HoA3}
Figure 1: Reference Architecture for PMIP6 Local Routing
Wu & Sarikaya Expires August 16, 2010 [Page 5]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
Depending on how MN and CN are distributed into different provider
domains, three typical scenarios need to be considered as follows:
Scenario 1: Intra-MAG local routing
In this scenario, both the MN and CN are attached to the same MAG
and are anchored with the same LMA or different LMAs.
Scenario 2: Intra-LMA local routing
In this scenario, the MN and CN are attached to different MAGs and
are anchored with the same LMA.
Scenario 3: Inter-LMA local routing
In this scenario, the MN and CN are attached to different MAGs and
are anchored with different LMAs.
In all three scenarios, the MN is allowed to roam within the domain
in which its anchoring LMA is located or move from one domain to
another. The CN should stay with the MN in the same domain; e.g.,
the MN moves to the visited domain to which the CN belongs. Another
example is if the MN and CN move to the same visited domain to which
MN's LMA or CN's LMA does not belong.
4. Local Routing Optimization Protocol Overview
The protocol specified here focuses on intra-MAG local routing and
intra-LMA local routing and assumes that
o the MAGs are situated in one Provider domain
o MN and CN are anchored with the same LMA.
o The MAG has the capability to perceive intra-MAG local routing
(i.e., the MAG can detect whether the mobile node and
correspondent node are attached to the same MAG).
o The LMA has the capability to perceive intra-LMA local routing
(i.e., the LMA can detect whether the MAGs to which the MN and CN
are attached belong to the same or different LMAs).
The decision to enable/disable detection of local routing should be
based on the policy configured on the MAG or LMA. The trigger for
detection of local routing may come from uplink or downlink datagram
forwarding or from the application layer. The specific details on
Wu & Sarikaya Expires August 16, 2010 [Page 6]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
how this is achieved are beyond of the scope of this document.
Depending on how local routing is initiated, local routing
optimization can be categorized into:
o MAG-initiated local routing optimization
o LMA-initiated local routing optimization
4.1. MAG-initiated Local Routing Optimization
When the MAG is triggered and enabled to detect local routing, the
MAG can detect whether the MN and CN are attached to the same MAG by
looking at the source and destination address of outgoing packets and
checking the binding update list of the MN and CN.
If, upon receiving a packet from the MN or the CN, the MAG perceives
that the MN and CN are both attached to the same MAG, it can initiate
local routing optimization by asking the LMA to check the value of
the Intra-MAG LocalRouting flag (defined in Section 8.1). If the MAG
detects that the MN and CN are not attached to the same MAG but wants
to check whether intra-LMA routing is allowed (i.e., the MN and CN
are attached to different MAGs but anchored to the same LMA), it also
can initiate LR by sending a message to the LMA. The message may be
a Binding Update message which contains the Local Routing
Optimization Mobility Option (Section 9.1) and Home Network Prefix
Option [RFC5213] for the correspondent node or a newly defined local
routing optimization message. It will be used to negotiate with the
LMA to verify whether local routing is allowed and determine what
local routing optimization is supported between the mobile node and
correspondent node. If the LMA can not determine whether local
routing optimization is supported, it may ask AAA server to make
decision, and the AAA server may be used to authorize the use of
localized routing service for the MN. If LR is not authorized, the
LMA will respond to the MAG that local routing optimization is not
available. Otherwise, the LMA will set the Intra-MAG LocalRouting or
Intra-LMA LocalRouting flag on the MAG by sending a successful
response message with the Local Routing Optimization Indication (LRI)
field of the Local Routing Optimization Mobility Option set
appropriately. If the LMA can validate the Correspondent Node's Home
Network Prefix (HNP), the LMA may notify the MN's MAG of the MAG
address associated with the CN's HNP using the MN-CNs Pair Mobility
Option (Section 9.4) in the same response message. In the intra-MAG
local routing case, the MN-CNs Pair Mobility Option can be omitted
from the response message. The LMA may also set its own LocalRouting
flag to indicate local routing is in use and correlate it with the
binding cache entries corresponding to the MN and CN. Note that
setting the local routing flag is helpful for avoiding duplication of
local routing behavior initiated from the MAG and triggering the MAG
Wu & Sarikaya Expires August 16, 2010 [Page 7]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
to setup a local routing path. Distinguishing between different
local routing types on the MAG helps the LMA to build the response
message efficiently. For example, when Local Routing Optimization
(LRI) field of the Local Routing Optimization Mobility Option is set
to the value of one, it means that MAG already knows that the MN and
CN are attached to the same MAG by checking binding update list,
therefore it is unnecessary to include the CN's MN-CNs Pair Mobility
Option; when the LRI field is not set to one, the MN-CNs Pair
Mobility Option MUST be included in the response message from LMA,
since only the LMA knows the address of the MAG to which the CN is
attached.
After the successful initiation of local routing optimization, if the
MN and CN attach to different MAGs (e.g., MAG1 and MAG2) and the
intra-LMA LocalRouting flag on MAG is set to value one, MAG1 may send
a PBU message to MAG2 setting the lifetime of the binding of the MN
at MAG2. Similarly, if the intra-LMA LocalRouting flag is set to
value one on MAG2, MAG2 sends a PBU message to MAG1. This PBU
message sets the lifetime of the binding of CN at MAG1. Each PBU
MUST be acknowledged with a PBA. With the PBU/PBA exchange, the
local data path between MAGs is established and the binding caches
associated with MN and CN are set up. A PBU-PBA exchange is repeated
to extend the lifetime of the binding. Subsequently the routing
table entry can be setup based on the binding caches established on
the MAGs. The PBU/PBA signaling is protected using IPsec
Encapsulation security payload [RFC4303] in transport mode with
mandatory integrity protection.
For data traffic, either of the MAGs can lookup the routing table
entry associated with the MN or CN and identify the tunnel to the
right MAG in terms of the destination address of an outgoing data
packet. If MN and CN attach to the same MAG, the traffic from the MN
will go directly to the CN via the MAG. If MN and CN attach to
different MAGs and register to the same LMA, the traffic from MN will
be forwarded directly by the MAG associated with the MN to the MAG
associated with the CN.
Wu & Sarikaya Expires August 16, 2010 [Page 8]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
+--+ +------+ +-----+ +------+ +--+
|MN| | MAG1 | | LMA | | MAG2 | |CN|
++-+ +--+---+ +--+--+ +--+---+ +-++
Attach to MAG1 | |Attach to MAG2
|---------->| | <------------+
| Datagram | PBU'/LROREQ | | |
|==========>|(MN-CN Pair) | | |
| |------------->| | |
| | +---+-----+ | |
| | |BCE Check| | |
| PBA'/LRORSP +---------+ | |
| | [MAG2] | | |
| |<------------ | | |
| +-------+---------+ | | |
| |Enable Intra-LMA/| | | |
| |intra-MAG Routing| | | |
| +-------+---------+ | | |
| Bidirectional PBU/PBA between MAGs |
| |<--------------------------->| |
| +-------------+ | +-------------+ |
| |Setup Binding| | |Setup Binding| |
| |and Tunnel | | | and Tunnel | |
| +-------------+ | +-------------+ |
| Datagram | Datagram | Datagram |
|==========>|============================>|===========>|
| Datagram | Datagram | Datagram |
|<==========|<=============|==============|<===========|
| | | | |
| | | | |
Figure 2: MAG-initiated Local Routing Optimization
4.1.1. Handover Considerations
When the MN moves from the old MAG (e.g., pMAG1) in the previous
access network to a new MAG (e.g., nMAG1) in the new access network,
context information (including the MAG addresses of all the CNs which
are communicating with MN) for the MN in pMAG1 may be transferred to
nMAG1. The Context Request Option [I-D.ietf-mipshop-pfmipv6] can be
reused to carry the context information from pMAG1 to nMAG1. nMAG1
can use this data to send PBU messages to each of the MAGs connected
to a CN with which the MN was in communication via the provisional
secure data path, updating the binding in each MAG with which the MN
was in communication and re-establishing an optimal local routing
path between the MN and its CNs.
Wu & Sarikaya Expires August 16, 2010 [Page 9]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
+-----+ +---------+ +---------+
|pMAG1| |nMAG1(MN)| | MAG2(CN)|
+--+--+ +---+-----+ +---+-----+
| | |
| HI/HACK | |
|<--------------->| |
|Predictive/Reactive |
| |Bidirectional PBU/PBA|
| |<------------------> |
| | |
| +------+------+ +-----+-------+
| |UpdateBinding| |UpdateBinding|
| | and Tunnel | | and Tunnel |
| +------+------+ +-----+-------+
| | Datagram |
| |<===================>|
Figure 3: MAG-initiated Local Routing During Handover
4.2. LMA-initiated Local Routing Optimization
When the LMA is triggered and enabled to detect local routing, the
LMA can detect whether the MN and CN are registered to the same LMA
by looking at the source and destination address of outgoing and
incoming packets and checking the binding update list of MN and CN.
Upon receiving a packet from the MN or CN and detecting that the MN
and CN are registered to the same LMA, it may set its intra-LMA
LocalRouting flag, correlating it with the binding cache entries
associated with the MN and CN. And then LMA initiates local routing
optimization to determine the value of Intra-LMA LocalRouting flag
(defined in Section 8.1) on the MAG, i.e., notify or enforce the
value of intra-LMA LocalRouting flag on the MAG associated with the
MN by means of a LROREQ/LRORSP message exchange. It will be used to
help LMA to determine whether the local routing optimization is
allowed. If local routing optimization is allowed, then LMA will be
responsible for enforcing local optimization on the MAG. The AAA
server serving the LMA may be used to authorize the use of localized
routing service for the MN. IF LR is not authorized,the LMA will
respond to the MAG with failure information indicating that intra-LMA
routing optimization is not allowed, otherwise, it will notify the
MAG to set the intra-LMA LocalRouting flag. The other procedures are
same as those described in Section 4.1.
Wu & Sarikaya Expires August 16, 2010 [Page 10]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
+--+ +------+ +-----+ +------+ +--+
|MN| | MAG1 | | LMA | | MAG2 | |CN|
++-+ +--+---+ +--+--+ +--+---+ +-++
Attach to MAG1 | |Attach to MAG2
|---------->| +-------+----------+ <------------+
| | | BCE Check | | |
| | |Perceive MAG1 and | | |
| | |MAG2 register to | | |
| | |the same LMA | | |
| | +-------+----------+ | |
| | LROREQ | | |
| | (MAG2) | | |
| |<------------ | | |
| +-------+---------+ | | |
| |Enable Intra-LMA/| | | |
| | Routing | | | |
| +-------+---------+ | | |
| LRORSP | | |
| |------------->| | |
| Bidirectional PBU/PBA between MAGs |
| |<--------------------------->| |
| +-------------+ | +-------------+ |
| |Setup Binding| | |Setup Binding| |
| | and Tunnel | | | and Tunnel | |
| +-----+-------+ | +-----+-------+ |
| Datagram | Datagram | Datagram |
|==========>|============================>|===========>|
| Datagram | Datagram | Datagram |
|<==========|<============================|<===========|
Figure 4: LMA Initiated Local routing optimization
4.2.1. Handover Considerations
If the MN moves from the old MAG (e.g., pMAG1) in the previous access
network to the new MAG (e.g., nMAG1) in a new access network, nMAG1
may update the binding cache entry associated with MN at the LMA by
sending a normal PBU message. At the same time, the LMA may refresh
the binding update list associated with the MN and update the binding
of each MAG with which MN was in communication via the established
local route optimization path by sending a LROREQ message to each
MAG. Also pMAG1 can use a procedure similar to that described in
Section 4.1.1 to transfer MN's registration entry at pMAG1 to nMAG1.
Wu & Sarikaya Expires August 16, 2010 [Page 11]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
+-----+ +---------+ +----------+ +---------+
|pMAG1| |nMAG1(MN)| |LMA(MN,CN)| | MAG2(CN)|
+--+--+ +---+-----+ +----+-----+ +---+-----+
| | Normal PBU | |
| |-------------->| |
| | | |
| | Normal PBA | |
| |<------------- | LROREQ |
| | |-------------->|
| | | |
| | | LRORSP |
| | |<------------- |
| Bidirectional PBU/PBA between MAGs
| |<----------------------------->|
| +------+------+ | +-----+-------+
| |UpdateBinding| | |UpdateBinding|
| | and Tunnel | | | and Tunnel |
| +------+------+ Datagram +-----+-------+
| |<=============================>|
| | | |
Figure 5: LMA-initiated Local Routing Optimization During Handover
5. Processing Considerations
5.1. Mobile Access Gateway Considerations
When the MAG sends a LROREQ or PBU to the LMA, it may include the
Routing Optimization Mobility and MN-CNs Pair Mobility Options in a
binding update message or create a new routing optimization request
message to include these two options:
o The Routing Optimization Mobility Option is used to negotiate what
kind of local routing optimization is available. If intra-MAG
local routing is allowed, the LRI field in the Routing
Optimization Mobility Option is set to one (1). If the intra-MAG
local routing is not available but the MAG would like to check
whether intra-LMA local routing is allowed, the MAG will set the
LRI field of the Routing Optimization Mobility Option to value 0
in the PBU or LROREQ message to the LMA, because the mobile node's
MAG does not know whether traffic between MN and CN can be locally
routed within one LMA.
o The MN-CNs Pair Mobility Option is used for the LMA to verify the
validity of the local routing optimization path end points (in the
intra-MAG local routing scenario) or to request the LMA to
determine the proxy CoA-Address of the Crrespondent Node for local
Wu & Sarikaya Expires August 16, 2010 [Page 12]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
routing optimization (in the intra-LMA local routing scenario).
In the case of intra-MAG local routing, MAG should fill the MN-CNs
Pair Mobility Option with MN HNP, MN Proxy CoA, CN HNP and CN
Proxy CoA. In the case of intra-LMA local routing, the MAG only
fills MN-CN pairs mobility option with MN's HNP, MN's Proxy CoA
and CN's HNP.
When the MAG receives a binding acknowledgement message containing
the Routing Optimization Mobility Option or routing optimization
response message it will check the validity of all the fields,
including whether the sequence number value in the acknowledge/
response message is identical to the sequence number value in the
corresponding request and whether the MN-CNs Pair Mobility Option is
present. If the message is valid, the MAG will extract the LRI field
from the Routing Optimization Mobility Option or routing optimization
response message and check the value. If the LRI field is zero, it
indicates the LMA does not support local routing optimization and the
MAG should set the intra-MAG LocalRouting flag to zero in the binding
update list extension; if the LRI field is one, it indicates that the
LMA allows local routing in one MAG and bypass the LMA and MAG should
set intra-MAG LocalRouting flag to value one in the binding update
list extension. If the LRI field is two, it indicates LMA has found
the Correspondent Node's MAG address in terms of the HNP of the CN.
In this case, the MAG should extract the Correspondent Node's MAG
address from the initial binding acknowledgement or routing
optimization response message and store it in a binding update list
extension with the Correspondent Node's HNP and set the intra-LMA
LocalRouting flag in the binding update list extension.
In LMA-initiated local routing, upon receiving a LROREQ message from
the LMA, the MAG extracts MN HNP from MN-CNs Pair Mobility Option and
searches the binding update list for a matching IPv6 home network
prefix in the list of prefixes it stores for each mobile node that
the MAG is serving. If a match is found, the MAG MUST send a PBU
message to the MAG of the Correspondent Node. PBU message lifetime
is set to the lifetime value in LROREQ message. Destination address
is the same as Proxy CoA field in the CN part of MN-CNs Pairs
Mobility Option included in LROREQ message. The MAG MUST send a PBU
message to the MAG of each Correspondent Node if the LROREQ message
contains more than one CN in the MN-CNs Pair Mobility Option. For
each PBU message sent to a MAG, a new binding update list entry MUST
be created if it has not already been created before, e.g. refresh
PBU. The fields in this entry are set as follows:
o Mobile Node information fields like MN-Identifier, link-layer
identifier, home network prefixes, etc., are copied from the entry
that was created during the initial PBU procedure.
Wu & Sarikaya Expires August 16, 2010 [Page 13]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
o The IPv6 address of the LMA serving the attached mobile node is
replaced with the Proxy-CoA of the MAG to which the PBU was sent
and Proxy-CoA field in the Correspondent Node part of the MN-CN RO
Option is copied to this field. The IP address of the
Correspondent Node to which MN is communicating is set to the Home
Network Prefix field of the Correspondent Node part of the MN-CNs
Pair Mobility Option. If the P bit is set in the MN-CNs Pair
Mobility Option, this field is set to the IPv4 HoA field in the
Correspondent Node part of MN-CNs Pair Mobility Option.
o The initial value of the Binding Lifetime field is set to the
Lifetime field in the LROREQ message.
o A configuration variable called EnableLMALocalRouting is defined
at the MAGs to indicate whether or not the MAG is allowed to
enable local routing of the traffic exchanged between a visiting
MN that is locally connected to one of the interfaces of the
mobile access gateway and a CN that is locally connected to one of
the interfaces of another mobile access gateway that is connected
to the same LMA. Any LROREQ message received from LMA with
lifetime greater than zero enables the local routing at this MAG
and the MAG that receives LROREQ first time MUST set
EnableLMALocalRouting to 1.
When the Intra-MAG LocalRouting flag or Intra-LMA LocalRouting flag
are set on the MAGs, one MAG may send a Proxy Binding Update message
to another MAG to establish a corresponding binding cache associated
with the MN and CN. Upon receiving a Proxy Binding Update message,
the MAG checks if the LocalRouting flag is set to value one. If the
LocalRouting flag is not set to value one, the MAG MUST reject the
request and send a Proxy Binding Acknowledgement message with the
status field set to 129 (administratively prohibited).
Upon accepting a Proxy Binding Update request, the MAG MUST create a
Binding Cache entry. The Source address in the Proxy Binding Update
is copied to the Proxy CoA field of the binding cache entry. The
Mobile Node data (MN-Identifier, link-layer identifier, link-local
address, home network prefixes, etc.) are copied from the
corresponding fields of the proxy binding update.
Upon accepting a Proxy Binding Update request for the first time from
another MAG, the MAG MUST establish a bi-directional tunnel between
the two MAGs. The tunnel endpoints are the Proxy-CoA of the
receiving Mobile Access Gateway and the Proxy-CoA of the Mobile
Access Gateway that sent the PBU, which can be obtained from the
source address of the PBU message. This tunnel SHOULD be deleted
when there are no Mobile Nodes sharing it or when a Mobile Access
Gateway receives a PBU message from another MAG with lifetime set to
Wu & Sarikaya Expires August 16, 2010 [Page 14]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
zero or when the MAG receives a LROREQ message from the corresponding
LMA with the lifetime set to zero.
In case of handover or detachment, if the MAG cannot detect the
presence of the mobile node on the connected link, the MAG SHOULD
terminate the binding of the MN by sending a PBU message to all CN's
MAGs that has established bindings. The MAG sends a PBU message to
each MAG with lifetime set to zero. Proxy-CoA of the MAG field in
each Binding update list entry determines the MAG address. If IPv4
transport is used, IPv4-Proxy-CoA is used. The MAG MUST also remove
each Binding Update List entry on all CN's MAGs created for that MN.
In order to re-establish the bindings of the MN that is involved in
local routing, i.e. with binding update list entries on the new MAG
other than the home (local mobility anchor registration), the
previous MAG MAY use a context transfer procedure to transfer the
local routing state to the new MAG. Each entry in the binding update
list for this MN other than the LMA entry can be transferred. After
handover is completed, the new MAG MUST send PBU messages to the MAG
(Proxy-CoA or IPv4-Proxy-CoA) associated with each Correspondent
Node. Another way to re-establish the bindings of the MN is to have
the new MAG trigger the LMA to notify all the CN's MAGs to update
binding update list on all CN's MAGs created for that MN.
For the data traffic between the MN and CN, on receiving a packet
from a MN connected to its access link, to a destination (i.e., CN)
that is directly connected or not directly connected to the same
access link, the MAG will check whether source/destination address
pairs in the routing table entry matches the source/destination
address in the outgoing data packet and identify the tunnel to the
right destination MAG. If the source address and destination address
in the packet match one of source/destination address pairs in the
routing entry, the packet must be tunneled to the Proxy CoA
corresponding to the destination address in the tunnel interface.
For the packet from a Mobile Node connected to its access link to a
destination that is also directly connected to the same access link,
the packet must go directly via the MAG.
5.2. Local Mobility Anchor Considerations
In the case of MAG initiating local routing, upon receiving a PBU or
routing optimization request message, the LMA will check the LRI
field in the Routing Optimization Mobility Option or routing
optimization message. If the LRI field is set to value one, the LMA
will check whether there exist a binding cache list for the CN and
whether the MN's proxy CoA address is same as the CN's proxy CoA
address. If LRI field is zero and the Correspondent Node's home
network prefix is included, the LMA will check whether there exists a
Wu & Sarikaya Expires August 16, 2010 [Page 15]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
binding cache list for CN in terms of the correspondent node's home
network prefix. If one does, the LMA will fill the MN-CNs Pair
Mobility Option with the Proxy CoA and HNP of the CN and respond to
the MAG with LRI field set to value two. Otherwise, the LMA will
respond to the MAG with the LRI field set to zero to indicate the MAG
that local routing optimization is not available.
In the case of LMA-initiated local routing, the LMA may be
responsible for perceiving intra-LMA routing and correlate MN with CN
in the binding update list. Upon perceiving that intra-LMA local
routing is allowed between the MN and CN, the LMA fills the MN-CNs
Pair Mobility Option with MN HNP, MN Proxy CoA, CN HNP, CN Proxy CoA
and includes it in the Local Routing Optimization Request
message(LROREQ). In the message, the LRI field set to value two.
Then the LMA receives routing optimization reply message from the
corresponding MAG.
The LMA MUST send a LROREQ message to either or both of MAGs where MN
and CN are located. If CN (or MN) is not connected to the same LMA,
the LROREQ message MUST be sent to only to the MAG that is connected
to the LMA. The LROREQ message MUST contain at least one pair of MN-
CNs Pair Mobility Options. If the MN is communicating with more than
one CN which is regitered with the same LMA, the LMA MUST include
more than one CN in the MN-CNs Pair Mobility Option if local routing
will be enabled. Before the LROREQ is sent to a MAG, the LMA MUST
place the MN address information which is connected to this MAG first
in MN-CNs Pair Mobility Option.
The LMA MAY set the Lifetime field in the LROREQ message to a non-
zero value. Any non-zero lifetime value enables two MAG to start
local routing optimization for MN-CN traffic. The lifetime values
sent to two MAG MUST be the same.
The LMA MAY stop the local routing optimization operation any time it
wishes. In that case LMA MUST set the Lifetime field in LROREQ
message to zero. After receiving a LRORSP message from the MAG with
a matching sequence number field, the LMA-MAG tunnel needs to be re-
established separately for each MAG.
The LMA sets the sequence number field in LROREQ message to a nonzero
integer. This initial sequence number is incremented by one for the
next LROREQ message sent. The LMA MUST receive a LRORSP message with
the same sequence number as in the corresponding LROREQ message
previously sent. This message is acknowledged with a LROREQ message.
If no acknowledgement is received, the LMA MUST retransmit the LROREQ
message.
Wu & Sarikaya Expires August 16, 2010 [Page 16]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
6. IPv4 Support
IPv4 support is needed in two cases:
o The MN is IPv4 enabled and receives an IPv4 home address and
o The transport network between the LMA and the MAG is an IPv4
network
In both two cases, the encapsulation mode as described in
[I-D.ietf-netlmm-pmip6-ipv4-support] is transparent to the MAG
concerned before setting up the localized routing path. This may
result in data packets being dropped by the egress/ingress tunnel end
points, i.e., the MAGs.
Therefore local route optimization can be supported only if the
encapsulated mode is aware or default configured during setting up
the localized routing path.
6.1. IPv4 HoA Support
If the MN is IPv4-enabled and receives an IPv4 home address, both the
MN and the CN configure global IPv4 home addresses by exchanging PBU/
PBA between the MAG and the LMA as explained in
[I-D.ietf-netlmm-pmip6-ipv4-support].
The LMA MUST include the IPv4 IPv4-MN-HoA in local routing
optimization messages for both MN and CN. The LMA MAY include the
Home Network Prefix in PBA if the MN or CN has been assigned one.
Both local routing optimization request and local routing
optimization response messages are IPv6 messages and are transported
over the LMA-MAG tunnel in the same fashion as the PBU and PBA
messages.
The PBU and PBA exchanged between the MAGs are IPv6 messages and are
transported as unencapsulated IPv6 messages between MAGs. For
simplification, we can assume the MAGs in communication are using the
default encapsulation mode. Data traffic between the MAGs after
local routing is established is transported in the IPv6 inner packet
as IPv4 payload.
6.2. IPv4 Transport Support
If IPv4 transport is used between the MAG and the LMA, the LROREQ,
LRORSP, PBU and PBA messages are transported as IPv6 messages using
IPv4 or IPv4-UDP-ESP encapsulation
[I-D.ietf-netlmm-pmip6-ipv4-support]. IPv4-UDP and IPv4-UDP-TLV
modes are not used because no NAT boxes are supported in this local
Wu & Sarikaya Expires August 16, 2010 [Page 17]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
routing optimization protocol. IPv4 data packets are transported in
an IPv4 packet or encapsulated in IPv4-UDP-ESP encapsulation.
7. Inter-LMA Local Routing Considerations
In this section we concentrate on the case where the MN and CN are
served by two different LMAs in the same Provider domain, which is
not covered by Section 4and Section 5.
7.1. MAG-initiated Inter-LMA Local Routing
If the MAG to which the MN and CN are attached is registered to
different LMAs, it needs to initiate local routing optimization to
the different LMAs respectively. The message exchange for the
protocol is shown in Figure 6. LR is triggered at one of the MAGs
(e.g., MAG1) when a datagram is received on its upstream interface
whose destination address is a CN for which LMA2 has a binding cache
entry. MAG1 requests the address of LMA2 from LMA1 by sending a
LROREQ message containing the HNP of the CN. LMA1 processes the
LROREQ message and looks up the address of LMA2 based on the HNP or
HoA of the CN. There is one possible way to achieve this goal:
o LMA1 can exchange with a AAA server to retrieve the address of
LMA2. LMA1 sends the address of the CN and requests the address
of the LMA to which the CN is anchored. The AAA server responds,
sending the address of LMA2 to LMA1. See [I-D.wu-dime-pmip6-lr]
for further details.
Note that LMA2 address discovery is only performed once, i.e., when
LMA1 does not know LMA2 address at the first time. If discovery is
successful, the address of LMA2 will be correlated with the HNP of
the CN in the Mobile Nodes's binding update list for future use.
Upon retrieving the address of LMA2, LMA1 then delivers it to MAG1 by
means of an LRORSP message. MAG1 then sends LROREQ message
containing a MN-CNs Pair Mobility Option (defined in Section 9.4) to
LMA2. Note that MN-CNs Pair Mobility Option does not contain the CN
Proxy CoA. LMA2 processes the LROREQ message and looks up MAG2
address based on CN HNP or HoA extracted from the message. If the
lookup is successful, LMA2 responds to the MAG1 with the address of
the MAG to which the CN is attached (i.e., the address of MAG2).
MAG1 and MAG2 exchange PBU/PBA messages to establish binding cache
list between each other and the direct path between MAG1 and MAG2
will be set up.
Wu & Sarikaya Expires August 16, 2010 [Page 18]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
+------+ +----------+ +---------+ +------+
| MAG1 | | LMA1(MN) | | LMA2(CN)| | MAG2 |
+---+--+ +----+-----+ +----+----+ +---+--+
| |LMA2 Discovery | |
| |-----> | |
| | | |
| LROREQ(CN) | | |
|--------------->| | |
| | | |
| LRORSP(LMA2) | | |
|<---------------+ | |
| LROREQ(MN,MAG1,CN) | |
|------------------------------->| |
| LRORSP(CN,MAG2) | |
|<-------------------------------| |
| | | |
|<------------MAGs Exchange PBU/PBA-------------->|
| | | |
Figure 6: MAG Initiated Inter-LMA Local routing
Editor's Note:
LMA-initiated Inter-LMA local routing is described in the Appendix
for future extension. In LMA-initiated Inter-LMA local routing,
the setup of a local routing path depends on LMA-LMA
communication.
8. Conceptual Data Structure Extensions
8.1. Binding Update List Extensions
Every Mobile Access Gateway maintains a Binding Update List. Each
Entry in the Binding Update List represents a mobile node's mobility
binding with its Local Mobility Anchor, as described in Section 6.1
of the PMIPv6 specification [RFC5213]. This specification extends
the Binding Update List Entry data structure with the following
additional fields:
Intra-MAG LocalRouting Flag
This flag indicates whether media delivery optimization is allowed
by locally routing packets within one MAG. The flag is set to the
value 1 if local media delivery optimization is allowed and 0 if
it is not.
Wu & Sarikaya Expires August 16, 2010 [Page 19]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
Intra-LMA LocalRouting Flag
This flag indicates whether media delivery optimization is allowed
by locally routing packets from one MAG to another within one LMA.
The flag is set to the value 1 if local media delivery
optimization is allowed and 0 if it is not.
Inter-LMA LocalRouting Flag
This flag indicates whether media delivery optimization is allowed
by locally routing packets from a MAG served by one LMA to another
MAG served by a different LMA. The flag is set to the value 1 if
local media delivery optimization is allowed and 0 if it is not.
8.2. Binding Cache Entry Extensions
Every Local Mobility Anchor MUST maintain a Binding Cache Entry for
each currently registered mobile node. To support LR, the Binding
Cache Entry data structure needs to be extended with the following
additional fields:
Intra-LMA LocalRouting Flag
This flag indicates whether media delivery optimization is allowed
by locally routing packets from one MAG to another within one LMA.
The flag is set to the value 1 if local media delivery
optimization is allowed and 0 if it is not.
Inter-LMA LocalRouting Flag
This flag indicates whether media delivery optimization is allowed
by locally routing packets from a MAG served by one LMA to another
MAG served by a different LMA. The flag is set to the value 1 if
local media delivery optimization is allowed and 0 if it is not.
8.3. Routing Table Entry Extensions
Every mobile access gateway and local mobility anchor MUST maintain a
Routing Table entry for each currently registered mobile node:
o The Home Address assigned to the Correspondent Node
o The Home Address assigned to the Mobile Node
o The tunnel interface assigned to the data path between the Mobile
Node and the Correspondent Node
Wu & Sarikaya Expires August 16, 2010 [Page 20]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
9. Local Routing Optimization Message Format
9.1. Local Routing Optimization Mobility Option
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 = TBD | Length | Reserved |LRI|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Local Routing Optimization Mobility Option
Type:
TBD
Length:
8-bit unsigned integer indicating the length of the option in
octets, excluding the Type and Length fields. This field MUST be
set to 2.
Reserved (R):
This 8-bit field is unused for now. The value MUST be initialized
to 0 by the sender and MUST be ignored by the receiver.
Local Routing Optimization Indication (LRI):
00:
Routing optimization state is unknown or routing optimization
is not available.
01:
The value of Intra-MAG LocalRouting
10:
The value of Intra-LMA LocalRouting
11:
The value of Inter-LMA LocalRouting
Wu & Sarikaya Expires August 16, 2010 [Page 21]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
9.2. The Local Routing Optimization Request (LROREQ) Message
The Local Routing Optimization Request message is used by one PMIP6
managed node (LMA or MAG) to negotiate with another PMIP6 managed
node (MAG or LMA) whether and what local routing is allowed.
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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|LRI|B| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Mobility options ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Local Routing Optimization Request Message
Sequence Number:
A monotonically increasing integer. Set by a sending node in a
request message, and used to match a reply to the request.
'R' flag:
Set to 0, this flag indicates a routing optimization request
message.
Bulk Localized Routing Flag (B):
If the Bulk Localized Routing Flag (B) is set to 1, then the
LROREQ message is a message requesting the MAG or LMA to establish
local routing optimization paths between the MN and multiple CNs
which are communicating with the MN; the MN-CNs Pair Mobility
Option will be used to carry one MN and more than one CN. If the
bulk localized routing flag is set to 0, then the LROREQ message
is a message requesting the MAG or LMA to establish a local
routing optimization path between one MN and CN.
Local Routing Optimization Indication (LRI):
00:
Routing optimization state is unknown or routing optimization
is not available
Wu & Sarikaya Expires August 16, 2010 [Page 22]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
01:
The value of Intra-MAG LocalRouting
10:
The value of Intra-LMA LocalRouting
11:
The value of Inter-LMA LocalRouting
Lifetime:
The requested period in seconds for which the sender wishes local
routing to be active.
9.3. Local Routing Optimization Response Message (LRORSP)
The Local Routing Optimization Response message is used to
acknowledge the receipt of a Local Routing optimization Request
message (described in Section 9.2).
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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|R|LRI|B| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Mobility options ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Local Routing Optimization Response Message
Sequence Number:
A monotonically increasing integer. Set by a sending node in a
request message, and used to match a reply to the request.
'R' flag:
Set to 0, indicates it is an routing optimization request message.
Set to 1, indicates it is an routing optimization response
message.
Wu & Sarikaya Expires August 16, 2010 [Page 23]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
Bulk Localized Routing Flag (B):
If the Bulk Localized Routing Flag (B) is set to 1, then the
LROREQ message is a message requesting the MAG or LMA to establish
local routing optimization paths between the MN and multiple CNs
which are communicating with the MN; the MN-CNs Pair Mobility
Option will be used to carry one MN and more than one CN. If the
bulk localized routing flag is set to 0, then the LROREQ message
is a message requesting the MAG or LMA to establish a local
routing optimization path between one MN and CN.
Local Routing Optimization Indication (LRI):
00:
Routing optimization state is unknown or routing optimization
is not available
01:
The value of Intra-MAG LocalRouting
10:
The value of Intra-LMA LocalRouting
11:
The value of Inter-LMA LocalRouting
Lifetime:
The requested period in seconds for which the sender wishes local
routing to be active.
Mobility Options:
The Local Routing Optimization Mobility Option described in
Section 9.1 and MN-CNs Pair Mobility Option described in
Section 9.4 can be included.
9.4. MN-CNs Pair Mobility Option
The MN-CNs Pair Mobility Option is defined for use with the Local
Route Optimization Request Section 9.2 and Local Route Optimization
Response Section 9.3 messages exchanged between the LMA and MAGs.
This option is used by the PMIP6 managed node to enable local routing
for MN to CNs path from the destination MAG that receives the request
Wu & Sarikaya Expires August 16, 2010 [Page 24]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
message towards CNs connected a different MAG. The addresses of the
target Correspondent Nodes are given in the option. The option MUST
be used in pairs including one MN, one or many CNs in communication
with MN. The order is important. The LMA places the data for the MN
first in the MN-CNs Pair Mobility Option.
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 | Length |P| Reserved |Prefix Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Home Network Prefix +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ Proxy CoA +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 HoA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Proxy CoA |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: MN-CNs Pair Mobility Option
P Flag:
The 'P' flag is set for IPv4 support. When set, the IPv4 HoA and
IPv4 Proxy CoA fields MUST be included for the MN or CN.
Reserved:
This 7-bit field is unused for now. The value MUST be initialized
to 0 by the sender and MUST be ignored by the receiver.
Prefix Length:
8-bit unsigned integer indicating the prefix length of the IPv6
prefix contained in the option.
Wu & Sarikaya Expires August 16, 2010 [Page 25]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
Home Network Prefix:
A sixteen-byte field containing the mobile or corresponding node's
IPv6 Home Network Prefix.
Proxy CoA:
A sixteen-byte field containing the global address configured on
the egress interface of the mobile access gateway to which the
mobile or corresponding node is connected.
IPv4 HoA:
Optional 32-bit field containing the IPv4 home address of the
mobile or corresponding node.
IPv4 Proxy CoA:
Optional 32-bit field containing the IPv4 address that is
configured on the egress-interface of the mobile access gateway.
10. Security Considerations
The protocol specified in this document can use the security
association between the LMA and the MAG to create security
associations between MAGs to which MN and CN attach in the intra-LMA
local routing scenario. As regarding the intra-MAG local routing
scenario, integrity protection can be considered and confidentiality
using IPsec is not necessary.
In the handover case, the security association between the new MAG
and a particular LMA should be pre-established when the MN arrives at
the new MAG. A particular LMA can be any LMA serving the MN or CN.
MAG initiated inter-LMA local routing may depend on the security
association between MN's new MAG and CN's LMA during handover.
In order to setup a local routing path, MN's MAG may exchange PBU/PBA
with CN's MAG. CN's MAG needs to know that the prefix extracted from
the MN-CNs Pair Mobility Option in the PBU is owned by the MN and
that the MN's MAG is actually proxying this prefix. Prefix ownership
validation may be required during PBU/BPA exchange to ensure that a
valid routing state can be created on the CN's MAG. It is the same
case when CN's MAG exchanges PBU/PBA with MN's MAG.
Wu & Sarikaya Expires August 16, 2010 [Page 26]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
11. IANA Considerations
TBD.
12. Acknowledgements
The authors would like to thank Tom Taylor, Kent Leung, Sri
Gundavelli, Jouni Korhonen, Mohana Jeyatharan, for their comments on
this draft. Speically thanks to Glen Zorn for providing useful
reviews.
13. References
13.1. Normative References
[I-D.ietf-mipshop-pfmipv6]
Yokota, H., Chowdhury, K., Koodli, R., Patil, B., and F.
Xia, "Fast Handovers for Proxy Mobile IPv6",
draft-ietf-mipshop-pfmipv6-12 (work in progress),
December 2009.
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17
(work in progress), September 2009.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
13.2. Informative 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.
Wu & Sarikaya Expires August 16, 2010 [Page 27]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
[I-D.wu-dime-pmip6-lr]
Wu, W. and G. Zorn, "AAA Support for PMIP6 mobility
entities Locating and Discovery during localized routing",
draft-wu-dime-pmip6-lr-01 (work in progress),
October 2009.
Appendix A. Future Extension
A.1. LMA Route Optimization Start Message
A.1.1. LMA Route Optimization Start Request Message
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.1.1. LMA Route Optimization Start Request Message
A new MH type should be assigned by IANA.
Sequence Number
16-bit unsigned integer. The LMA uses this field to match a
returned LMAROStartRsp message. The LMA also uses this field to
identify each new pairs of MN-CN to start local routing if the LMA
received LMAStartRORsp message.
Reserved
This field is unused. It SHOULD be initialized to zero by the
sender and MUST be ignored by the receiver.
Lifetime
16-bit unsigned integer. If non-zero, this fields indicates the
initial lifetime of the MN to CN route optimization binding. If
there are several MN-CN pairs, the same lifetime applies to each
pair.
Wu & Sarikaya Expires August 16, 2010 [Page 28]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
Mobility Options
As defined in section 6.1.7 of RFC 3775 [RFC3775].
This document defines a new mobility option: MN-CN RO option in
Section 9.4. The sending LMA sends a pair of MN-RO Options. LMA
sets Home Network Prefix value of the first MN-RO Option to HNP for
MN and Proxy-CoA value to Proxy-CoA1. The LMA sets Home Network
Prefix value of the second MN-RO Option to HNP of CN and Proxy-CoA
value to zero.
A.1.2. LMA Route Optimization Start Response Message
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A.1.2. LMA Route Optimization Start Response Message
A new MH type should be assigned by IANA.
Status An 8-bit unsigned integer indicating the disposition of
LMAROStartReq message by the receiving LMA. Values less than 128
indicate that ROStartReq message was accepted by the LMA. Values
greater than 128 indicate that LMAROStartReq message was rejected
by LMA.
Sequence number and Lifetime fields are as defined above for
LMAROStartReq message.
Mobility Options contain pairs of MN-CN RO Option as defined in
Section 9.4. The LMA must copy this field from LMAROStartReq
message when status field contains a value indicating success.
The LMA MUST search its binding cache for the Home Network Prefix
value of CN and find the corresponding MAG address, e.g. Proxy-
CoA2. Th LMA MUST replace MAG address field set to zero by the
sending LMA with Proxy- CoA2.
Wu & Sarikaya Expires August 16, 2010 [Page 29]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
A.2. LMA Initiated Inter-LMA Local Routing
The message exchange for the protocol is shown in Figure A.2. Inter-
LMA Local routing is triggered at one of the LMAs, e.g. LMA1 when a
datagram is received on its upstream interface whose destination
address is a MN, e.g. MN1 for which LMA1 has a binding cache entry.
From the binding cache entry, LMA1 determines the MAG address, e.g.
MAG1 (Proxy-CoA1). LMA1 checks the source address to find out if the
datagram is coming from a MN located in the same Provider domain and
if yes, its MAG address, e.g. MAG2 (Proxy-CoA2). There are several
ways for doing this and the exact means is out of scope with the
document. Below we will mention two different ways.
(a) LMAs in the same Provider domain are configured with a table
containing a list of /48, /32, etc. prefixes and the
corresponding LMA address for all the LMAs in the domain. LMA1
searches this table doing a longest prefix match based on the
prefix part of the source address of MN2 and finds the
corresponding LMA2 address.
(b) LMA1 can exchange with the AAA server to retrieve LMA2 address.
LMA1 sends MN2 address and asks LMA address this MN is attached
to. LMA1 receives LMA2 address and MAG address (Proxy-CoA2)
from AAA server, e.g.DIAMETER server.
LMA1 sends LMAROStartRequest message to LMA2. LMAROStartRequest
message contains MN1 and MN2 address and MAG1 address (Proxy-CoA1).
MAG2 address is set to zero. LMA2 searches its BCE for MN2 and
determines MAG2 address (Proxy-CoA2). LMA2 sends LMAROStartResponse
message to LMA1. LMAROStartResponse message contains MN1 and MN2
address and MAG1 address (Proxy-CoA1) and MAG2 address (Proxy-CoA2).
LMA1 sends LROREQ message to MAG1 at Proxy-CoA1. LROREQ message
contains MN address and Proxy- CoA1 and CN address, e.g. MN2 and
Proxy-CoA2. LMA2 sends LROREQ message to MAG2 at Proxy-CoA2. LROREQ
message contains CN address, e.g. MN2 and Proxy-CoA2 and MN address,
e.g. MN1 and Proxy-CoA1. LROREQ messages enable both MAGs to modify
their Binding Update Lists. The two MAGs respond LROREQ with LRORSP
messages.
The two MAGs, MAG1 and MAG2 exchange PBU/PBAs as described in
Section 4.
Wu & Sarikaya Expires August 16, 2010 [Page 30]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
+------+ +----------+ +---------+ +------+
| MAG1 | | LMA1(MN) | |LMA2(CN) | | MAG2 |
+---+--+ +----+-----+ +----+----+ +---+--+
| | | |
| | LMAROStartReq | |
| |-------------->| |
| | | |
| | LMARoStartRsp | |
| |<------------- | |
| LROREQ | | LROREQ |
|<---------------| |--------------->|
| | | |
| LRORSP | | LRORSP |
|--------------->| |<-------------- |
| | | |
|<--------------MAGs exchange PBU/PBA------------>|
| | | |
| | | |
Figure A.2. LMA Initiated Inter-LMA Local routing
A.2.1. IPv4 Support Consideration
IPv4 support presented in Section 6 also applies here. In addition,
we discuss IPv4 support issues related to LMAROStartRequest and
LMAStartResponse messages. LMAROStartRequest and LMAStartResponse
messages are IPv6 messages. These messages are transported in IPv6
because LMAs support IPv6 and there is IPv6 transport established
among LMAs in the same Provider domain.
A.3. LMA Initiated operation for Inter-LMA Local Routing
Local mobility anchor MUST send LMAROStartReq message to another
local mobility anchor in the same Provider domain. LMAROStartReq
message MUST contain at least one pair of MN-CN RO Option. Local
mobility anchor MUST place the mobile node address information which
is connected to this local mobility anchor first in MN-CN RO Option.
Local mobility anchor MAY set lifetime field in LMAROStartReq message
to a non zero value. Any nonzero lifetime value enables the
receiving local mobility anchor to start local routing optimization
for MN-CN traffic by sending LROReq message to the mobility access
gateway to which CN is connected as the local mobility anchor
determines by searching its binding cache.
After receiving LRORes from the mobile access gateway, the local
mobility anchor MUST send LMAROStartRes to the originating local
mobility anchor. LMAROStartRes MUST contain MN-CN Option RO pair in
Wu & Sarikaya Expires August 16, 2010 [Page 31]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
which the first contains MN and its mobility access gateway address
info which is copied from LMAROStartReq message and the second
contains CN address which is copies from LMAROStartReq and its
mobility access gateway address which this local mobility gateway
provides.
Local mobility anchor MAY set lifetime field in LMAROStartRes to the
same value as LMAROStartReq lifetime field value. Local mobility
anchor MAY set lifetime field in LMAROStartRes to a different value.
The lifetime field in LMAROStartRes becomes the final value and local
mobility anchor MUST set lifetime value in LROReq message that it
sends to MN's mobility access gateway.
In case the simplified route optimization involves two local mobility
gateways, the initiating local mobility anchor MAY stop the route
optimization any time it wishes. The initiating local mobility
anchor MUST send LMAROStartReq message to the destination local
mobility anchor with lifetime field set to zero. The destination
local mobility anchor sends LMAROStartRes with lifetime set to zero.
Both local mobility anchors send LROReq messages to the corresponding
mobility access gateways with lifetime set to zero. Both local
mobility anchors reestablish the tunnel with mobility access gateways
for MN and CN, respectively.
Local mobility anchor sets the sequence number field in LMAROStartReq
message to a nonzero integer. This initial sequence number is
incremented by one for the next LMAROStartReq message sent. Local
mobility anchor MUST receive LMAROStartRes message with the same
sequence number as in LMAROStartReq message previously sent. This
message acknowledges LMAROStartReq message. If no ack is received
local mobility anchor MUST retransmit LMAROStartReq message. In a
normal mode of operation local mobility anchor has one outstanding
LMAROStartReq messages because they are sent to the other local
mobility anchor in the same Provider domain.
Appendix B. Change Notes
Changes in version 04.
o Move LMA Initiated inter-LMA local routing to appendix A
o Some Editorial Revision.
o Additional text about MAG operation and LMA operation in section 5
and appendix A.3.
Wu & Sarikaya Expires August 16, 2010 [Page 32]
Internet-Draft PMIPv6 Local Routing Optimization February 2010
o Remove NAT Aspect and private IPv4 aspect in this document.
o Additional text about Routing Table extension and Bulk localized
routing Flag.
Changes in version 05.
o Some Editorial changes.
o Consistent with I-D.ietf-netext-pmip6-lr-ps on terminology using
o Incorporate prefix ownsership validation into the section of
"security consideration".
Authors' Addresses
Qin Wu
Huawei Technologies Co.,Ltd
Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd.
Nanjing, Jiangsu 21001
China
Phone: +86-25-84565892
Email: Sunseawq@huawei.com
Behcet Sarikaya
Huawei Technologies Co.,Ltd
1700 Alma Drive, Suite 500
Plano, TX 75075
USA
Email: sarikaya@ieee.org
Wu & Sarikaya Expires August 16, 2010 [Page 33]