One document matched: draft-cui-netext-route-optimization-agent-ext-01.txt
Differences from draft-cui-netext-route-optimization-agent-ext-00.txt
Netext Working Group X. Cui
Internet Draft Huawei
Intended status: Informational October 26, 2009
Expires: April 2010
Reflector Extension for Route Optimization Agent
draft-cui-netext-route-optimization-agent-ext-01.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 2010.
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.
Cui Expires April 26, 2010 [Page 1]
Internet-Draft Route Optimization Agent Extension October 2009
Abstract
Route Optimization is a very useful feature in Mobile IPv6. Mobile
node can communicate with correspondent node without the involvement
of the home agent by Route Optimization. But there are some
limitations to this feature. One problem is that the mobile node and
the correspondent node must be capable for Route Optimization. This
document introduces a Route Optimization Agent function used for
Route Optimization and this extension mechanism can enable Route
Optimization to be used between mobile node and simple IP node. In
the extension solution, the Route Optimization Agent function may be
implemented in LMA or MAG and the Agent entity can reflect the RO-
related signal messages and fulfill the Route Optimization procedure
on behalf of the simple IP node.
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 [RFC2119].
Cui Expires April 26, 2010 [Page 2]
Internet-Draft Route Optimization Agent Extension October 2009
Table of Contents
1. Introduction..................................................4
2. Terminology...................................................4
3. Scenario Analysis and Use Case................................5
3.1. Issues if the CN can't support Route Optimization........5
3.2. Use Case for Route Optimization Agent Extension..........7
3.3. Motivation..............................................11
3.4. Requirements............................................12
4. Solution and Operation Consideration.........................13
4.1. Route Optimization Agent Operation......................13
4.1.1. Incoming Flow Transmission.........................14
4.1.2. Outgoing Flow Transmission.........................15
4.1.3. Conceptual Data Structures.........................16
4.1.4. Configuration Variables............................16
4.2. LMA Operation...........................................17
4.3. MAG Operation...........................................17
5. Security Considerations......................................18
6. IANA Considerations..........................................18
7. Acknowledgments..............................................18
8. References...................................................18
8.1. Normative References....................................18
8.2. Informative References..................................19
APPENDIX A: Future Extension and Use Case.......................20
A.1. Agent Extension for Mobile Router.......................20
A.2. Extension for IPv4/MIP4.................................21
Author's Addresses..............................................21
Cui Expires April 26, 2010 [Page 3]
Internet-Draft Route Optimization Agent Extension October 2009
1. Introduction
Mobile IPv6 protocol [RFC3775] provides a mobility extension to basic
IPv6 and introduces Route Optimization (RO) mechanism. Route
Optimization enables mobile node (MN) to establish a directly
connection between mobile node and correspondent node (CN) without
the involvement of MN's home agent (HA).
But Route Optimization requires mobile node and correspondent node to
have some certain capabilities, such as MN's transmitting Home Test
Init (HoTI) message, Care-of Test Init (CoTI) message and direct
Binding Update message to CN, and CN's reflecting Home Test (HoT)
message, Care-of Test Init (CoT) message and Binding Ack message to
MN.
If the correspondent node is a simple IP node without support for
Route Optimization, the MN with support for Route Optimization even
can't set up Route Optimization to this CN, as [RFC3775] specified
"If a mobile node attempts to set up route optimization with a node
with only basic IPv6 support, an ICMP error will signal that the node
does not support such optimizations and communications will flow
through the home agent."
From the MN's viewpoint, the IPv6 nodes with support for MIP and IPv6
nodes without support for MIP are using the unified address space, so
the MN can't distinguish whether a correspondent node is a RO-capable
node or a non-RO-capable node. When the network is composed of mobile
IPv6 nodes, IPv6 nodes with support for Route Optimization and
enormous quantity of simple IPv6 nodes with support for only basic
IPv6 protocol, lots of Route Optimization attempts will go to a
failure result.
This document introduces an extension mechanism, which can be used
for IP nodes with only support for basic IPv6 protocol, to fulfill
the Route Optimization.
2. Terminology
All the mobility related terms used in this document are to be
interpreted as defined in the Mobile IPv6 specification [RFC3775] and
Proxy Mobile IPv6 [RFC5213].
Cui Expires April 26, 2010 [Page 4]
Internet-Draft Route Optimization Agent Extension October 2009
This document also provides the following context-specific
explanation to the following terms used in this document.
Route Optimization Agent (ROA)
Route Optimization Agent is the logical function entity that acts
reflector role in Route Optimization procedure on behalf of the
correspondent node.
Agent Binding Cache (ABC)
The Agent Binding Cache is the cache of binding for binding source
node and binding destination node, and is cached in the mid-box (i.e.
the agent entity) between the node pair.
3. Scenario Analysis and Use Case
3.1. Issues if the CN can't support Route Optimization
Mobile IPv6 provides the Route Optimization mechanism, which may be
used between mobile nodes with support for MIPv6 or between mobile
nodes and IP nodes with support for Route Optimization.
In other situation, if the correspondent node can't support Route
Optimization, the correspondent node will reply an ICMP ERROR message
to the mobile node who initiates the Route Optimization.
On the other hand, Proxy Mobile IPv6 [RFC5213] provides a network-
based mobility solution. In Proxy Mobile IPv6 domain, Local Mobility
Anchor (LMA) and Mobile Access Gateway (MAG) can provide proxy
mobility management functionality for the mobile node.
The LMA works as the mobility anchor for the mobile node and the MAG
works as the mobility proxy for the mobile node, as [RFC5213]
defined, LMA is "the entity that manages the mobile node's binding
state" while MAG is "a function on an access router that manages the
mobility-related signaling for a mobile node that is attached to its
access link". But by now the MAG is only half-function proxy for the
mobile node, because the MAG can only transmit mobility-related
signal messages for the mobile node but can not dispose the mobility-
related signal messages destined to the mobile node. The MAG is only
an active proxy function but does not implement reactive agent
function in current specification. The function of managing the
mobility-related signaling defined for MAG is not fully specified by
now.
Cui Expires April 26, 2010 [Page 5]
Internet-Draft Route Optimization Agent Extension October 2009
Take the Route Optimization procedure as the example. If the mobile
node is setting up Route Optimization with a simple IP node which is
attached to the MAG, the message flow is as below:
MN1 HA LMA MAG MN2
| | | | |
===== MN1 attached to HA and MN2 attached to MAG =====
(a) ===== MAG runs PMIP protocol for MN2 (Basic IP) =====
===== MN1 has no idea about the capability of MN2 =====
| | | | |
| HoTI | | | |
(b) |---------->| HoTI | | |
(c) | |------------>| HoTI | |
(d) | | |---------->| HoTI |
(e) | | | |---------->|
| | | | ICMP(Err) |
(f) | | | |<----------|
| CoTI | | |
(g) |------------------------>| CoTI | |
(h) | | |---------->| CoTI |
(I) | | | |---------->|
| | | | ICMP(Err) |
(j) | | | |<----------|
| ICMP(Err) | | | |
(k) |<----------| | | |
| | | | |
| | | | |
| | | | |
Figure 1 Issue in Route Optimization.
The detailed descriptions are as follows:
(a) MN1 attached to Home Agent and MN2 attached to MAG, MAG runs PMIP
protocol for MN2, which only supports basic IP protocol. During
the lifetime of the session between MN1 and MN2, MN1 has no idea
about the capability of MN2.
(b~e) MN1 initiates a Route Optimization set up and sends Home Test
Init message to MN2. The destination address of the packet is
the home address of MN2 and the packet goes through HA, LMA and
MAG, at last arrives at MN2.
Cui Expires April 26, 2010 [Page 6]
Internet-Draft Route Optimization Agent Extension October 2009
(f) MN2 can't recognize the Home Test Init message and replies an
ICMP error message to MN1.
(g~i) MN1 sends Care-of Test Init message to MN2. The destination
address of the packet is the home address of MN2 and the packet
goes through LMA and MAG, at last arrives at MN2 too.
(j) MN2 can't recognize the Care-of Test Init message and replies an
ICMP error message to MN1.
(k) MN1 receives the ICMP error messages sent by MN2, has to stop
Route Optimization set up.
In this example, Home Test Init message and Care-of Test Init message
are both mobility-related signaling, but the MAG doesnot manage or
deal these messages for MN2. This miss induces the failure of Route
Optimization.
3.2. Use Case for Route Optimization Agent Extension
Route Optimization is specified in [RFC3775] and also adopted by
other SDO, such as 3GPP2. 3GPP2 has specified some specific
requirements and feature description in 3GPP2 documents.
Section 4.4 "MIP6" of [X.S0011-001-D] is about MIP6 protocol and
Figure 13 and Figure 16 in this section illustrate the protocol
reference model for MIP6 Route Optimization mode.
Section 5.3 "Home Agent Requirements" of [X.S0011-002-D] introduces
the requirements of Home Agent on Route Optimization, as specified in
section 5.3.6 "Return Routability Support for Route Optimization",
"The Home Agent shall support Return Routability (RR) for Route
Optimization as specified in [RFC3775] with the exception that IPsec
is not used to protect the RR messages."
Section 6 "MIP6 Route Optimization" of [X.S0047-0] introduces the
requirements of mobile node on Route Optimization, as specified in
section 6.1 "MS Requirements", "The MS may support the return
routability procedure, binding update procedure, and packet
processing for the Mobile Node Operation and Correspondent Node
Operation, according to [RFC3775]."
Based on 3GPP2 documents, mobile node in 3GPP2 network may (as far as
it like) set up Route Optimization to the correspondent node, but as
mentioned above, the correspondent node maybe cannot support that
Cui Expires April 26, 2010 [Page 7]
Internet-Draft Route Optimization Agent Extension October 2009
(e.g. CN is in 3GPP network or in PMIP domain). From the MN's
viewpoint, all work well but the setting up is failed, the result is
exactly disgusting.
For above trouble, this document introduces the Route Optimization
Agent function and this extension enables network entity to manage
all the mobility-related signaling for the mobile node that is
attached to the network. The use case, taking the MAG as the Agent
entity, is as below:
Cui Expires April 26, 2010 [Page 8]
Internet-Draft Route Optimization Agent Extension October 2009
MN1 HA LMA MAG MN2
| | | | |
===== MN1 attached to HA and MN2 attached to MAG =====
a ===== MAG runs PMIP protocol for MN2 (Basic IP) =====
===== MN1 has no idea about the capability of MN2 =====
| | | | |
| HoTI | | | |
b1 |---------> | HoTI | | |
b2 | |------------>| HoTI | |
b3 | CoTI |---------->| |
c1 |------------------------>| HoT | |
d1 | | |<----------| |
| | | CoTI | |
c2 | | HoT |---------->| |
d2 | HoT |<------------| | |
d3 |<----------| | CoT | |
e1 | CoT |<----------| |
e2 |<------------------------| | |
| | | |
| | | |
| BU | | |
f1 |------------------------>| BU | |
f2 | |---------->| |
| |Binding Ack| |
g1 | Binding Ack |<----------| |
g2 |<------------------------| | |
| Traffic data | | |
-|------------------------>| Traffic | |
/ | |---------->| Traffic |
/ | | |---------->|
h | | | | Traffic |
\ | | Traffic |<----------|
\ | Traffic data |<----------| |
-|<------------------------| | |
| | | |
Figure 2 Agent extension in Route Optimization.
The detailed descriptions are as follows:
(a) MN1 attached to Home Agent and MN2 attached to MAG, MAG runs PMIP
protocol for MN2, which only supports basic IP protocol. During
Cui Expires April 26, 2010 [Page 9]
Internet-Draft Route Optimization Agent Extension October 2009
the lifetime of the session between MN1 and MN2, MN1 has no idea
about the capability of MN2.
(b1~b3) MN1 initiates a Route Optimization set up and sends Home Test
Init message to MN2. The destination address of the packet is
the home address of MN2 and the packet goes through HA and LMA
and reaches MAG.
(c1~c2) MN1 sends Care-of Test Init message to MN2. The destination
address of the packet is the home address of MN2 and the packet
goes through LMA and reaches MAG too.
(d1~d3) MAG recognizes the Home Test Init message, which is a
mobility-related signaling, and generates a Home Test message
on behalf of MN2. The procedure for the MAG to generate the
Home Test message is as the same with CN's operation specified
in section 9.4.1 and section 9.4.3 of [RFC3775]. The MAG
transmits Home Test message to MN1 and the packet goes through
LMA and HA and arrives at MN1 at last.
(e1~e3) MAG recognizes the Care-of Test Init message, which is a
mobility-related signaling, and generates a Care-of Test
message on behalf of MN2. The procedure for the MAG to generate
the Care-of Test message is as the same with CN's operation
specified in section 9.4.2 and section 9.4.4 of [RFC3775]. The
MAG transmits Care-of Test message to MN1 and the packet goes
through LMA and arrives at MN1 at last.
(f1~f2) MN1 receives Home Test and Care-of Test message and sends
Binding Update message to the address of MN2 as specified in
[RFC3775]. The Binding Update message also reaches the MAG
which the MN2 attached to.
(g1~g2) MAG recognizes the Binding Update message, which is a
mobility-related signaling, and caches the Home Address, Care-
of Address and bindings on behalf of MN2. The procedure is as
the same with CN's operation as specified in section 9.5.1 of
[RFC3775]. The MAG also includes the IP address of the attached
IP node (i.e. the destination of the Binding Update message) in
the Agent Binding Cache entry. The MAG transmits Binding Ack
message to MN1 and the packet goes through LMA and arrives at
MN1 at last.
(h) Route Optimization is achieved and Home Agent of MN1 is not
involved in the traffic data transport. For the traffic flow
between MN1 to MN2, the MAG forwards all the traffic packets
Cui Expires April 26, 2010 [Page 10]
Internet-Draft Route Optimization Agent Extension October 2009
between MN1 and MN2, with some additional operation (specified
in section 4.1) implemented.
3.3. Motivation
The motivation for this extension is based on some mechanisms that
have been introduced in IETF. For example, Proxy ARP protocol, which
is specified in [RFC1027] "Using ARP to Implement Transparent Subnet
Gateways", has been adopted by lots of routers and gateways.
One basic Proxy ARP flow is as below:
Host A Gateway Host B
| e0 | e1 |
| | |
------- Host A and Host B attached to the Gateway -------
| | |
| ARP request (IP B) | |
|----------------------- > | |
| | |
| proxy ARP reply (IP B) | |
|< ------------------------| |
| | |
| traffic data (IP B) | |
|------------------------ >| traffic data (IP B) |
| |------------------- >|
| | |
| | |
Figure 3 Proxy ARP message flow.
In this case, when host A wants to send IP packets to host B, if host
A knows only the IP address of host B but doesn't know the MAC
address of host B, host A need send out a ARP request message and
broadcast the message in MAC layer. The gateway will receive this ARP
request, whose destination IP address is the IP address of host B.
The destination of this message is not the gateway, but the gateway
knows that the destination (i.e. host B) is attached to itself and
also knows the destination can't receive this ARP request, so in this
situation, the gateway replies an ARP reply message for host B. In
the proxy ARP reply message, the source IP address is the IP address
of host B and the source MAC address is the MAC address of the e0
interface in the gateway. When host A receives this proxy ARP reply
Cui Expires April 26, 2010 [Page 11]
Internet-Draft Route Optimization Agent Extension October 2009
message, it can know how to send IP packets to host B. Host A will
send IP packets to the gateway (i.e. the e0 interface) and the
gateway will forward these packets to host B.
Similar to this case, when the MAG in the PMIP domain receives some
mobility-related signal messages (e.g. HoTI, CoTI and BU) destined to
the mobile node that is attached to its access link, the MAG can also
know that the mobile node can't recognize these messages. This
judgment may depend on the policy profile of the mobile node, the
configuration variables of the MAG, or other manners. Since the MAG
is the mobility proxy of the mobile node and can manage the mobility-
related signaling for the mobile node, it is reasonable for the MAG
to dispose these messages on behalf of the mobile node. The Route
Optimization Agent function MAY be implemented in this situation.
3.4. Requirements
The Route Optimization Agent function introduced in this document
depends on the operation of the network entity. The requirements of
the Route Optimization Agent function include following:
R1: Route Optimization Agent can recognize mobility-relate signal
messages. When the Route Optimization Agent receives mobility-related
signaling destined to the MN that is attached to the network, the
Route Optimization Agent MAY intercept the messages and reply
response messages for the mobile node. Since all the mobility-related
signal messages contain mobility header and MH Type field, the Route
Optimization Agent can easily fulfill this requirement.
R2: Route Optimization Agent can achieve the operation of CN role for
Return Routability and Route Optimization specified in [RFC3775].
[RFC5213] has specified some mechanisms for LMA/MAG to provide
network-based mobility management function. For example, the MAG can
create and maintain the Binding Update List as a mobile node does,
and the LMA can create and maintain the Binding Cache for the mobile
node. It is easy to expand the MAG to create and maintain an Agent
Binding Cache Entry to meet this requirement, and it is also easy to
expand the LMA to create and maintain Agent Binding Cache to hold the
binding between the mobile node and the correspondent node. The
LMA/MAG MAY do more agent operation than specified in [RFC5213] as
specified in this document.
R3: Route Optimization Agent can modify the outgoing packets and
route the packets to the optimized route depending on the created
Agent Binding Cache. The Route Optimization Agent MAY check whether
an Agent Binding Cache entry exists and if the Agent Binding Cache
entry exists the Route Optimization Agent modifies the destination
Cui Expires April 26, 2010 [Page 12]
Internet-Draft Route Optimization Agent Extension October 2009
address in the IP header and includes Type 2 Routing Header in the
outgoing packets. The Route Optimization Agent should set the
destination address to the care-of address of the destined mobile
node and set the Home Address field in the Type 2 Routing Header to
the home address of the destined mobile node.
R4: Route Optimization Agent can modify the source address of the
incoming packets depending on the created Agent Binding Cache. The
care-of address in the source address of the packet is replaced by
the home address of the remote mobile node.
4. Solution and Operation Consideration
4.1. Route Optimization Agent Operation
The Route Optimization Agent is a function that typically runs on
LMA, MAG or other special routers. The Route Optimization Agent
transfers all the IP packets from or destined to the mobile node that
is attached to the network. However, some more operations are defined
in this document for the expansion solution.
The operations for Route Optimization Agent consist of following:
o Intercepting and disposing the mobility-related signaling destined
to the attached mobile node.
o Creating, maintaining and deleting the Agent Binding Cache for the
mobile node to which the initiator wants to establish or release
a Route Optimization.
o Destination Address replacement and Type 2 Routing Header
insertion for the outgoing traffic from the attached mobile node.
o Source Address replacement for the incoming traffic destined to
the attached mobile node.
o Security operation for the Return Routability Procedure and Route
Optimization. The Route Optimization Agent SHOULD works as
specified in section 5.2 and section 15.4 in [RFC5213] for the
role of correspondent node.
Cui Expires April 26, 2010 [Page 13]
Internet-Draft Route Optimization Agent Extension October 2009
Editor Note:
The introduced Route Optimization Agent Function in the reflector
may be separate with the active Proxy Mobile IP function
specified in [RFC5213]. This is to say that the Agent Binding
Cache management, the Binding Cache management and the Binding
Update List management may be independent. Route Optimization
Agent function may even be implemented in access router for fixed
IP node. The details need more consideration and discussion.
4.1.1. Incoming Flow Transmission
For the incoming flow (i.e. from the remote IP node to the IP node
that is attached to the Route Optimization Agent), the Route
Optimization Agent needs parse the IP header to check the packet type
as soon as it receives the packet from the remote IP node.
If the IP packets received from other IP nodes don't contain mobility
header, i.e. the IP packets are not mobility-related signaling, the
Route Optimization Agent entity needs examine its Agent Binding Cache
for an entry for the address pair (i.e. the source address and the
destination address of the IP packet). Additionally if a
corresponding Agent Binding Cache entry exists, it means Route
Optimization has been established between the IP node pair. The Route
Optimization Agent MAY replace the care-of address in the source
address of the packet with the home address of the mobile node.
If the IP packets received from other IP nodes contain the mobility
header, the Route Optimization Agent needs further check the MH type
field in the mobility header. The Route Optimization Agent MAY
execute the expansion solution for these mobility-related packets.
When the received packet is Home Test Init Message, the Route
Optimization Agent stops transferring the packet to the attached IP
node and executes the operation as specified for the correspondent
node role in section 9.4.1 and 9.4.3 of [RFC3775].
When the received packet is Care-of Test Init Message, the Route
Optimization Agent stops transferring the packet to the attached IP
node and executes the operation as specified for the correspondent
node role in section 9.4.2 and 9.4.4 of [RFC3775].
When the received packet is Binding Update message, the Route
Optimization Agent stops transferring the packet to the attached IP
node and executes the operation as specified for the correspondent
Cui Expires April 26, 2010 [Page 14]
Internet-Draft Route Optimization Agent Extension October 2009
node role in section 9.5.1 and 9.5.4 of [RFC3775]. The exception is
that the Route Optimization Agent should create or update Agent
Binding Cache entity and include the destination address of the BU
message in the Agent Binding Cache entry.
4.1.2. Outgoing Flow Transmission
For the outgoing (i.e. from the IP node that is attached to the Route
Optimization Agent to the remote IP node) flow, the Route
Optimization Agent needs examine its Agent Binding Cache for an entry
for the address pair (i.e. the source address and the destination
address of the IP packet) as soon as it receives packet from the
attached IP node.
If no corresponding Agent Binding Cache entry exists, the Route
Optimization Agent function is skipped.
If a corresponding Agent Binding Cache entry exists, it means Route
Optimization has been established between the IP node pair. The Route
Optimization Agent MAY use a type 2 routing header to route the
packet to the destination node by way of its care-of address.
However, the Route Optimization Agent MUST NOT do this in the
following cases:
o When forwarding an IPv6 Neighbor Discovery packet.
o When forwarding the packets that are noted in Section 6.1 of
[RFC3775].
The Route Optimization Agent may implement following operation for
Route Optimization:
o The Route Optimization Agent inserts the Type 2 routing header and
sets the Home Address in the routing header to the remote mobile
node's home address (the original destination address to which
the packet was being sent).
o The Route Optimization Agent sets the Destination Address in the
packet's header to the remote mobile node's care-of address
copied from the Agent Binding Cache entry.
o The Route Optimization Agent operation is achieved and the packet
go forward as described in other specification.
Cui Expires April 26, 2010 [Page 15]
Internet-Draft Route Optimization Agent Extension October 2009
Note that the implementation creates some additional requirements for
path MTU discovery since the modification changes the packet size.
The Route Optimization Agent should choose an appropriate way to
indicate the sending IP node this situation.
4.1.3. Conceptual Data Structures
This document adds Agent Binding Cache to the Route Optimization
Agent entity. When the Route Optimization Agent receives the Binding
Update message destined to the attached mobile node the Route
Optimization Agent creates or updates the Agent Binding Cache entry
and includes the destination address of the BU message in the Agent
Binding Cache entry.
The newly introduced Agent Binding Cache entry for this extension
contains two additional fields than the Binding Cache entry data
structure specified in section 9.1 of [RFC3775].
o The Agent Binding Cache entry contains a flag indicating either
this is an Agent Binding Cache entry or a normal Binding Cache
entry.
o The Agent Binding Cache entry contains an associated mobile node
address, which is the true destination of the intercepted Binding
Update message.
Each Agent Binding Cache entry is mapped with a triple set (i.e. HoA
of MN, CoA of MN and IP address of CN). The lookup key is the source
address and the destination address of the IP packet. For the
incoming packet, if the CoA of MN and CN address pair matches, then
the Agent Binding Cache entry is found. For the outgoing packet, if
the HoA of MN and CN address pair matches, then the Agent Binding
Cache entry is found. Route Optimization may be applied between the
IP node pair in these two cases.
4.1.4. Configuration Variables
A configuration variable, EnableRouteOptimizationAgent is defined in
this document for Route Optimization Agent function.
Cui Expires April 26, 2010 [Page 16]
Internet-Draft Route Optimization Agent Extension October 2009
This variable is available in Route Optimization Agent entity. When
the value of this variable is 1, the Route Optimization Agent
function is enabled. When the value of this variable is 0, the Route
Optimization Agent function is disabled.
The default value of EnableRouteOptimizationAgent is 0.
4.2. LMA Operation
The Route Optimization Agent function may be implemented in LMA
entity.
When the LMA works as the Route Optimization Agent entity, LMA should
follow the operation specified in section 4.1 of this document, and
other network elements such as MAG, CN, MN and the HA of the MN are
not impacted and follow the operation described in other
specifications.
4.3. MAG Operation
The Route Optimization Agent function may be implemented in MAG
entity.
When the MAG works as the Route Optimization Agent entity, MAG should
follow the operation specified in section 4.1 of this document, and
other network elements such as LMA, CN, MN and the HA of the MN are
not impacted and follow the operation described in other
specifications.
Note if the Route Optimization Agent function is implemented in the
MAG and MAG handover happens simultaneously, the previous MAG should
try to transfer the Agent Binding Cache entry to the new MAG as part
of the context.
If the new MAG cannot support Route Optimization Agent function or
the value of EnableRouteOptimizationAgent in the new MAG is 0, the
Route Optimization would be interrupted. This case is for further
study.
Cui Expires April 26, 2010 [Page 17]
Internet-Draft Route Optimization Agent Extension October 2009
5. Security Considerations
The extension in this document is just to expand the scope of the
mobility management to cover the reactive mobility management agent
function, such as the acceptance of Route Optimization, and the MAG
still follows the principle that providing network-based mobility
management to the mobile node that is attached to its access link. So
this extension brings no new security issue to mobility management.
But this extension needs the MAG to implement packet inspection on
the packets destined to the mobile node, which would impact the
performance of the MAG and maybe bring some security risk. By the
time when this document is written, no explicit security problem has
been found and the accurate security consideration needs to be
further studied.
6. IANA Considerations
This document has no actions for IANA.
7. Acknowledgments
The author would like to specially thank Hidetoshi Yokota, Sri
Gundavelli, Qin Wu and Yungui Wang for their comments and discussion
on this document.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5213] Sri, G., Kent, L., Vijay, D. Kuntal, C. and Basavaraj, P.,
"Proxy Mobile IPv6", RFC 5213, August 2008.
Cui Expires April 26, 2010 [Page 18]
Internet-Draft Route Optimization Agent Extension October 2009
8.2. Informative References
[RFC1027] Smoot, C. and John Q., "Using ARP to Implement Transparent
Subnet Gateways", RFC1027, October 1987.
[X.S0011-001-D] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard:
Introduction", X.S0011-001-D v2.0, November 2008.
[X.S0011-002-D] 3GPP2 TSG-X, "cdma2000 Wireless IP Network Standard:
Simple IP and Mobile IP Access Services", X.S0011-002-D
v2.0, November 2008.
[X.S0047-0] 3GPP2 TSG-X, "Mobile IPv6 Enhancements", X.S0047-0 v1.0,
February 20, 2009.
Cui Expires April 26, 2010 [Page 19]
Internet-Draft Route Optimization Agent Extension October 2009
APPENDIX A: Future Extension and Use Case
A.1. Agent Extension for Mobile Router
This solution can also be applied in Network Mobility (NEMO)
extension, where the Mobile Router provides mobility management for
IP node with only support for basic IP. The extension for NEMO is as
below:
MN1 HA1 HA2 MR MN2
| | | | |
===== MN1 attached to HA and MN2 attached to MR =====
a ===== MR provides mobility management for MN2 =====
===== MN1 has no idea about the capability of MN2 =====
| | | | |
| HoTI | | | |
b1 |---------> | HoTI | | |
b2 | |------------>| HoTI | |
b3 | CoTI |---------->| |
c1 |------------------------>| HoT | |
d1 | | |<----------| |
| | | CoTI | |
c2 | | HoT |---------->| |
d2 | HoT |<------------| | |
d3 |<----------| | CoT | |
e1 | CoT |<----------| |
e2 |<------------------------| | |
| | | |
| | | |
| BU | | |
f1 |------------------------>| BU | |
f2 | |---------->| |
| |Binding Ack| |
g1 | Binding Ack |<----------| |
g2 |<------------------------| | |
| Traffic data | | |
-|------------------------>| Traffic | |
/ | |---------->| Traffic |
/ | | |---------->|
h | | | | Traffic |
\ | | Traffic |<----------|
\ | Traffic data |<----------| |
-|<------------------------| | |
| | | |
Figure 4 Agent extension in Route Optimization.
Cui Expires April 26, 2010 [Page 20]
Internet-Draft Route Optimization Agent Extension October 2009
In this extension, Mobile Router manages the mobility-related
signaling destined to the mobile node that is attached to its access
link. Mobile Router responds Care-of Test and Home Test message and
manages the binding cache on behalf of the MN.
A.2. Extension for IPv4/MIP4
TBD.
Author's Addresses
Xiangsong Cui
Huawei Technologies
KuiKe Bld., No.9 Xinxi Rd.,
Shang-Di Information Industry Base,
Hai-Dian District, Beijing, P.R. China, 100085
Email: Xiangsong.Cui@huawei.com
Cui Expires April 26, 2010 [Page 21]
| PAFTECH AB 2003-2026 | 2026-04-24 08:00:57 |