NETLMM Working Group A. Dutta (Ed.)
Internet-Draft S. Das
Expires: January 14, 2009 Telcordia
H. Yokota
KDDI Labs
T. Chiba
KDDILab
H. Schulzrinne
Columbia Univ.
July 13, 2008
ProxyMIP Extension for Inter-MAG Route Optimization
draft-dutta-netlmm-pmipro-01
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of 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 January 14, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Dutta (Ed.), et al. Expires January 14, 2009 [Page 1]
Internet-Draft PMIP Route Optimization July 2008
Abstract
This draft describes a light weight route optimization technique that
helps to optimize the media path between two communicating nodes when
Proxy MIP is used as the mobility protocol. This routing
optimization technique is most useful when the two communicating
hosts are away from home and need to communicate with each other
using an optimized path. It takes advantage of the data packet
between LMA and MAG to set up the optimized data path between the
communicating hosts. This route optimization technique is applicable
to both the intra-LMA and inter-LMA scenarios.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicable Scenarios for Route Optimization . . . . . . . . . 7
4. Route Optimization Techniques . . . . . . . . . . . . . . . . 11
4.1. Intra-LMA route optimization . . . . . . . . . . . . . . . 11
4.1.1. Initial State . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Route Optimization after handoff . . . . . . . . . . . 14
4.2. Inter-LMA route optimization . . . . . . . . . . . . . . . 17
4.2.1. Initial state . . . . . . . . . . . . . . . . . . . . 17
4.2.2. Route optimization after handoff . . . . . . . . . . . 19
5. Message Format . . . . . . . . . . . . . . . . . . . . . . . . 21
5.1. Correspondent Binding Update Message . . . . . . . . . . . 21
5.2. Correspondent Binding Acknowledgement . . . . . . . . . . 22
6. Security Considerations . . . . . . . . . . . . . . . . . . . 23
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
9.1. Normative References . . . . . . . . . . . . . . . . . . . 26
9.2. Informative References . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 29
Dutta (Ed.), et al. Expires January 14, 2009 [Page 2]
Internet-Draft PMIP Route Optimization July 2008
1. Introduction
Wireless Service Providers (WISPs) strive to provide secured and
seamless connectivity to the roaming users. When a mobile is
subjected to repeated handoff, quality of existing communication gets
degraded due to delay and packet loss. There are several transition
events during the handoff, such as discovery, configuration,
authentication, security association, binding update and media
redirection that contribute to the handoff delay and the associated
packet loss. This specific route optimization technique reduces the
delay due to media delivery by reducing the media traversal path
between the communicating hosts.
In order to reduce the delay due to binding update and associated
one-way-delay of the media, when a mobile's movement is confined to a
specific domain, various local mobility management protocols have
been designed. These include Cellular IP, HAWAII, IDMP, HMIPv6 etc.
NETLMM working group within IETF has recommended a set of goals and
host requirements to support localized mobility [RFC4830], [RFC4831],
[RFC4832]. Based on these goals, IETF has currently designed Proxy
MIPv6 protocol [I-D.ietf-netlmm-proxymip6] that helps to reduce the
delay due to long binding update. It takes much of the burden away
from the mobile and puts it on the wired access routers within the
network that are called Media Access Gateway (MAG). MAG is equipped
with proxy mobility agent (PMA) that sends the binding update to the
home agents on behalf of the mobiles. Each mobile is anchored with a
certain MAG until it hands off to a new MAG. The PMIPv6-based
mobility protocol is preferred when mobility is confined within a
domain and wireless service providers do not want to overload the
mobile nodes stack by setting up a tunnel between the mobile and the
LMA. A tunnel is not desirable on the mobile node because it adds
extra processing and bandwidth constraints to the wireless hop.
Although Proxy Mobile IP provides optimization compared to other
global mobility protocols, it still needs improvement in certain
areas such as route optimization. Route optimization reduces the
delay due to media delivery between the two communicating mobiles by
reducing the traversal distance of the media packets between the
communicating hosts. Some of the requirements for route optimization
are mentioned in [I-D.jeong-netlmm-pmipv6-roreq]. There are also few
proposals that have discussed route optimization for Proxy MIPv6,
[I-D.abeille-netlmm-proxymip6ro] and [I-D.qin-netlmm-pmipro]. These
mechanisms either depend on the MIPv6 route optimization procedures
or introduce a heavy weight route setup procedure to obtain the
desired optimization. In this draft we describe a lightweight route
optimization technique for PMIP that will further improve the
effectiveness of PMIP for both intra-domain and inter-domain
movement. This technique takes advantage of the data packet and sets
Dutta (Ed.), et al. Expires January 14, 2009 [Page 3]
Internet-Draft PMIP Route Optimization July 2008
up the route optimization between the mobile hosts.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 4]
Internet-Draft PMIP Route Optimization July 2008
2. Terminology
Binding Cache Entry: A binding cache in the network entity that
provides the route information about a communicating node. BCE
can exist either within an LMA or in the MAG.
Route Optimization: Route optimization is a mechanism by which the
data path is from CN to MN is optimized.
Proxy Binding Update: A procedure to update the identifier of the
mobile by a third party. In the context of PMIPv6, MAG sends the
binding update to LMA on behalf of the mobile.
Local Mobility Agent (LMA): Local mobility agent is the local home
agent that is responsible to maintain the binding cache of the
mobile when the mobile's movement is confined to a domain. LMA
actually does the job of a Home Agent, and thus can be used
interchangeably in the document.
Media Access Gateway: MAG is the first hop access router that is
equipped with the Proxy Mobility Agent (PMA). MAG sends the proxy
binding update on behalf of the mobile. MAG stores the binding
cache entry created by Correspondent Binding Update (CBU) message,
so that it can forward the traffic to the neighboring MAG without
sending it to HA (LMA). MAG has been used interchangeably with
AGW in the document.
Access Gateway (AGW): AGW is the first hop access router that is
equipped with the Proxy Mobility Agent (PMA). AGW sends the proxy
binding update on behalf of the mobile. AGW been used
interchangeably with MAG in this draft.
Proxy Mobility Agent (PMA): PMA is the proxy mobility agent that
resides in each of the access routers that are within a mobility
domain. PMA helps to send proxy binding update to LMA on behalf
of the mobile.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 5]
Internet-Draft PMIP Route Optimization July 2008
Correspondent Binding Update:
Binding update message that updates the route in the neighboring
MAGs for route optimization. This CBU update can be between the
LMA and MAG or between the MAGs. This helps to update the route
cache on the AGWs, so that they can route the packet based on
mobile's destination.
Correspondent Binding Cache:
Correspondent Binding Cache (CBC) is formed at the MAGs when
Correspondent Binding Update (CBU) message is received from the
LMA or other MAG. CBC usually has associated timer that helps it
to expire after a while.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 6]
Internet-Draft PMIP Route Optimization July 2008
3. Applicable Scenarios for Route Optimization
In this section, two PMIP-based scenarios are described where the
route optimization technique can be applied. This can primarily be
divided as Intra-LMA and Inter-LMA. The proposed route optimization
technique can be applied to both of these scenarios.
Figure 1 shows a general PMIP architecture with all the PMIPv6
components. In this case the MAGs do not need to be adjacent to each
other but can be connected to a core network and thus can be few hops
away. Similarly, MAG and LMA also do not need to be adjacent. Route
optimization technique offers the best advantage when the LMA is far
way from the communicating hosts.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 7]
Internet-Draft PMIP Route Optimization July 2008
+-----------+
| |
| LMA |
| |
+-----|-----+
|
|
|
|
|
-----|-----
/// \\\
// \\
| |
| BACKBONE |
| Network |
/\ \/
/ \\\ /// \
/ -----|----- \
/ | \
/ | \
/ | \
/ | \
/ | \
+-----------+ +----------+ +---------+
| | | | | |
| MAG1 | | MAG2 | |MAG3 |
| | | | | |
+-----------+ +----------+ +---------+
+-----+ +------+ +-------+
| | | | | |
| MN1 | | MN2 |--------->| MN2 |
+-----+ +------+ +-------+
Figure 1: Intra LMA Scenario
Figure 2 shows a scenario where both the mobiles are in two different
PMIP domains. MAG1, MAG2, MAG3 are under LMA1 and MAG4, MAG5 and
MAG6 are under LMA2. In this case, route optimization needs to take
place when the mobile is in under MAG4 and then it makes a movement
to MAG5.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 8]
Internet-Draft PMIP Route Optimization July 2008
-------
/// \\\
| |
/ Core \
// \\\ /// \\
PMIP domain 1 / ------- \ PMIP domain 2
// \
/ \\
// \
+----/----+ +---\-----+
| | | |
| | | |
| LMA1 | | LMA2 |
| | | |
+----|----+ +----|----+
| |
| |
| |
| |
| |
--|---- -|-----
/// \\\ /// \\\
| Core |------------------| Core |
| | | |
\\\ /// \\\ ///
/---|---\ /---|---\
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
+------+ +-----+ +-----+ +-----+ +-----+ +----+
| | | | | | | | | | | |
| MAG1 | |MAG2 | |MAG3 | |MAG4 | |MAG5 | |MAG6|
+------+ +-----+ +-----+ +-----+ +-----+ +----+
+----+ +----+
+----+ | | | |
| | |MN2 +---->|MN2 |
| MN1| +----+ +----+
+----+
Figure 2: Inter LMA scenario
In the next section, the route optimization technique and associated
flows are described for the hosts when they operate within a single
Dutta (Ed.), et al. Expires January 14, 2009 [Page 9]
Internet-Draft PMIP Route Optimization July 2008
and multiple PMIP domains.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 10]
Internet-Draft PMIP Route Optimization July 2008
4. Route Optimization Techniques
In this section, a light weight route optimization technique for
PMIPv6 is described that can be applied it to both Intra-LMA and
Inter-LMA scenarios. This route optimization technique takes
advantage of the initial data packet to set the route optimization
without the need for any additional route setup procedures.
4.1. Intra-LMA route optimization
In this section intra-LMA scenarios are described. Route
optimizations for data between MN1 and MN2 in both directions are
illustrated.
4.1.1. Initial State
In this section several call flows for intra-LMA route optimization
are discussed.
4.1.1.1. Route Optimization from MN1 to MN2
Figure 3 shows the flows associated with the route optimization when
a single LMA is used. It shows the route optimization scenario when
the mobile is in the initial stage and has not moved. Initially, MN1
is under MAG1 and MN2 is under MAG2, but MN2 moves to MAG3 when the
communication session is active.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 11]
Internet-Draft PMIP Route Optimization July 2008
+-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | |
| MN1 | | MN2 | |MAG1 | |MAG2 | | LMA |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| network attachment | ProxyBU(MN1,MAG1) |
|<----------------------->|<------------------------>|
| | | | |
| | network attachment | |
| |<----------------------->|------------>|
| | | | |
| | | | |
| data(MN1->MN2) | | |
|------------+----------->| | |
| | | | |
| | | data(MN1->MN2) |
| | |------------------------->|
| | | | |
| | | CB update(MN2, MAG2) |
| | |<-------------------------|
| | | | |
| | | |data(MN1->MN2)
| | | |<------------|
| | | | |
| | data(MN1->MN2) | |
| |<------------------------| |
| | | | |
| data (MN1->MN2) | | |
|------------------------>| | |
| | | | |
| | |data(MN1->MN2) |
| | |----------->| |
| | | | |
| | data(MN1->MN2) | |
| |<------------------------| |
| | | | |
| | | | |
Figure 3: Route optimization in Single LMA:Initial State
Path optimization from MN1 to MN2 are described here. Before the
handover takes place, MN1 attaches to MAG1 (MAG1) and then the Proxy
Mobility Agent within MAG1 sends a binding update to the LMA on
behalf of MN1. Similarly, MN2 connects to MAG2 (PMA2), that triggers
the proxy-BU to the LMA on behalf of MN2. We then show the
optimization procedure. First packet from MN1 to MN2 is tunneled to
the LMA. As soon as the LMA gets this packet, it knows how to
forward packet to MAG2, but at the same time, it also sends a CB
Update (CBU) to MAG1 notifying that MAG2 is the PMA for MN2. On
Dutta (Ed.), et al. Expires January 14, 2009 [Page 12]
Internet-Draft PMIP Route Optimization July 2008
receiving the CBU, MAG1 keeps a cache that maps MAG2 with MN2. Thus,
any subsequent packet from MN1 destined to MN2 gets intercepted by
MAG1 and is forwarded to MAG2, instead of being forwarded to the LMA.
Trajectory of the optimized packet looks like, MN1->MAG1->MAG2->MN2
instead of MN1->MAG1->LMA->MAG2->MN2, thus optimizing the media route
between MN1 and MN2.
4.1.1.2. Optimization from MN2 to MN1
Similarly, Figure 4 shows the path optimization from MN2 to MN1 when
the MN2 is in the initial stage and has not handed over yet. This
illustrates how this route optimization technique can be applied to
optimize media traffic in either direction.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 13]
Internet-Draft PMIP Route Optimization July 2008
+-----+ +-----+ +-----+ +-----+ +------+
| | | | | | | | | |
| MN1 | | MN2 | |MAG1 | |MAG2 | | LMA |
+--+--+ +--+--+ +--+--+ +--+--+ +---+--+
| | | | |
| | data(MN2->MN1) | |
| |------------------------>| |
| | | |data(MN2->MN1)|
| | | |------------->|
| | | | |
| | | CB update(MN1,MAG1)
| | | |<-------------|
| | | | |
| | | data(MN2->MN1) |
| | |<--------------------------|
| data (MN2->MN1) | | |
|<------------------------| | |
| | | | |
| | | | |
| | data(MN2->MN1) | |
| +------------------------->| |
| | | | |
| | | | |
| | |data(MN2->MN1) |
| | |<-----------| |
| | | | |
| data(MN2->MN1) | | |
|<------------------------| | |
| | | | |
| | | | |
Figure 4: Route optimization from MN2 to MN1
4.1.2. Route Optimization after handoff
In this section, we illustrate how the route optimization takes place
after the mobile moves to another AGW (MAG3) under the same LMA
(LMA1). We consider the media delivery from both MN1 to MN2 and
vice-versa.
4.1.2.1. Route optimization from MN1 to MN2
In this section, we show how the media route is optimized from MN1 to
MN2, after MN2 moves from its current location.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 14]
Internet-Draft PMIP Route Optimization July 2008
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | |
| MN1 | | MN2 | |MAG1 | |MAG2 | |MAG3 | | LMA |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | network attachment (handover) | proxy-BU |
| |<------------------------------>|--------->|
| | | | | |
| | | | CB update(MN2,MAG3)
| | | |<--------------------|
| | | | | |
| data(MN1 -> MN2) | | | |
|-------------------->| | | |
| | | | | |
| | |data(MN1->MN2) | |
| | |--------->| | |
| | | | | |
| | |CB update(MN2,MAG3) | |
| | |<---------| | |
| | | | | |
| | | |data(MN1->MN2) |
| | | |--------->| |
| | | | | |
| | data(MN1->MN2) | |
| |<-------------------------------| |
| | | | | |
| data(MN1->MN2) | | | |
|-------------------->| | | |
| | | | | |
| | | data(MN1->MN2) | |
| | |-------------------->| |
| | | | | |
| | data(MN1->MN2) | |
| |<-------------------------------| |
| | | | | |
| | | | | |
Figure 5: Single LMA: Route Optimization after handoff
Figure 5 shows the flow when MN2 makes a handover from MAG2 to MAG3.
It shows the route optimization procedure and optimized route from
MN1 to MN2 after MN2 hands over to a new PMA such as MAG3. In this
case, MN2 attaches with MAG3 and sends a proxy BU to LMA. At that
point, LMA immediately sends a Correspondent Binding Update to MAG2,
since the LMA has the knowledge of MAG2. MAG2 in turn sends a proxy
BU to MAG1 telling that MN2 is under MAG3. Thus, both MAG1 and MAG2
are made aware of the fact that MN2 is currently connected to MAG3.
During this procedure if any data from MN1 destined to MN2 arrives at
MAG1, MAG1 forwards it to MAG2 which in turn forwards it to MAG3.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 15]
Internet-Draft PMIP Route Optimization July 2008
MAG3 finally forwards it MN2. But once the route optimization
procedure is over, any data destined from MN1 to MN2 gets intercepted
by MAG1 and then directly gets forwarded to MAG3 which forwards it
again to MN2.
4.1.2.2. Route Optimization from MN2 to MN1
In this section, we show how data path is optimized between MN2 and
MN1 after the MN2 has handed over to MAG3 during communication
session.
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | |
| MN1 | | MN2 | |MAG1 | |MAG2 | |MAG3 | | LMA |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | | |
| | | | | |
| | |data (MN2->MN1) | |
| |------------------------------->| |
| | | | data(MN2->MN1)
| | | | |--------->|
| | | | | |
| | | | CB update(MN1,MAG1)
| | | | |<---------|
| | | | | |
| | | | | |
| | |data (MN2->MN1) | |
| | |<-------------------------------|
| data(MN2->MN1) | | | |
|<--------------------| | | |
| | | | | |
| | |data (MN2->MN1) | |
| |------------------------------->| |
| | | | | |
| | | data(MN2->MN1) | |
| | |<--------------------| |
|data (MN2->MN1) | | | |
|<--------------------| | | |
| | | | | |
Figure 6: Call Flow for data path MN2 to MN1
Figure 6 shows the route optimization procedure when the data is
destined from MN2 to MN1 after the handover. After the route
optimization is over, data from MN2 destined to MN1 gets picked up by
MAG3 which finally sends to the MAG1 to be delivered to MN1. During
Dutta (Ed.), et al. Expires January 14, 2009 [Page 16]
Internet-Draft PMIP Route Optimization July 2008
the route optimization procedure, however the first packet gets
routed via LMA and is subjected to little delay. These techniques
thus avoid the route from LMA to AGWs (MAGs) and forward the traffic
from one AGW (MAG) to another AGW (MAG). However the first packet is
not subjected to route optimization.
4.2. Inter-LMA route optimization
4.2.1. Initial state
In this section, we describe the route optimization procedure when
the communicating mobiles are under two different LMA domains.
Figure 7 shows a typical inter-LMA handoff procedure. Initially, the
mobile is anchored at MAG1 (MAG1) that is under LMA1, and MN2 is
anchored at MAG4 which is under LMA2. First packet from MN1 to MN2
traverses via LMA1 and LMA2, and gets delivered to MN2. When the
first packet is traversed, LMA2 sends Correspondent Binding Update
message to LMA1, LMA1 in turn sends it back to MAG1 to update the
binding cache entry. At this point MAG1 keeps a cache entry for MN2.
Thus any subsequent packet does not travel via LMA1 and LMA2 any more
but is forwarded from MAG1 to MAG4 where the mobile resides. Thus,
any further data packet during this communication session is
optimized until the mobile moves away from MAG4.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 17]
Internet-Draft PMIP Route Optimization July 2008
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | |
| MN1 | |MAG1 | |LMA1 | | MN2 | | MAG4| | LMA2|
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | | |
|Network | | | | |
|Attachment| | | | |
|<-------->| | | | |
| |Proxy-BU(MN1,MAG1) |Network | |
| |--------->| |Attachment |
| | | |<------->| |
| | | | Proxy-BU(MN2,MAG2)
| | | | |--------->|
| | | | | |
| data (MN1->MN2) | | | |
|-------------------->| | | |
| | | | | |
| | | |data (MN1->MN2) |
| | |------------------------------>|
| | | | | |
| | | | |data(MN1->MN2)
| | | | |<---------|
| | | | | |
| | | |data(MN1->MN2) |
| | | |<--------| |
| | | | | |
| | | CB update (MN2,MN1,MAG4) |
| | |<------------------------------|
| | | | | |
| |CB update(MN2,MAG4) | | |
| |<---------| | | |
| | | | | |
|data(MN1->MN2) | | | |
|--------->| | | | |
| | | | | |
| | |data(MN1->MN2) | |
| |------------------------------>| |
| | | | | |
| | | |data(MN1->MN2) |
| | | |<---------| |
| | | | | |
| | | | | |
Figure 7: Inter-LMA route optimization before handoff
Dutta (Ed.), et al. Expires January 14, 2009 [Page 18]
Internet-Draft PMIP Route Optimization July 2008
4.2.2. Route optimization after handoff
This section shows the route optimization procedure after the mobile
has handed over to MAG5 that is under LMA2. Figure 8 shows the call
flow of the route optimization procedure. As soon as the mobile gets
connected to MAG5, LMA2 gets notified and it sends a CB update to
MAG4 notifying that the mobile is under MAG5. Thus the first packet
after the handover still flows from MAG1 to MAG4 that forwards this
packet to MAG5, MAG5 in turn delivers the packet to MN2. As it is
shown the path is not optimized. At this time, MAG4 notifies MAG1
about the existence of MN2 under its attachment. Thus, any
subsequent packet from MN1 and MN2 flows using the route optimized
path, MN1->MAG1->MAG5->MN2.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 19]
Internet-Draft PMIP Route Optimization July 2008
+-----+ +-----+ +-----+ +-----+ +-----+ +-----+ +-----+
| | | | | | | | | | | | | |
| MN1 | | MAG1| |LMA1 | |MN2 | |MAG4 | |MAG5 | |LMA2 |
+--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+ +--+--+
| | | | | | |
| | | | | | |
| | | |Network Attachment (handover)|
| | | |------------------>| |
| | | | | | |
| | | | | |Proxy-BU |
| | | | | |-------->|
| | | | | | |
| | | | | CB update(MN2,MAG5)
| | | | |<------------------|
| | | | | | |
|data(MN1->MN2) | | | | |
|-------->| | | | | |
| | data (MN1->MN2) | | |
| |---------------------------->| | |
| | | | | | |
| | | | |data(MN1->MN2) |
| | | | |-------->| |
| | | | | | |
| | CB update(MN2,MAG5,MN1) | | |
| |<----------------------------| | |
| | | | | | |
| | | | data (MN1->MN2) | |
| | | |<------------------| |
| | | | | | |
|data(MN1->MN2) | | | | |
|-------->| | | | | |
| | | data(MN1->MN2) | | |
| |-------------------------------------->| |
| | | | | | |
| | | | data(MN1->MN2) | |
| | | |<------------------| |
| | | | | | |
| | | | | | |
Figure 8: Inter-LMA route optimization after handoff
It is to be noted that Inter-LMA CBU needs to carry the IP address of
the source and destination hosts in addition to the address of source
MAG. This is needed as the LMA1 needs to determine which MAG it
needs to send the CBU back. Thus, new mobility option type needs to
be added to the CBU message.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 20]
Internet-Draft PMIP Route Optimization July 2008
5. Message Format
In this section, we describe the message format for the Correspondent
Binding Update (CBU) message.
5.1. Correspondent Binding Update Message
In order to make the optimization technique light weight and
compatible with the existing Binding Update messages, a slight
extension of the existing Proxy Binding Update method is proposed to
take care of route optimization. In order to differentiate
Correspondent Binding Update (CBU) message from the regular Proxy
Binding Update (PBU), a new flag "C" is suggested to be added in the
existing BU message. Also, Inter-LMA CBU needs to include additional
addresses such as the source address, destination address and
destination MAG address. Thus, new mobility option may type need to
be defined to carry these IP address prefix (MN-Prefix, CN-Prefix)
and MAG address. Alternatively, MAG address may be contained in
Alternate care-of-Address option. These prefixes may also be sent
using HNP option as well. A sample message format is shown in figure
9.
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 # |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
|A|H|L|K|M|R|P|C| Reserved | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| |
. .
. Mobility options .
. .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 9: CBU Message Format
A new flag (C) is included in the Proxy Binding Update message format
to indicate that this is Corresponding Binding Update message.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 21]
Internet-Draft PMIP Route Optimization July 2008
5.2. Correspondent Binding Acknowledgement
In order to acknowledge the CBU, the Correspondent Binding
Acknowledgement (CBA) message is used. The message format is
identical to the PBA message, but a new flag (C) is included to
distinguish from the PBA. A sample binding update message is shown
in Figure 10.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Status |K|R|P|C|Resv'd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sequence # | Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
. .
. Mobility options .
. .
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: CBA Message Format
Dutta (Ed.), et al. Expires January 14, 2009 [Page 22]
Internet-Draft PMIP Route Optimization July 2008
6. Security Considerations
The CB update (CBU) messages need to be secured. Since mobile's
movement is constrained within a domain, these route optimization
update messages can use the existing security mechanism that is in
place as part of ProxyMIP deployment. It is assumed that there is
standard security mechanism in place between the MAGs (Media Access
Gateway) and between MAG and LMA. Thus, the CB update messages can
be protected accordingly.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 23]
Internet-Draft PMIP Route Optimization July 2008
7. IANA Considerations
TBD
Dutta (Ed.), et al. Expires January 14, 2009 [Page 24]
Internet-Draft PMIP Route Optimization July 2008
8. Acknowledgments
Authors acknowledge the useful discussion with Dana Chee.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 25]
Internet-Draft PMIP Route Optimization July 2008
9. References
9.1. Normative References
[RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based
Localized Mobility Management (NETLMM)", RFC 4832,
April 2007.
[RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility
Management (NETLMM)", RFC 4831, April 2007.
[RFC4830] Kempf, J., "Problem Statement for Network-Based Localized
Mobility Management (NETLMM)", RFC 4830, April 2007.
[I-D.ietf-netlmm-proxymip6]
Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6",
draft-ietf-netlmm-proxymip6-18 (work in progress),
May 2008.
9.2. Informative References
[I-D.jeong-netlmm-pmipv6-roreq]
Jeong, S., Vogt, C., Wakikawa, R., Liebsch, M., Sugimoto,
S., and B. Sarikaya, "Problem Statement and Requirements
for Route Optimization in PMIPv6",
draft-jeong-netlmm-pmipv6-roreq-01 (work in progress),
November 2007.
[I-D.qin-netlmm-pmipro]
Sarikaya, B., Qin, X., Huang, A., and W. Wu, "PMIPv6 Route
Optimization Protocol", draft-qin-netlmm-pmipro-00 (work
in progress), February 2008.
[I-D.abeille-netlmm-proxymip6ro]
Liebsch, M., Le, L., and J. Abeille, "Route Optimization
for Proxy Mobile IPv6",
draft-abeille-netlmm-proxymip6ro-01 (work in progress),
November 2007.
Dutta (Ed.), et al. Expires January 14, 2009 [Page 26]
Internet-Draft PMIP Route Optimization July 2008
Authors' Addresses
Ashutosh Dutta
Telcordia Technologies
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 3130
Email: adutta@research.telcordia.com
Subir Das
Telcordia Technologies
1 Telcordia Drive
Piscataway, NJ 08854
USA
Phone: +1 732 699 2483
Email: subir@research.telcordia.com
Hidetoshi Yokota
KDDI Labs
2-1-15 Ohara
Fujimono, Saitama 356-8502
Japan
Phone:
Email: yokota@kddilabs.jp
Tsunehiko Chiba
KDDILab
2-1-15 Ohara
Fujimino, Saitama 356-8502
Japan
Phone:
Email: t-chiba@kddilabs.jp
Dutta (Ed.), et al. Expires January 14, 2009 [Page 27]
Internet-Draft PMIP Route Optimization July 2008
Henning Schulzrinne
Columbia University
Department of Computer Science
450 Computer Science Building
New York, NY 10027
USA
Phone: +1 212 939 7004
Email: hgs@cs.columbia.edu
Dutta (Ed.), et al. Expires January 14, 2009 [Page 28]
Internet-Draft PMIP Route Optimization July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Dutta (Ed.), et al. Expires January 14, 2009 [Page 29]