One document matched: draft-cui-netext-route-optimization-agent-ext-02.txt
Differences from draft-cui-netext-route-optimization-agent-ext-01.txt
Netext Working Group X. Cui (Ed.)
Internet Draft Huawei
Intended status: Informational A. Makela
Expires: June 2010 TKK
December 14, 2009
Reflector Extension for Route Optimization Agent
draft-cui-netext-route-optimization-agent-ext-02.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 June 14 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 June 14, 2010 [Page 1]
Internet-Draft Route Optimization Agent Extension December 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 in Route Optimization mode. 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 mode 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 accomplish 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 June 14, 2010 [Page 2]
Internet-Draft Route Optimization Agent Extension December 2009
Table of Contents
1. Introduction...................................................4
2. Terminology....................................................4
3. Scenario Analysis and Use Case.................................5
3.1. Route Optimization Requirement from Other SDO.............5
3.2. Issues if the CN can't support Route Optimization.........6
3.3. Existing analysis and solutions...........................8
3.4. Use Case for Route Optimization Agent Extension...........9
3.5. Motivation of Route Optimization Agent...................13
3.6. Requirements on Route Optimization Agent.................15
4. Solution and Operation Consideration..........................16
4.1. Route Optimization Agent Operation.......................16
4.1.1. Incoming Flow Transmission..........................16
4.1.2. Outgoing Flow Transmission..........................18
4.1.3. Conceptual Data Structures..........................19
4.1.4. Configuration Variables.............................19
4.2. LMA Operation............................................20
4.3. MAG Operation............................................20
4.3.1. Inter-MAG Handover with Agent Takeover..............20
4.3.2. Inter-MAG Handover with Agent Revocation............21
5. Security Considerations.......................................21
6. IANA Considerations...........................................21
7. Acknowledgments...............................................22
8. References....................................................22
8.1. Normative References.....................................22
8.2. Informative References...................................22
APPENDIX A: Future Extension and Use Case........................24
A.1. Agent Extension for Mobile Router........................24
A.2. Extension for IPv4/MIP4..................................25
Author's Addresses...............................................25
Cui Expires June 14, 2010 [Page 3]
Internet-Draft Route Optimization Agent Extension December 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 still
can't set up Route Optimization to this CN, as [RFC3775] specifies
"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 accomplish
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].
This document also provides the following context-specific
explanation to the following terms used in this document.
Cui Expires June 14, 2010 [Page 4]
Internet-Draft Route Optimization Agent Extension December 2009
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. The binding source consists of
home address of the source node and the home address of the source
node and the Agent Binding Cache is cached in the mid-box (i.e. the
agent entity) between the source/destination node pair.
3. Scenario Analysis and Use Case
3.1. Route Optimization Requirement from Other SDO
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]."
Cui Expires June 14, 2010 [Page 5]
Internet-Draft Route Optimization Agent Extension December 2009
3.2. 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 cannot 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.
Take the Route Optimization procedure as the example. If the mobile
node is setting up Route Optimization with a basic IP node which is
attached to the MAG, the message flow is as below:
Cui Expires June 14, 2010 [Page 6]
Internet-Draft Route Optimization Agent Extension December 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 | | | |
(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.
(f) MN2 can't recognize the Home Test Init message and replies an
ICMP error message to MN1.
Cui Expires June 14, 2010 [Page 7]
Internet-Draft Route Optimization Agent Extension December 2009
(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.3. Existing analysis and solutions
[RFC4889] focuses on NEMO Route Optimization and provides many
valuable analyses on this topic. The conclusion section (section 6)
shows some consideration aspects on Route Optimization: the benefits
a Route Optimization solution is expected to bring, the different
scenarios in which a Route Optimization solution applies, issues a
Route Optimization solution might face.
[RFC4889] also introduces some scenarios in section 5. When RO is
applied between Mobile Router and Correspondent Node, as [RFC4889]
states, "However, new functionality is likely to be required on the
Correspondent Node."
[HMIP-Based-Route-Optimization] introduces some scenarios and
solutions about Route Optimization, too. For example, Figure 11 in
section 3 illustrates Proxy CN case. In this case a MR takes the
proxy role of the correspondent node. But the solution in this
scenario is not introduced in detail and the solution also requires
the correspondent node (here is a MN but not a LFN) to support
Routing Header and Home Address Option.
This document wants to introduce a new extension solution for the
similar scenario. In this solution there is no requirement or new
functionality on the correspondent node and the agent can take all
the mobility management function for the correspondent node.
Cui Expires June 14, 2010 [Page 8]
Internet-Draft Route Optimization Agent Extension December 2009
3.4. Use Case for Route Optimization Agent Extension
The use case is related to 3GPP2 network. A mobile node in 3GPP2
network can attempt to set up Route Optimization with a correspondent
node, but as mentioned above, Route Optimization may fail due to e.g.
CN being in 3GPP network or in PMIP domain.
As an approach to these issues, this document introduces Route
Optimization Agent functionality. The functionality allows a separate
network entity to manage Route Optimization-related signaling on
behalf of the mobile node that is attached to the network. Benefits
include bringing higher QoE/QoS to both the initiating and responding
user and reducing network resource costs. The applicable scenarios
include PMIP domain and fixed IPv6 nodes that only support basic IPv6
protocol. Possible caveats include performance issues appearing on
the node running Route Optimization Agent. However, similar packets
interception functionality is already present in e.g. Home Agent, so
performance loss should be acceptable for any Router-like entities.
The use case, taking the MAG as the Agent entity, is as below:
Cui Expires June 14, 2010 [Page 9]
Internet-Draft Route Optimization Agent Extension December 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 for Route Optimization in MAG.
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.
Cui Expires June 14, 2010 [Page 10]
Internet-Draft Route Optimization Agent Extension December 2009
(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
between MN1 and MN2, with some additional operation (specified
in section 4.1) implemented.
Cui Expires June 14, 2010 [Page 11]
Internet-Draft Route Optimization Agent Extension December 2009
The Route Optimization Agent function may also be implemented in LMA,
as below:
MN1 HA LMA MAG MN2
| | | | |
===== MN1 attached to HA and MN2 attached to MAG =====
===== LMA runs PMIP protocol for MN2 (basic IP) =====
===== MN1 has no idea about the capability of MN2 =====
| | | | |
| HoTI | | | |
|---------->| HoTI | | |
| |------------>| | |
| CoTI | | |
|------------------------>| | |
| | | | |
| | HoT | | |
| HoT |<------------| | |
|<----------| | | |
| CoT | | |
|<------------------------| | |
| | | |
| BU | | |
|------------------------>| | |
| Binding Ack | | |
|<------------------------| | |
| | | |
| Traffic data | | |
|------------------------>| Traffic | |
| |---------->| Traffic |
| | |---------->|
| | | Traffic |
| | Traffic |<----------|
| Traffic data |<----------| |
|<------------------------| | |
| | | |
Figure 3 Agent extension for Route Optimization in LMA.
The Route Optimization Agent function may also be implemented in
Access Router, as below:
Cui Expires June 14, 2010 [Page 12]
Internet-Draft Route Optimization Agent Extension December 2009
MN1 HA AR IP Node2(basic IP)
| | | |
===== MN1 attached to HA and IP Node2 attached to AR =====
==== MN1 has no idea about the capability of IP Node2 ====
| | | |
| HoTI | | |
|------------>| HoTI | |
| |---------------->| |
| CoTI | |
|------------------------------>| |
| | | |
| | HoT | |
| HoT |<----------------| |
|<------------| | |
| CoT | |
|<------------------------------| |
| | |
| BU | |
|------------------------------>| |
| Binding Ack | |
|<------------------------------| |
| | |
| Traffic data | |
|------------------------------>| Traffic |
| |-------------->|
| | |
| | Traffic |
| Traffic data |<--------------|
|<------------------------------| |
| | |
Figure 4 Agent extension for Route Optimization in AR.
3.5. Motivation of Route Optimization Agent
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:
Cui Expires June 14, 2010 [Page 13]
Internet-Draft Route Optimization Agent Extension December 2009
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 5 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
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.
Cui Expires June 14, 2010 [Page 14]
Internet-Draft Route Optimization Agent Extension December 2009
3.6. Requirements on Route Optimization Agent
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
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
Route Optimization Agent MAY check whether an Agent Binding Cache
entry exists and if yes, the care-of address in the source address of
the packet is replaced by the home address of the remote mobile node
and the Home Address Option contained in the packet is removed.
Cui Expires June 14, 2010 [Page 15]
Internet-Draft Route Optimization Agent Extension December 2009
4. Solution and Operation Consideration
4.1. Route Optimization Agent Operation
The Route Optimization Agent is a function that typically runs on
LMA, MAG, Mobile Router or even the fixed Access Router for wired IP
node. The Route Optimization Agent transfers all the IP packets from
or destined to the simple IP 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 IP node.
o Creating, maintaining and deleting the Agent Binding Cache for the
IP 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 IP node.
o Source Address replacement and Home Address Option elimination for
the incoming traffic destined to the attached IP 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 of [RFC5213] for the
role of correspondent node.
The introduced Route Optimization Agent function in the reflector may
be independent of the active Proxy Mobile IP function that specified
in [RFC5213].
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 to parse the IP header to check the packet
type as soon as it receives the packet from the remote IP node.
Cui Expires June 14, 2010 [Page 16]
Internet-Draft Route Optimization Agent Extension December 2009
If the IP packet received from other IP node doesn't contain mobility
header, i.e. the IP packet is not mobility-related signaling, the
Route Optimization Agent entity needs to additionally examine the
Destination Option extension header of the packet. If the Home
Address Option (Option type = 201) is contained in the packet, the
Route Optimization Agent entity needs to examine its Agent Binding
Cache for an entry for the 3-Tuple address set (i.e. the home
address, the source address and the destination address of the IP
packet). If a corresponding Agent Binding Cache entry exists, it
means Route Optimization has been established between the IP node
pair. In this situation the Route Optimization Agent MAY replace the
care-of address in the source address of the packet with the home
address of the remote mobile node, remove the Home Address Option and
forward the modified packet to the attached IP node. If no mobility
header and no Home Address Option are contained in the packet, the
Route Optimization Agent SHOULD forward the packet to the attached IP
node without any modification. If no mobility header is contained in
the packet, and the Home Address Option is contained, but no Agent
Binding Cache entry exists, the Route Optimization Agent MUST drop
this packet. (Note: This case follows the rule of [RFC3775]).
If the IP packet received from other IP node contains the mobility
header, the Route Optimization Agent needs to further check the MH
type field in the mobility header. The Route Optimization Agent MAY
execute the expansion solution for these mobility-related packets.
If 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].
If 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].
If 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
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.
Cui Expires June 14, 2010 [Page 17]
Internet-Draft Route Optimization Agent Extension December 2009
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 to 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 MUST forward the packet to the remote IP node
without any modification.
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.
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
is transferred as described in other specification.
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].
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 attached IP node this situation.
Cui Expires June 14, 2010 [Page 18]
Internet-Draft Route Optimization Agent Extension December 2009
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 IP node the Route
Optimization Agent creates or updates the Agent Binding Cache entry
and includes the destination address of the Binding Update 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 (This document defines) or a
normal Binding Cache entry ([RFC3775] defines).
o The Agent Binding Cache entry contains a destination IP address,
which is the true destination of the intercepted Binding Update
message.
Each Agent Binding Cache entry is mapped with a 3-Tuple address set
(i.e. HoA of MN, CoA of MN and IP address of CN). The incoming packet
lookup key is the source address and the destination address of the
IP packet and the Home Address Option contained in the packet. For
the incoming packet, if the HoA of MN, CoA of MN and CN address all
matches, then the Agent Binding Cache entry is found. The outgoing
packet lookup key is the destination address and the source address
of the IP packet. 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.
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.
Cui Expires June 14, 2010 [Page 19]
Internet-Draft Route Optimization Agent Extension December 2009
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.
If the Route Optimization Agent function is implemented in the MAG
and inter-MAG handover happens simultaneously, the MAG SHOULD proceed
as specified in section 4.3.1 and 4.3.2 of this document.
4.3.1. Inter-MAG Handover with Agent Takeover
If the Agent function can be implemented in the new MAG (The previous
MAG can get this information during the message exchange between pMAG
and nMAG), the previous MAG SHOULD try to transfer the Agent Binding
Cache entry to the new MAG as part of the context. The 3-Tuple
address set (i.e. HoA of MN, CoA of MN and IP address of CN) MUST be
transferred to the new MAG. Note some Node Keys in the previous MAG
are not shared with other entities so the new MAG gets no binding
management keys from the previous MAG. In this situation, the new MAG
SHOULD send the Binding Refresh Request message to the remote mobile
IP node as specified in [RFC3775] to refresh the agent binding. When
the remote mobile IP node restarts the Return Routability and Route
Cui Expires June 14, 2010 [Page 20]
Internet-Draft Route Optimization Agent Extension December 2009
Optimization as specified in [RFC3775], the new MAG will take over
the Agent role for the attached IP node.
4.3.2. Inter-MAG Handover with Agent Revocation
If the new MAG does not support Route Optimization Agent function,
the function is disabled or the 3-Tuple address set (i.e. HoA of MN,
CoA of MN and IP address of CN) can't be transferred to the new MAG
(The previous MAG can get this information during the message
exchange between pMAG and nMAG), the previous MAG SHOULD send the
Binding Revocation Indication message to the remote mobile node as
specified in [CN-Binding-Revocation] to revoke the agent binding.
When the remote mobile IP node releases the correspondent node
binding as specified in [CN-Binding-Revocation], the session between
the remote mobile IP node and the attached IP node fallbacks to the
Bidirectional Tunneling mode.
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 Route
Optimization Agent still follows the principle that providing
network-based mobility management to the IP node that is attached to
its access link. So this extension brings no new security issue to
mobility management.
But this extension requires the Route Optimization Agent to implement
packet inspection on the packets destined to the IP node, which would
impact the performance of the Agent entity 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.
Cui Expires June 14, 2010 [Page 21]
Internet-Draft Route Optimization Agent Extension December 2009
7. Acknowledgments
The author would like to specially thank Hidetoshi Yokota, Sri
Gundavelli, Qin Wu, Yungui Wang and Carlos J. Bernardos 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.
[RFC4889] Ng, C., Zhao, F., Watari, M., and P. Thubert, "Network
Mobility Route Optimization Solution Space Analysis", RFC
4889, July 2007.
[RFC5213] Sri, G., Kent, L., Vijay, D. Kuntal, C. and B. Patil,
"Proxy Mobile IPv6", RFC 5213, August 2008.
[CN-Binding-Revocation] Xiangsong, C. and A. Makela, "Binding
Revocation from correspondent node in Route Optimization
Mode", draft-cui-mext-cn-binding-revocation-00, (work in
progress), November 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 June 14, 2010 [Page 22]
Internet-Draft Route Optimization Agent Extension December 2009
[HMIP-Based-Route-Optimization] Hiroyuki, O., Keisuke, S. and Y.
Takagi, "HMIP based Route optimization method in a mobile
network", draft-ohnishi-nemo-ro-hmip-00 (expired),
October, 2003.
Cui Expires June 14, 2010 [Page 23]
Internet-Draft Route Optimization Agent Extension December 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 6 Agent extension in Route Optimization.
Cui Expires June 14, 2010 [Page 24]
Internet-Draft Route Optimization Agent Extension December 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
Antti Makela
Helsinki University of Technology
P.O. Box 3000
FIN-02105 TKK
FINLAND
Phone: +358 9 451 5590
Email: antti.makela@tkk.fi
Cui Expires June 14, 2010 [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-24 08:01:12 |