One document matched: draft-wu-netext-local-ro-04.txt
Differences from draft-wu-netext-local-ro-03.txt
Network Working Group Q.Wu
B.Sarikaya
Internet Draft Huawei
Intended status: Standard Track October 26, 2009
Expires: April 2010
Proxy MIP extension for local routing optimization
draft-wu-netext-local-ro-04.txt
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 April 26, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Wu,et al. Expires April 26, 2010 [Page 1]
Internet-Draft Proxy MIP Extension for local routing October 2009
Abstract
This document extends local routing in proxy Mobile IPv6 and defines
a localized routing optimization protocol within one PMIPv6 domain.
The protocol supports IPv4 transport network operation, IPv4 home
address mobility and handover. The Local mobility anchor/mobile
access gateway initiates local routing for the mobile and
correspondent node by sending messages to each mobile access
gateway/local mobility anchor. In case the correspondent node is
connected to another local mobility anchor, the local mobility
anchors connected by the correspondent node needs to be discovered
firstly so that it can notify its mobile access gateways attached by
the correspondent node to the mobile access gateway attached by the
mobile node afterwards. Mobile access gateways create and refresh bindings
using proxy binding update and acknowledgement messages.
Table of Contents
1. Introduction.................................................3
2. Conventions used in this document............................4
3. Scenarios analysis for PMIP6 local routing...................5
4. Local routing optimization protocol overview.................6
4.1. MAG initiated local routing optimization................6
4.1.1. Handover Consideration.............................8
4.2. LMA initiated local routing optimization................9
4.2.1. Handover Consideration............................10
5. Process consideration.......................................11
5.1. Mobile Access Gateway Consideration....................11
5.2. Local Mobility Anchor Consideration....................15
6. IPv4 support................................................16
6.1. IPv4 HoA support.......................................16
6.2. IPv4 transport support.................................17
7. Inter-LMA Local routing Consideration.......................17
7.1. MAG Initiated Inter-LMA local routing..................17
8. Conceptual Data Structure Extension.........................18
8.1. Binding Update List Extension..........................18
8.2. Binding Cache Entry Extension..........................19
8.3. Routing Table Entry Extension..........................19
9. Local routing optimization message format...................19
9.1. Local Routing optimization mobility option.............19
9.2. Local Routing optimization Request message(LROREQ).....20
9.3. Local Routing optimization Response Message(LRORSP)....21
9.4. Context Request Option.................................23
Wu,et al. Expires April 26, 2010 [Page 2]
Internet-Draft Proxy MIP Extension for local routing October 2009
9.5. MN-CNs pair mobility option...........................23
10. Security Considerations...................................24
11. IANA Considerations.......................................24
12. Acknowledgement...........................................25
13. References................................................25
13.1. Normative References.................................25
13.2. Informative References...............................25
Appendix A Future Extension..................................26
A.1. LMA Route Optimization Start Message.....................26
A.1.1 LMA Route Optimization Start Request Message.........26
A.1.2. LMA Route Optimization Start Response Message.......27
A.2. LMA Initiated Inter-LMA Local Routing....................27
A.2.1 IPv4 Support Consideration...........................29
A.3. LMA Initiated operation for Inter-LMA Local Routing...30
Appendix B Change Notes......................................31
1. Introduction
Proxy Mobile IPv6 [RFC5213] can allow the Mobility Access Gateway
(MAG) to optimize the media delivery by locally routing the packets
within one MAG and by not reverse tunneling them to the mobile node's
local mobility anchor (LMA). However it does not address the case of
routing optimization between two MAGs sharing the same LMA or
registering to the different LMA. The capability for local routing
optimization provided in [RFC5213] requires the MAG to support the
EnableMAGLocalRouting flag and allow the MAG to control local routing
optimization behavior. However, [RFC5213] does not define how local
routing optimization capability is detected, who initiates local
routing optimization and how to negotiate between the MAG and the LMA
to determine whether the local routing optimization is allowed.
This document defines a local routing optimization mobility messages
or options for proxy mobile ipv6 that is intended to assist the MAGs
to negotiate and setup local routing path between each other. The new
local routing optimization mobility options included in each binding
update or local routing optimization messages exchange is used to
negotiate between the LMA and the MAG whether and what local routing
is allowed. Different from the local forwarding control message
described in the [I-D.LocalFwd], the local routing optimization
messages can be initiated by either of pmip6 managed node and provide
flexible negotiation mechanism for local routing. As [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 PMIPv6 domain.
Wu,et al. Expires April 26, 2010 [Page 3]
Internet-Draft Proxy MIP Extension for local routing October 2009
2. Conventions used in this document
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.
The document uses the terminology specified in [RFC5213] and in
[RFC3775]. In addition, this document defines the following:
Local routing: Traffic between MN and CN does not pass through LMA
and is locally routed in the same PMIPv6 domain.
Local Routing Optimization Request (LROREQ): A message initiated by
the MAG or LMA requesting the MAG or LMA to establish local routing
optimization path between MN and at least one pair of CNs who
communicate with MN.
Local Routing Optimization Response (LRORSP): A reply message from
the MAG or LMA to confirm local routing optimization results.
Wu,et al. Expires April 26, 2010 [Page 4]
Internet-Draft Proxy MIP Extension for local routing October 2009
3. Scenarios analysis for PMIP6 local routing
Figure 1 shows the reference architecture for PMIP6 local routing. In
this architecture, the local communication between PMIPv6 managed
nodes(i.e., MAGs) is constrained within a single PMIPv6 domain. LMA1
and LMA2 which MN and CN are respectively anchored to may be the same
LMA or different LMAs in the same PMIPv6 domain.
+---------+
============|LMA1/LMA2|============
// +---------+ \\
|| ||
|| ||
|| +-----------+
+-----------+ | IPv4/IPv6 |
| IPv4 | | 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
Depending on how MN and CN are distributed into one PMIP6 domain,
three typical scenarios need to be considered as follows:
Scenario 1: Intra-MAG local routing
In this scenario, MN and CN attach to the same MAG and are anchored
with the same LMA or different LMAs.
Scenario 2: Intra-LMA local routing
In this scenario, MN and CN attach to the different MAGs and are
anchored with the same LMA.
Scenario 3: Inter-LMA local routing
Wu,et al. Expires April 26, 2010 [Page 5]
Internet-Draft Proxy MIP Extension for local routing October 2009
In this scenario, MN and CN attach to the different MAGs and are
anchored with the different LMAs.
In all the above scenarios, MN is allowed to roam within its PMIPv6
domain (i.e, MN's home domain in which MN's LMA is located) or move
from one PMIPv6 domains(i.e., MN's visited domains)to another. CN
should stay with MN within the same PMIPv6 domain, e.g., MN moves to
the visited domain to which CN belongs. Another example is 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 assumes that
o the MAGs are situated in one PMIP 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 attach 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 MN and CN are
attach belong to the same or different LMAs).
The flag EnableDetectLocalRouting on the MAG and LMA may be used to
control this behavior. The decision to enable/disable detection of
local routing should be based on the policy configured on the MAG or
LMA. The specific details on how this is achieved are beyond of the
scope of this document. Subsequently depend on who initiate local
routing, the local routing optimization can be categorized into two
aspects.
4.1. MAG initiated local routing optimization
When the EnableDetectLocalRouting is enabled in the MAG, the MAG can
start to detect whether the MN and CN attach to the same MAG by
checking binding update List of MN and CN.
Upon the MAG receives the packet from MN or CN and perceives MN and
CN attach to the same MAG, it can initiate local routing optimization
to determine the value of the intra-MAG local routing flag (defined
in section 8) by message exchange between the MAG and LMA (If the MAG
attached by the MN and CN register to the different LMAs, it needs to
initiate local routing optimization to the different LMAs
Wu,et al. Expires April 26, 2010 [Page 6]
Internet-Draft Proxy MIP Extension for local routing October 2009
respectively). When the MAG detect that MN and CN don't attach to the
same MAG but want to check whether intra-LMA routing is allowed(i.e.,
MN and CN attach to different MAGs and register to the same LMA), it
also can initiate the local routing optimization by sending message
to the LMA. The message may be a binding update message which
contains the local routing optimization mobility option and home
network prefix option for the correspondent node or a newly defined
local routing optimization message. It will be used to negotiate with
LMA to determine whether or what the local routing optimization
between the mobile node and correspondent node is supported. The AAA
server can be used to authorize the use of localized routing service
for MN. If the AAA sever does not authorize the use of localized
routing service or the LMA does not allow the MAG bypass traffic from
itself, LMA will respond to the MAG that the local routing
optimization is not available. Otherwise LMA will set the intra-MAG
localrouting or intra-LMA localrouting flag on the MAG into value one
in the successful response message.
After successful local routing optimization process, if MN and CN
attach to the different MAGs, i.e., MAG1, MAG2 and intra-LMA
localrouting flag is set to value one, the MAG1 to which the MN
attaches may send PBU message to the MAG2 which the CN attaches to.
The PBU/PBA signaling is protected using IPsec Encapsulation security
payload [RFC4303] in transport mode with mandatory integrity
protection. This PBU message sets the lifetime of the binding of MN
at MAG2. Similarly if intra-LMA localrouting flag is set to value one
on the MAG2, the MAG2 sends PBU message to the MAG1. This PBU message
sets the lifetime of the binding of CN at MAG1. Each PBU MUST be
acknowledged with PBAs. With PBU/PBA exchange, the local data path
between MAGs is established and the binding caches associated with MN
and CN are set up. Also PBU-PBA exchange is repeated to extend the
lifetime of the binding.
For the data traffic, either of the MAGs can lookup the routing table
entry associated with MN or CN and identify the tunnel to the right
MAG in terms of destination address of outgoing data packet. If MN
and CN attach to the same MAG, the traffic from MN will go directly
to CN via the MAG. If MN and CN attaches to the different MAG and
register to the same LMA, the traffic from MN will be forwarded
directly by the MAG associated with MN to the MAG associated with the
CN.
Wu,et al. Expires April 26, 2010 [Page 7]
Internet-Draft Proxy MIP Extension for local routing October 2009
+--+ +------+ +-----+ +------+ +--+
|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 Consideration
In case of handover when the MN moves from the old MAG (e.g., pMAG1)
in the previous access network to the new MAG(e.g., nMAG1) in the new
access network, registration entry for MN in pMAG1's Binding update
list should be transferred to the nMAG1. The context request option
defined in the [I-D.ietf-mipshop-pfmipv6] can be reused to carry the
context information on pMAG1 to nMAG1. And the new MAG(i.e., nMAG1)
sends PBUs to each MAG with which MN was in communication via local
route optimization path established. This PBU/PBA exchange updates
the binding in each MAG with which MN was in communication and re-
establishes optimal local route path between MN and its CNs.
Wu,et al. Expires April 26, 2010 [Page 8]
Internet-Draft Proxy MIP Extension for local routing October 2009
+-----+ +---------+ +---------+
|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 EnableDetectLocalRouting is enabled in the LMA, the LMA can
start to detect whether the MN and CN register to the same LMA by
checking binding List of MN and CN. Upon receiving the packet from
the MN or CN and perceiving MN and CN register to the same LMA, it
may correlate MN with CN in one the routing table entry associated
with MN and initiate local routing optimization to determine the
value of Intra-LMA localrouting flag (defined in section 8)at MAG,
i.e., notify or enforce the value of intra-LMA flag to the MAG
associated with MN by message exchange between the MAG and LMA. The
message could be proxy binding update message which contains local
routing optimization mobility option or a newly defined routing
optimization message. It will be used to help LMA to determine
whether or not the local routing optimization is allowed and enforce
the local optimization on the MAG. The AAA server serving LMA can be
used to authorize the use of localized routing service for MN. If the
AAA sever does not authorize the use of localized routing service or
If the LMA verifies there exists binding cache list of correspondent
node and mobile node and allow the MAG bypass traffic between mobile
node and correspondent node from itself, it will notify the MAG to
set the intra-LMA Localrouting flag into value one, otherwise, it
will respond to MAG with failure information which indicates the
intra-LMA routing optimization is not supported. The other procedures
are same as that of section 4.1.
Wu,et al. Expires April 26, 2010 [Page 9]
Internet-Draft Proxy MIP Extension for local routing October 2009
+--+ +------+ +-----+ +------+ +--+
|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 Consideration
In case of handover when the MN moves from the old MAG (e.g., pMAG1)
in the previous access network to the new MAG(e.g., nMAG1) in the new
access network, MAG1 may update the binding cache entry associated
with MN at the LMA by sending normal PBU. At the same time, LMA may
refresh routing table entries associated with MN as well and update
binding of each MAG with which MN was in communication via local
route optimization path established by sending LROREQ to each MAG.
Also MAG1 can use the similar procedure described in the section
4.1.1 to transfer MN's registration entry at pMAG1 to the new MAG
(i.e., nMAG1).
Wu,et al. Expires April 26, 2010 [Page 10]
Internet-Draft Proxy MIP Extension for local routing October 2009
+-----+ +---------+ +----------+ +---------+
|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. Process consideration
5.1. Mobile Access Gateway Consideration
The MAG may include the routing optimization mobility option and MN-
CNs pair mobility option into binding update message or create a new
routing optimization request message in which the above two options
are contained. The routing optimization mobility option is used to
negotiate which kind of local routing optimization is available. The
MN-CNs pair mobility option is used for the LMA to verify the
validity of local routing optimization path end points (in the intra-
MAG local routing scenario) or to request the LMA to determine proxy
CoA-Address of correspondent node for local routing optimization (in
the intra-LMA local routing scenario). In the intra-MAG local routing
case, LRI field in routing optimization mobility option is set into
value 1 while in the intra-LMA local routing case, LRI field in
routing optimization mobility option is set into value 0, because
mobile node's MAG does not know whether traffic between MN and CN can
be locally routed within one LMA.
When the MAG receives binding acknowledge message with routing
optimization mobility option or routing optimization response
message, it will check Mobile access gateway check all fields
validity in the response/acknowledge message including whether the
Wu,et al. Expires April 26, 2010 [Page 11]
Internet-Draft Proxy MIP Extension for local routing October 2009
sequence number value in acknowledge/response message is identical
to the sequence number value in request message, whether MN-CN pairs
mobility option is included in the response/acknowledge message. In
successful case, MAG then will extract the LRI field from the
routing optimization mobility option or routing optimization
response message and check the value of it. If LRI field is 0, it
indicates the LMA does not support this local routing optimization
and the MAG should set intra-MAG LocalRouting flag to value 0 in the
binding update list extension; if LRI field is 1, it indicates the
LMA allow local routing in one MAG and bypass the LMA and MAG should
set intra-MAG LocalRouting flag to value 1 in the binding update
list extension, if LRI field is 2, it indicates LMA has found
correspondent node's MAG address in terms of home network prefix of
CN and MAG should extract correspondent node's MAG address from
initial binding acknowledge message or routing optimization response
message and store it in binding update list extension with
correspondent node's home network prefix.
When MAG receives LROReq message from the LMA for each MN-CN RO
Option pair it searches the binding update list for a matching IPv6
home network prefix in the list of prefixes it stores for each
mobile node that MAG is serving. If a match is found, 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 CN part of MN-
CN pairs mobility Option found in LROReq message. MAG MUST send PBU
message to the MAG of each correspondent node if LROReq message
contains more than one CN in the MN-CN pairs 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
existing entry that was created during the initial PBU procedure.
O The IPv6 address of the LMA serving the attached mobile node is
replaced with Proxy-CoA of the MAG to which the PBU was sent and
Proxy-CoA field in correspondent node part of MN-CN RO Option is
copied to this field. IP address of the correspondent node to
which MN is communicating with is set to Home Network Prefix
Wu,et al. Expires April 26, 2010 [Page 12]
Internet-Draft Proxy MIP Extension for local routing October 2009
field of the correspondentnode part of MN-CN pair mobility Option.
If P bit is set in MN-CN pairs mobility Option, this field is set
to IPv4 HoA field of the correspondent node part of MN-CN pairs
mobility Option.
O The initial value of binding lifetime field is set to the
lifetime field of 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.
Upon the intra-MAG Localrouting flag or intra-LMA Localrouting flag
setup at the MAGs, one MAG may send the proxy binding update message
to another MAG to establish corresponding binding cache associated
with the MN and CN. Upon receiving Proxy Binding Update message, the
MAG checks if the LocalRouting flag is set to one. If the
LocalRouting flag is not set to 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 Proxy Binding Update request, the MAG MUST create a
Binding Cache entry. The Source address of Proxy Binding Update is
copied to 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 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 this mobile
access gateway and the Proxy-CoA of the mobile access gateway that
sent Proxy Binding Update as can be obtained from the source address
of Proxy Binding Update. This tunnel should be deleted when there
are no mobile nodes sharing it or when mobile access gateway receives
RORQ message from local mobility anchor with lifetime set to zero.
Wu,et al. Expires April 26, 2010 [Page 13]
Internet-Draft Proxy MIP Extension for local routing October 2009
In case of handover or detachment, if the mobile access gateway
cannot predictably detect the presence of the mobile node on the
connected link, the MAG SHOULD terminate the binding of the mobile
node by sending a PBU message to all CN's MAGs that has established
bindings. 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. MAG MUST also remove each Binding Update List entry
created for that MN.
In order to re-establish bindings of the MN that is involved in local
routing, i.e. with binding update list entries other than the home
(local mobility anchor registration) the previous MAG MAY use 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 each MAG (Proxy-CoA or IPv4-Proxy-CoA)
associated with each correspondent node.
For the data traffic between the MN and CN, on receiving a packet
from a mobile node 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 destined MAG. If the source address and
destination address in the packet match one of source/destination
addresses pair 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.
Wu,et al. Expires April 26, 2010 [Page 14]
Internet-Draft Proxy MIP Extension for local routing October 2009
5.2. Local Mobility Anchor Consideration
For the case where the MAG initiates local routing, upon receiving
binding update message or routing optimization request message, the
LMA will check LRI field in the routing optimization mobility option
or routing optimization message. If LRI field is set to value one,
the LMA will check whether there exist binding cache list for CN and
whether MN's proxy CoA address is same as CN's proxy CoA address. If
LRI field is 0 and correspondent node's home network prefix included,
the LMA will check whether there exists binding cache list for CN in
terms of the correspondent node's home network prefix. If does, the
LMA will respond to the MAG with LRI field set to value 2. Otherwise,
the LMA will respond to the MAG with LRI field set to 0 in the
routing optimization mobility option to indicate the MAG that the
local routing optimization is not available. For the case where the
LMA initiates local routing, LMA may be responsible for perceiving
intra-LMA routing and correlate MN with CN in the routing table entry.
Upon perceiving intra-LMA routing, the LMA sends routing optimization
request message with the LRI field set to value 2. And then the LMA
receives routing optimization reply message from the corresponding
MAG.
LMA MUST send LROReq message to either or both of MAGs where MN and
CN are located. If CN (or MN) is not connected to this LMA, the
LROReq message MUST be sent to only one MAG. The LROReq message MUST
contain at least one pair of MN-CN pairs mobility Option.If MN is
communicating with more than one CN which registers to the same LMA,
LMA MUST include more than CNs in the MN-CN pairs mobility Option if
localized routing will be enabled.
When LROReq is sent to a MAG, LMA MUST place the MN address
information which is connected to this MAG first in MN-CN pairs
mobility Option.
LMA MAY set lifetime field in LROReq message to a non zero value.
Any nonzero 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.
LMA MAY stop the local routing optimization operation any time it
wishes. In that case LMA MUST set lifetime field in LROReq message
to zero. After receiving LRORes message from MAG with matching
sequence number field, the LMA-MAG tunnel is re-established
separately for each MAG.
Wu,et al. Expires April 26, 2010 [Page 15]
Internet-Draft Proxy MIP Extension for local routing October 2009
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. LMA MUST receive LRORes message with the
same sequence number as in LROReq message previously sent. This
message is acknowledged with LROReq message. If no ack is received
LMA MUST retransmit LROReq message.
6. IPv4 support
IPv4 support is needed in two cases:
O MN is IPv4 enabled and receives 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.draft-netlmm-pmip6-ipv4-support] are transparent to the MAG
concerned before setting up the localized routing path. This may
result in data packets are dropped by the egress/ingress tunnel end
point, i.e., the MAGs.
Therefore local route optimization can be supported only if the
encapsulated mode is aware during setting up the localized routing
path.
6.1. IPv4 HoA support
In case MN is IPv4 enabled and receives IPv4 home address, both the
MN and the CN configure global IPv4 home addresses by exchanging
PBU/PBA as explained in [I-D.ietf-netlmm-pmip6-ipv4-support] with
the LMA.
The LMA MUST include IPv4 IPv4-MN-HoA in local routing optimization
messages for both MN and CN. The LMA MAY include Home Network Prefix
in PBA if the MN or CN is assigned Home Network Prefix. Both local
routing optimization request and local routing optimization response
messages are IPv6 messages and are transported over LMA-MAG tunnel
as PBU and PBA are transported.
The PBU and PBA exchanged between the MAGs are IPv6 messages and are
transported as unencapsulated IPv6 messages between MAGs. Various
encapsulation modes described in the [I-D.ietf-netlmm-pmip6-ipv4-
support] can be used in PBU and PBA and encapsulation mode
negotiation between the MAGs is required If the MAGs in
communication support different encapsulation mode. For
Wu,et al. Expires April 26, 2010 [Page 16]
Internet-Draft Proxy MIP Extension for local routing October 2009
simplification, we can assume the MAGs in communication are using
the default encapsulation mode. Data traffic between the MAGs after
local routing is established are transported in IPv6 inner packet as
IPv4 payload.
6.2. IPv4 transport support
In case IPv4 transport is used between the MAG and the LMA, 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 routing optimization protocol.
IPv4 data packets are transported in an IPv4 packet or encapsulated
in IPv4-UDP-ESP encapsulation.
7. Inter-LMA Local routing Consideration
In this section we concentrate on the local routing case where MN
and CN are served by two different LMAs, in the same PMIPv6 domain
which is not covered by the section 4.
7.1. MAG Initiated Inter-LMA local routing
The message exchange for the protocol is shown in Figure 6.
Local routing case 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
request LMA2 address from LMA1 by sending LROREQ message contain CN
HNP or HoA to LMA1. LMA1 processes LROREQ message and lookup LMA2
address based on CN HNP or HoA. There are one possible ways to
achieve this goal.
a. MAG1 can exchange with AAA server to retrieve LMA2 address.
MAG1 sends CN address and asks the address of LMA2 which CN is
anchored to. The AAA server responds LMA2 address to MAG1.
Upon retrieving LMA2 address, MAG1 then sends LROREQ message
containing MN-CN pairs defined in the section 9.5 to LMA2. LMA2
process LROREQ message and looks up MAG2 address based on CN HNP or
HoA extracted from the corresponding message.
In successful case, LMA2 responds to the MAG1 with MAG2 address
corresponding to CN.
MAG1 and MAG2 exchange PBU/PBA to establish binding cache list
between each other and direct path between MAG1 and MAG2 will be
setup.
Wu,et al. Expires April 26, 2010 [Page 17]
Internet-Draft Proxy MIP Extension for local routing October 2009
+------+ +----------+ +---------+ +------+
| MAG1 | | LMA1(MN) | | LMA2(CN)| | MAG2 |
+---+--+ +----+-----+ +----+----+ +---+--+
| | | |
+----+----+ | | |
| LMA2 | | | |
|Discovery| | | |
+----+----+ | | |
| LROREQ(MN,MAG1,CN) | |
|------------------------------->| |
| LRORSP(CN,MAG2) | |
|<-------------------------------| |
| | | |
|<------------MAGs Exchange PBU/PBA-------------->|
| | | |
Figure 6: MAG Initiated Inter-LMA Local routing
Editor Notes: LMA initiated Inter-LMA local routing is described in
the Appendix A for future extension. In the LMA initiated Inter-LMA
local routing, LMA-LMA communication is required to setup local
routing path.
8. Conceptual Data Structure Extension
8.1. Binding Update List Extension
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:
O Intra-MAG LocalRouting Flag indicating whether the media delivery
optimization is allowed by locally routing the packets within one
MAG. The flag is set to value 1 for local media delivery
optimization is allowed and vice versa.
O Intra-LMA LocalRouting Flag indicating whether the media delivery
optimization is allowed by locally routing the packets from one
MAG to another within one LMA. The flag is set to value 1 for
local media delivery optimization is allowed and vice versa.
O Inter-LMA LocalRouting Flag indicating whether the media delivery
optimization is allowed by locally routing the packets from one
MAG served by one LMA to another MAG served by the different LMA.
Wu,et al. Expires April 26, 2010 [Page 18]
Internet-Draft Proxy MIP Extension for local routing October 2009
The flag is set to value 1 for local media delivery optimization
is allowed and vice versa.
8.2. Binding Cache Entry Extension
Every local mobility anchor MUST maintain a Binding Cache entry for
each currently registered mobile node. For supporting this
specification, the Binding Cache Entry data structure needs to be
extended with the following additional field:
O Intra-LMA LocalRouting Flag indicating whether the media delivery
optimization is allowed by locally routing the packets from one
MAG to another within one LMA. The flag is set to value 1 for
local media delivery optimization is allowed and vice versa.
O Inter-LMA LocalRouting Flag indicating whether the media delivery
optimization is allowed by locally routing the packets from one
MAG served by one LMA to another MAG served by the different LMA.
The flag is set to value 1 for local media delivery optimization
is allowed and vice versa.
8.3. Routing Table Entry Extension
Every mobile access gateway and local mobility anchor MUST maintain a
Routing Table entry for each currently registered mobile node.
O Home Address assigned to correspondent node
O Home Address assigned to mobile node
O Tunnel interface assigned to the data path between mobile node and
correspondent node
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
Wu,et al. Expires April 26, 2010 [Page 19]
Internet-Draft Proxy MIP Extension for local routing October 2009
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
9.2. Local Routing optimization Request message(LROREQ)
The Local Routing optimization Request message is used by one PMIP6
managed node (e.g., LMA or MAG) to negotiate with another PMIP6
managed node(e.g., 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.
Wu,et al. Expires April 26, 2010 [Page 20]
Internet-Draft Proxy MIP Extension for local routing October 2009
'R' flag: Set to 0, indicates it is an 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 MN and more than one CNs who
communicate with MN and 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 local routing optimization path between one MN
and one 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 local routing
Lifetime: The requested time in seconds for which the sender wishes
to have local routing.
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.
Wu,et al. Expires April 26, 2010 [Page 21]
Internet-Draft Proxy MIP Extension for local routing October 2009
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|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.
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 MN and more than one CNs who
communicate with MN and 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 local routing optimization path between one MN
and one 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 time in seconds for which the sender wishes
to have local routing.
Wu,et al. Expires April 26, 2010 [Page 22]
Internet-Draft Proxy MIP Extension for local routing October 2009
Mobility options: local Routing optimization mobility option
described in section 9.1 and MN-CN pair mobility option described in
section 9.4 can be included.
9.4. Context Request Option
The details is defined in the section 6.2.1 of [I-D.ietf-mipshop-
pfmipv6].
9.5. MN-CNs pair mobility option
A new option, MN-CNs pair mobility option is defined for use with
the local Route Optimization Request and local Response messages
exchanged between LMA and MAGs. This option is used by the PMIP6
managed node to enable local routing for MN - CNs path from MN
connected MAG towards CNs connected a different MAG whose addresses
are given in 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 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-CN pair mobility option
P Flag
Wu,et al. Expires April 26, 2010 [Page 23]
Internet-Draft Proxy MIP Extension for local routing October 2009
P flag is set for IPv4 support. When set IPv4 HoA and IPv4 Proxy
CoA fields must be included for 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.
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 IPv4 home address of the mobile or
corresponding node.
IPv4 Proxy CoA
Optional 32-bit field containing 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
association between MAGs to which MN and CN attach in the intra-LMA
local routing scenario. As regarding intra-MAG local routing
scenario, integrity protection can be considered and confidentiality
using IPsec is not necessary.
11. IANA Considerations
TBD.
Wu,et al. Expires April 26, 2010 [Page 24]
Internet-Draft Proxy MIP Extension for local routing October 2009
12. Acknowledgement
The authors would like to thank Tom Taylor, Kent Leung, Sri
Gundavelli, Jouni Korhonen for their review and comments of this
draft and all colleagues who have supported the advancement of this
draft effort.
13. References
13.1. Normative References
[RFC3775] Johnson, D. and al. et, "Mobility Support in IPv6", RFC3775,
June 2004
[RFC5213] Gundavelli, S. and al. et, "Proxy Mobile IPv6", RFC5213,
May 2008.
[RFC4303] Kent,S.,"IP Encapsulation Security Payload(ESP)",RFC4303,
December 2005.
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-09 (work
in progress), January 2009.
[I-D.ietf-mipshop-pfmipv6]
Yokota,H.,Chowdhury,K.,Koodli,R.,Patil,B.,Xia,F.,"Fast
handover for Proxy Mobile IPv6",draft-ietf-mipshop-pfmipv6-
05(work in progress),June,2009
13.2. Informative References
[I-D.LocalFwd]
Koodli,R., Chowdhury,K. "Local Forwarding in Proxy Mobile
IPv6", draft-koodli-netlmm-local-forwarding-00, July 2008
[I-D.ietf-netext-pmip6-ro-ps]
Liebsch, M.,Jeong,S,Wu,Q. "PMIPv6 Localized Routing Problem
Statement", draft-ietf-netext-pmip6-ro-ps-00 (work in
progress),February 2009.
[I-D.wu-netext-pmipv6-ipv4-ro-ps]
Wu,Q., Korhonen, J.," Problem Statement of IPv4 Support for
PMIPv6 Localized Routing", draft-wu-netext-pmipv6-ipv4-ro-
Wu,et al. Expires April 26, 2010 [Page 25]
Internet-Draft Proxy MIP Extension for local routing October 2009
ps-01 (work in progress),June 2009.
Appendix A Future Extension
A.1. LMA Route Optimization Start Message
A.1.1 LMA Route Optimization Start Request Message
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence Number | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility Options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure A 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
initial lifetime of MN to CN route optimization binding. If there
are several MN-CN pairs, the same lifetime applies to each pair.
Mobility Options
As defined in section 6.1.7 in [RFC3775].
This document defines a new mobility option: MN-CN RO option in
Section 6.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
Wu,et al. Expires April 26, 2010 [Page 26]
Internet-Draft Proxy MIP Extension for local routing October 2009
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 6.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.
A.2. LMA Initiated Inter-LMA Local Routing
The message exchange for the protocol is shown in Figure 7.
Inter-LMA Local routing is triggered at one of the
LMAs, e.g. LMA1 when a datagram is received on its upstream
Wu,et al. Expires April 26, 2010 [Page 27]
Internet-Draft Proxy MIP Extension for local routing October 2009
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 PMIPv6 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 PMIPv6 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,et al. Expires April 26, 2010 [Page 28]
Internet-Draft Proxy MIP Extension for local routing October 2009
+------+ +----------+ +---------+ +------+
| 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 8 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 PMIPv6 domain.
Wu,et al. Expires April 26, 2010 [Page 29]
Internet-Draft Proxy MIP Extension for local routing October 2009
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 PMIPv6 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
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
Wu,et al. Expires April 26, 2010 [Page 30]
Internet-Draft Proxy MIP Extension for local routing October 2009
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 PMIPv6 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.
O Remove NAT Aspect and private IPv4 aspect in this document.
O Additional text about Routing Table extension and Bulk localized
routing Flag.
Wu,et al. Expires April 26, 2010 [Page 31]
Internet-Draft Proxy MIP Extension for local routing October 2009
Authors' Addresses
Qin Wu
Huawei Technologies Co.,Ltd
Site B,Floor 12F,Huihong Mansion,No.91,Baixia Rd.
Nanjing 210001
China
Email: Sunseawq@huawei.com
Behcet Sarikaya
Huawei Technologies Co.,Ltd
1700 Alma Dr.Suite 500
Plano, TX 75075
USA
Email: sarikaya@ieee.org
Wu,et al. Expires April 26, 2010 [Page 32]
| PAFTECH AB 2003-2026 | 2026-04-24 04:22:19 |