NetExt Working Group M. Liebsch, Ed.
Internet-Draft NEC
Intended status: Informational S. Jeong
Expires: September 15, 2011 ETRI
Q. Wu
Huawei
March 14, 2011
PMIPv6 Localized Routing Problem Statement
draft-ietf-netext-pmip6-lr-ps-06.txt
Abstract
Proxy Mobile IPv6 is the IETF standard for network-based mobility
management. In Proxy Mobile IPv6, mobile nodes are topologically
anchored at a Local Mobility Anchor, which forwards all data for
registered mobile nodes. The setup and maintenance of localized
routing, which allows forwarding of data packets between mobile nodes
and correspondent nodes directly without involvement of the Local
Mobility Anchor in forwarding, is not considered. This document
describes the problem space of localized routing in Proxy Mobile
IPv6.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on September 15, 2011.
Copyright Notice
Copyright (c) 2011 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
Liebsch, et al. Expires September 15, 2011 [Page 1]
Internet-Draft PMIPv6 Localized Routing PS March 2011
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Problem Statement for Localized Routing in PMIPv6 . . . . . . 5
3.1. General Observation . . . . . . . . . . . . . . . . . . . 5
3.2. Use Cases Analysis . . . . . . . . . . . . . . . . . . . . 6
3.3. IPv4 Considerations . . . . . . . . . . . . . . . . . . . 8
3.3.1. Localized Routing for Communication between IPv4
Home Addresses . . . . . . . . . . . . . . . . . . . . 8
3.3.2. IPv4 Transport Network Considerations . . . . . . . . 9
4. Functional Requirements for Localized Routing . . . . . . . . 10
5. Roaming Considerations . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . . 16
Appendix A. Change Notes . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Liebsch, et al. Expires September 15, 2011 [Page 2]
Internet-Draft PMIPv6 Localized Routing PS March 2011
1. Introduction
The IETF has specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as the
base protocol for network-based localized mobility management
(NetLMM). The scope of the base protocol covers the set up and
maintenance of a tunnel between an MN's Mobile Access Gateway (MAG)
and its selected Local Mobility Anchor (LMA). Data packets will
always traverse the MN's MAG and its LMA, irrespective of the
location of the MN's remote communication endpoint. Even though an
MN may be attached to the same or a different MAG as its
Correspondent Node (CN) within the same provider domain, packets
being associated with their communication will traverse the MN's and
the CN's LMA. [RFC5213] addresses the need to enable local routing
of traffic between two nodes being attached to the same MAG, but does
not specify the complete procedure to establish such localized
routing state on the shared MAG.
The NetLMM Extensions (NetExt) Working Group has an objective to
design a solution for localized routing in PMIPv6. This includes the
specification of protocol messages and associated protocol operation
between PMIPv6 components to support the setup of a direct routing
path for data packets between the MN's and the CN's MAG. As a result
of localized routing, these packets will be forwarded between the two
associated MAGs without traversing the MN's and the CN's LMA(s). In
case one or both nodes hand over to a different MAG, the localized
routing protocol maintains the localized routing path. Relevant
protocol interfaces may include the interface between associated
MAGs, between a MAG and an LMA as well as between LMAs.
This document analyzes and discusses the problem space of using
always the default route through two communicating mobile nodes'
local mobility anchors. Furthermore, the problem space of enabling
localized routing in PMIPv6 is analyzed and described, while
different communication and mobility scenarios are taken into
account.
Liebsch, et al. Expires September 15, 2011 [Page 3]
Internet-Draft PMIPv6 Localized Routing PS March 2011
2. Conventions and Terminology
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].
This document uses the terminology of [RFC5213]. The following terms
are used in the context of this problem statement:
o Mobile Node (MN): Mobile Node without IP mobility support, which
is attached to a Mobile Access Gateway (MAG) and registered with a
Local Mobility Anchor (LMA) according to the PMIPv6 specification
[RFC5213].
o Correspondent Node (CN): Correspondent Node according to its
definition in [RFC3775] with or without IP mobility support. The
CN represents the communication peer of an MN, which is attached
to a MAG and registered with an LMA according to the PMIPv6
specification.
o Localized Routing: Result of signaling to set up routing states on
relevant network entities to allow forwarding of data packets
between an MN and a CN, which are attached to MAGs sharing the
same provider domain, without intervention of the MN's LMA and the
CN's LMA in data forwarding.
o Localized Routing States: Information for localized routing on
relevant forwarding entities on the optimized data path between an
MN and a CN. Such information includes route entries and tunnel
endpoints and may include further information about the MN and the
CN, such as the communicating nodes' Mobile Node Identifier and
their assigned Home Network Prefix.
o Provider Domain: A network domain in which network components are
administered by a single authority, e.g. the mobile operator.
Liebsch, et al. Expires September 15, 2011 [Page 4]
Internet-Draft PMIPv6 Localized Routing PS March 2011
3. Problem Statement for Localized Routing in PMIPv6
3.1. General Observation
The Mobile IPv6 (MIPv6) protocol [RFC3775] has built-in mechanisms
for direct communication between an MN and a CN. Mechanisms for
route optimization in MIPv6 cannot be directly applied in PMIPv6.
Following the paradigm of PMIPv6, MNs are not involved in mobility
signaling, hence cannot perform signaling to set up localized routes.
Instead, the solution for localized routing must consider functions
in the network to find out whether or not a localized route is to be
used and then control the setup and maintenance of localized routing
states accordingly without any assistance from the MN and the CN. In
case of communication between two nodes, which are attached to the
PMIPv6 network infrastructure and each node is registered with an
LMA, data packets between these two nodes will always traverse the
responsible LMA(s). At least some deployment would benefit from
having such communication localized, rather than traverse the core
network to the LMA(s). In the context of this document, such
localized communication comprises offloading traffic from LMAs and
establish an optimized forwarding path between the two communication
endpoints.
Localized routing is understood in [RFC5213] as optimization of
traffic between an MN and a CN that are attached to an access link
connected to a same MAG. In such case, the MAG forwards traffic
directly between the MN and the CN, assuming the MAG is enabled to
support this feature (setting of the EnableMAGLocalRouting flag on
the MAG) and the MN's LMA enforces this optimization. [RFC5213] does
not specify how an LMA can enforce optimization for such local
communication. Maintaining local forwarding between the MN and the
regular IPv6 CN gets more complex in case the MN performs a handover
to a different MAG. Such use case is not considered in the
specification and out of scope of this problem statement. This
document focuses on use cases, where both nodes, the MN and the CN,
are within a PMIPv6 network and served by an LMA in a domain of LMAs.
Localized routing is relevant at least for the following two reasons:
First, by limiting the communication to the access nodes, the data
traffic traversing the MAG - LMA path (network) can be reduced. This
is significant considering that the transport network between the
access and the core is often the bottleneck in terms of costs and
performance. Second, there may be performance benefits for data
flows between the MN and the CN in terms of delay and packet loss,
especially when the MN and the CN are attached to the same MAG and
the LMA is topologically far away from that MAG. Even when the MN
and the CN are attached to different MAGs, there could be benefit in
limiting the communication to the access network only, rather than
Liebsch, et al. Expires September 15, 2011 [Page 5]
Internet-Draft PMIPv6 Localized Routing PS March 2011
traversing the transport network to the LMA. Furthermore, offloading
traffic from the LMA by means of localized routing can improve
scalability of the LMA, as it represents a bottleneck for traffic
being forwarded by many MAGs. Hence, providing the necessary
protocol specification to enable localized routing in PMIPv6 is
strongly recommended.
3.2. Use Cases Analysis
This problem statement focuses on local communication between PMIPv6
managed nodes, which attach to MAGs sharing the same provider domain.
The following list analyzes different use cases, which consider the
existence of multiple LMAs. Figure 1 depicts a PMIPv6-based network
with two mobility anchors. According to [RFC5213], the MN moves in
the PMIPv6 domain being built by its LMA and MAG. The same applies
to the CN, which moves in the PMIPv6 domain built by the CN's LMA and
MAG. The analysis takes no assumption on whether the MN and the CN
share the same PMIPv6 domain or not.
Internet Backbone
: :
+------------------+
| |
+----+ +----+
|LMA1| |LMA2|
+----+ +----+
| |
| |
+----+------------------+----+
| |
+----+ +----+
|MAG1| |MAG2|
+----+ +----+
: : :
+---+ +---+ +---+
|MN | |CN1| |CN2|
+---+ +---+ +---+
Figure 1: Reference architecture for localized routing in PMIPv6
All use cases A assume that both the MN and the CN are registered
with an LMA according to the PMIPv6 protocol. Whereas MAG1 is always
considered as the MN's current Proxy Care-of Address, the CN can be
either connected to the same or a different MAG or LMA as the MN.
Accordingly, these topological differences are denoted as follows:
Liebsch, et al. Expires September 15, 2011 [Page 6]
Internet-Draft PMIPv6 Localized Routing PS March 2011
A[number of MAGs][number of LMAs]
A11: MN and CN (CN1) connect to the same MAG (MAG1) and are
registered with the same LMA (LMA). The common MAG may forward
data packets between the MN and the CN directly without forwarding
any packet to the LMA. [RFC5213] addresses this use case, but
does not specify the complete procedure to establish such
localized routing state on the shared MAG.
A12: MN and CN (CN1) connect to the same MAG (MAG1) and are
registered with different LMAs (LMA1 and LMA2). The common MAG
may forward data packets between the MN and the CN directly
without forwarding any packet to the LMAs. Following the policy
of [RFC5213] and enforcement of the setup of a localized
forwarding path, potential problems exist in case LMA1 and LMA2
differ in their policy to control the MAG.
A21: The CN (CN2) connects to a different MAG (MAG2) as the MN
(MAG1), but MN and CN are registered with the same LMA (LMA1).
The result of localized routing should be the existence of routing
information at MAG1 and MAG2, which allows direct forwarding of
packets between the MN's MAG1 and the CN's MAG2. As LMA1 is the
common anchor for MN and CN and maintains location information for
both nodes, no major race condition and instability in updating
the states for localized routing is expected.
A22: The CN (CN2) connects to a different MAG (MAG2) and a different
LMA (LMA2) as the MN (MAG1, LMA1). The result of localized
routing should be the existence of routing information at MAG1 and
MAG2, which allows direct forwarding of packets between the MN's
MAG1 and the CN's MAG2. As the location information of the CN and
the MN is maintained at different LMAs, both LMAs need to be
involved in the procedure to set up localized routing. In case of
a handover of the MN and/or the CN to a different MAG, not
synchronized control of updating the states for localized routing
may result in race conditions, superfluous signaling and packet
loss.
The following list summarizes general problems with setting up and
maintaining localized routing between an MN and a CN. In the context
of this problem statement, the MN and the CN are always assumed to be
registered at an LMA according to the PMIPv6 protocol [RFC5213].
o MNs do not participate in mobility management, hence cannot
perform binding registration at a CN on their own. Rather
entities in the network infrastructure must take over the role of
MNs to set up and maintain a direct route. Accordingly, a
solution for localized routing in PMIPv6 must specify protocol
Liebsch, et al. Expires September 15, 2011 [Page 7]
Internet-Draft PMIPv6 Localized Routing PS March 2011
operation between relevant network components, such as between a
MAG and an LMA, to enable localized routing for data traffic
without traversing the MNs' LMA(s).
o In case the MN and the CN are both registered with different LMAs
according to the PMIPv6 protocol, relevant information for the set
up of a localized routing path, such as the current MAG of the MN
and the CN, is distributed between these LMAs. This may
complicate the setup and stable maintenance of states enabling
localized routing.
o In case localized routing between an MN and a CN has been
successfully set up and both nodes move and attach to a new access
router simultaneously, signaling the new location and maintenance
of states for localized routing at relevant routers may run into a
race condition situation. This can happen in case coordination of
signaling for localized routing and provisioning of relevant state
information is distributed between different network entities,
e.g. different LMAs. In such case, as a result of MN's handover,
updated information about the MN's location may arrive at the CN's
previous MAG while CN moved already to a new MAG. The same
applies to the other direction, where the system may update MN's
previous MAG about CN's new location while the MN has moved to a
new MAG in the meantime. The protocol solution must deal with
such exceptional handover cases efficiently to avoid or resolve
such problem.
3.3. IPv4 Considerations
According to [RFC5844], the basic configuration requirements for
supporting IPv4 in PMIPv6 are that LMAs and MAGs are both IPv4 and
IPv6 enabled. Also, LMAs and MAGs must have a globally unique IPv6
address configured, irrespective of enabled support for IPv6 routing
between these components. This requirement should also apply to
configuration requirements of localized routing.
Additional issues emerge when localized routing is considered for
PMIPv6 with IPv4 support. These can be classified into two general
groups, which are issues with localized routing between an MN's and a
CN's IPv4 Home Addresses or transport plane issues. The following
subsections analyze these two groups.
3.3.1. Localized Routing for Communication between IPv4 Home Addresses
In case an LMA and a MAG hold a registration to support IPv4 Home
Address mobility for an MN, the MAG and the LMA must support
appropriate encapsulation of IPv4 packets. To enable localized
routing, the MN's MAG must encapsulate and forward routing path
Liebsch, et al. Expires September 15, 2011 [Page 8]
Internet-Draft PMIPv6 Localized Routing PS March 2011
optimized packets to the CN's MAG and needs to ensure, that the
chosen encapsulation mode is supported by the correspondent MAG.
Incompatibility in a selected encapsulation mode causes failure in
setting up a localized route.
When localized routing is used for IPv4 traffic, the conceptual data
structures on associated MAGs must be augmented with appropriate
parameters for forwarding localized traffic. MAGs may need to
maintain a routing state for each MN-CN-pair and make routing
decisions for uplink traffic based on the packets' complete IPv4
source and destination address. Hence, conceptual data structures to
handle states for localized routes need to comprise this address
tuple for unique identification.
As a known constraint, IPv4 addresses of two nodes, which hold
addresses from a private address space, may overlap. To uniquely
identify both nodes, the IPv4 address of the MN and the CN must not
overlap. To cope with overlapping address spaces, the localized
routing solution could use additional mechanisms to tag and uniquely
identify the MN and the CN.
3.3.2. IPv4 Transport Network Considerations
The transport network between LMA and MAG may be based on IPv6 or
IPv4. Deployments may ensure that the same transport mechanism
(i.e., IPv6 or IPv4) is used for operational consistency. Similar to
the encapsulation requirement stated in the previous section, the IP
version used for localized routing is also assumed, by configuration,
to be consistent across all MAGs within the associated provider
domain. The design of optional mechanisms for negotiating the IP
version to use as well as the encapsulation mode to use are outside
the scope of the NetExt WG's solution for localized routing.
Liebsch, et al. Expires September 15, 2011 [Page 9]
Internet-Draft PMIPv6 Localized Routing PS March 2011
4. Functional Requirements for Localized Routing
Several tasks need to be performed by the network infrastructure
components before relevant information for such direct communication
is discovered and associated states for localized routing can be set
up. The following list summarizes some key functions, which need to
be performed by the PMIPv6 enabled network infrastructure to
substitute mobile nodes in setting up a direct route.
o Detection of the possibility to perform localized routing. This
function includes looking at data packets' source and destination
address.
o Initiation of a procedure, which sets up a localized routing path.
o Discovery of stateful entities (i.e. the LMA(s) and/or the
MAG(s)), which maintain and can provide relevant information
needed to set up a localized routing path. Such information may
include the routable address of an LMA or MAG, where one or both
mobile nodes are connected to and registered with.
o Control in setting up and maintaining (e.g. during handover) the
localized routing path. Control is also needed to terminate the
use of a localized routing path and to delete associated states,
whereas a trigger for the termination may come from a non-PMIPv6
related component.
o Enforcement of administrative policy rules to localized routing.
Such policies allow operators to have further control on the set
up of a localized route and enable the possibility to disallow
localized routing, for example to ensure that traffic traverses
charging related functions on the LMA.
Liebsch, et al. Expires September 15, 2011 [Page 10]
Internet-Draft PMIPv6 Localized Routing PS March 2011
5. Roaming Considerations
Figure 2 shows PMIPv6 roaming cases where PMIPv6 components (e.g.,
LMAs, MAGs) tied by MN and CN may be distributed between different
provider domains (i.e., domain A, B, C) and MN and/or CN moves from
one provider domain to another one. In order to support localized
routing when roaming occurs, it is required that MAGs to which MN and
CN connect are within the same provider domain and each MAG has a
security relationship with the corresponding LMA which maintains the
registration of the MN or the CN, respectively.
According to the roaming model as depicted in Figure 2, MN's PMIPv6
domain is characterized by its MAG (MAG1/MAG1') and its LMA (LMA1),
whereas CN's PMIPv6 domain is characterized by CN's MAG (MAG2/MAG2')
and its LMA (LMA2/LMA2'). A solution for localized routing cannot
take any assumption about whether or not MN and CN share the same
PMIPv6 domain, hence MAG1/MAG1' may not share a security association
with LMA2/LMA2' and MAG2/MAG2' may not share a security association
with LMA1 respectively.
It is not required that LMAs, which hold the registration for the MN
and the CN respectively, are part of the same provider domain as the
MAGs where MN and CN attach. When MN's MAG and MN's LMA belong to
different provider domains (A and C), localized routing is subject to
policy governing the service level agreements between these domains.
The same applies to the provider domains which provide CN's MAG and
LMA. Based on the above requirements, four PMIPv6 roaming and non-
roaming cases can be taken into account.
o Case 1: MN's MAG (MAG1), CN's MAG (MAG2), MN's LMA (LMA1), CN's
LMA (LMA2) are located in the same provider domain A.
o Case 2: MN's MAG (MAG1), CN's MAG (MAG2), MN's LMA (LMA1) are
located in the same domain A while CN's LMA (LMA2') is located in
provider domain B.
o Case 3: MN's MAG (MAG1'), CN's MAG (MAG2') are located in domain C
while MN's LMA (LMA1) and CN's LMA (LMA2) are located in provider
domain A.
o Case 4: MN's MAG (MAG1'), CN's MAG (MAG2') are located in provider
domain C while MN's LMA (LMA1) is located in provider domain A,
and CN's LMA (LMA2) is located in provider domain B.
In these roaming cases, MN can be allowed to roam within its domain
(e.g, MN's home domain in which MN's LMA is located) or over
different domains (e.g., MN moves from its home domain to a visited
domain). During mobility, CN and MN should remain attached to MAGs
Liebsch, et al. Expires September 15, 2011 [Page 11]
Internet-Draft PMIPv6 Localized Routing PS March 2011
of the same provider domain to maintain efficient routing of traffic
between their MAGs.
|
+-----+ +-----+ | +-----+
|LMA1 | |LMA2 | | |LMA2'|
+-----+ +-----+ | +-----+
|
|
|
|
+-----+ +-----+ |
|MAG1 | |MAG2 | |
+-----+ +-----+ |
|
|
Provider Domain A | Provider Domain B
------------------------------+-------------------------------
Provider Domain C
+-----+ +-----+
|MAG1'| |MAG2'|
+-----+ +-----+
Figure 2: PMIPv6 roaming cases considered for Localized Routing
Liebsch, et al. Expires September 15, 2011 [Page 12]
Internet-Draft PMIPv6 Localized Routing PS March 2011
6. Security Considerations
A protocol solution for localized routing in a PMIPv6 network must
counter unauthorized change of a routing path. In particular, the
control plane for localized routing must preclude blocking or
hijacking of mobile nodes' traffic by malicious or compromised
network components. A security solution must support suitable
mechanisms for authentication of control plane components of the
localized routing functional architecture for both scenarios, roaming
and non-roaming. Any possibility for Internet hosts to interfere
with the localized routing procedure in a malicious manner must be
precluded.
Since network entities rather than MNs and CNs perform signaling to
set up localized routing, the MIPv6 return routability test [RFC3775]
is not suitable to authenticate associated signaling messages in
PMIPv6. Solutions for localized routing in PMIPv6 need to mitigate
or to provide sufficient defense against possible security threats.
When PMIPv6 participants are administered within the same domain,
infrastructure-based authorization mechanisms, such as IPsec, may be
usable to protect signaling for localized routing.
Existing security associations according to [RFC5213] can be re-used
to protect signaling for localized routing on the interface between a
MAG and an LMA. In case a protocol solution for localized routing in
PMIPv6 relies on protocol operation between MAGs, means for
protection of signaling between these MAGs must be provided. The
same applies for signaling on a possible protocol interface between
two LMAs of the same domain.
Liebsch, et al. Expires September 15, 2011 [Page 13]
Internet-Draft PMIPv6 Localized Routing PS March 2011
7. IANA Considerations
This document does not require any action from IANA.
Liebsch, et al. Expires September 15, 2011 [Page 14]
Internet-Draft PMIPv6 Localized Routing PS March 2011
8. Acknowledgments
Many aspects of the problem space for route optimization in PMIPv6
have been discussed in the context of a PMIPv6 Route Optimization
Design Goals document, which has been submitted to the NetLMM WG in
November 2007. This group of contributors includes Sangjin Jeong,
Christian Vogt, Ryuji Wakikawa, Marco Liebsch, Behcet Sarikaya,
Shinta Sugimoto, Long Le, Alice Qinxia and Jaehwoon Lee. Many thanks
to Rajeev Koodli for his comments about the structure and scope of
this problem statement for the NetExt WG.
This problem statement reflects the results of the discussion in the
NetExt group. Many thanks to Hidetoshi Yokota, Carlos Bernardos,
Ashutosh Dutta, Sri Gundavelli, Mohana Jeyatharan, Jouni Korhonen,
Glen Zorn, Dirk von Hugo, Frank Xia, Xiangsong Cui and Basavaraj
Patil for their comments and support to improve the quality of the
problem statement.
Liebsch, et al. Expires September 15, 2011 [Page 15]
Internet-Draft PMIPv6 Localized Routing PS March 2011
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008.
[RFC5844] Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", RFC 5844, May 2010.
9.2. Informative References
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Liebsch, et al. Expires September 15, 2011 [Page 16]
Internet-Draft PMIPv6 Localized Routing PS March 2011
Appendix A. Change Notes
Changes in version 01:
o Removed text about potential issues with IPv4 address conflict
from Section 3.3.1 (out of NetExt scope)
o Removed NAT issues from Section 3.3.2 (out of NetExt scope)
o Removed text about IP version and encapsulation mode negotiation
from 3.3.2 (out of NetExt scope)
Changes in version 02:
o Consistently refer to communication between MN and CN, not between
two MNs
o Adopt text to the result of the roaming model discussion and refer
to provider domain, not PMIPv6 domain
o Revision of Terms section according to comments
o Revision of text in Section 3.1 about network entities, which
perform signaling for localized routing (clarification)
o Revision of text in Section 3.1 to clarify about localized routing
benefits
o Revision of text in Section 3.2 to clarify about signaling race
condition in multi-LMA case
o Add more text to Section 5 about the roaming model for localized
routing, relevance of the PMIPv6 domain concept and associated
issues with localized routing in roaming case
o Modified heading of Section 3.3.1 to avoid confusion with
localized routing between IPv4 Proxy-CoAs
Changes in version 03:
o Editorial revision according to received comments
o IPv4 support reference updated from draft to RFC status
Changes in version 04:
Liebsch, et al. Expires September 15, 2011 [Page 17]
Internet-Draft PMIPv6 Localized Routing PS March 2011
o Editorial revision according to received and agreed comments
Changes in version 05:
o Editorial revision and clarification according to remaining
comments received during WG last call
Changes in version 06:
o Address AD comment to clarify 2nd paragraph of Section 3.1
o Include functional requirement about policy enforcement for
localized routing in Section 4
o Refer to localized routing specific security threats in the first
paragraph of Section 6
Liebsch, et al. Expires September 15, 2011 [Page 18]
Internet-Draft PMIPv6 Localized Routing PS March 2011
Authors' Addresses
Marco Liebsch (editor)
NEC Laboratories Europe
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg,
Germany
Phone: +49 6221 4342146
Email: liebsch@neclab.eu
Sangjin Jeong
ETRI
138 Gajeongno, Yuseong
Daejeon, 305-700
Korea
Phone: +82 42 860 1877
Email: sjjeong@etri.re.kr
Qin Wu
Huawei Technologies,Co.,Ltd
12F, Huihong Mansion,No.91,Baixia Rd.,
Nanjing, 210001
China
Phone: +86 21 84565892
Email: sunseawq@huawei.com
Liebsch, et al. Expires September 15, 2011 [Page 19]
