Network Working Group M. Liebsch
Internet-Draft NEC
Intended status: Informational S. Jeong
Expires: January 14, 2010 ETRI
Q. Wu
Huawei
July 13, 2009
PMIPv6 Localized Routing Problem Statement
draft-liebsch-netext-pmip6-ro-ps-01.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 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.
Liebsch, et al. Expires January 14, 2010 [Page 1]
Internet-Draft PMIPv6 Localized Routing PS July 2009
Abstract
Proxy Mobile IPv6 is the IETF standard for network-based localized
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 set up 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4
3. Problem Statement for Localized Routing in PMIPv6 . . . . . . 5
4. IPv4 Considerations . . . . . . . . . . . . . . . . . . . . . 9
4.1. Localized Routing between IPv4 Home Addresses . . . . . . 9
4.2. IPv4 Transport Network Considerations . . . . . . . . . . 9
4.3. NAT Presence Issues . . . . . . . . . . . . . . . . . . . 10
4.4. IPv4 Address Space Overlapping Issues . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 13
Appendix A. Change Notes . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Liebsch, et al. Expires January 14, 2010 [Page 2]
Internet-Draft PMIPv6 Localized Routing PS July 2009
1. Introduction
The IETF has specified Proxy Mobile IPv6 (PMIPv6) [RFC5213] as the
base protocol for network-based localized mobility management
(NetLMM), which takes basic operation for registration, de-
registration and handover into account. In scope of the base
protocol is the set up and maintenance of a forwarding tunnel between
an MN's Mobility 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 two communicating MNs might be attached to the
same MAG or to different MAGs of the same local mobility domain,
packets will traverse the MNs' LMA(s).
Objectives of designing a solution for localized routing in PMIPv6
are to specify protocol messages and enable associated protocol
operation between PMIPv6 components to support the set up of a direct
routing path for data packets between the MNs' MAGs without
forwarding these packets through the MNs' LMA(s) and to maintain
localized routing in case one or both MNs handover to a different
MAG. 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 January 14, 2010 [Page 3]
Internet-Draft PMIPv6 Localized Routing PS July 2009
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 Mobility Access Gateway (MAG) and registered with
a Local Mobility Anchor (LMA) according to the PMIPv6
specification [RFC5213].
o Correspondent Node (CN): Correspondent Node 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 within a single PMIPv6 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 direct data path between an MN
and a CN. Such information includes route entries and may include
further information about the MN and the CN, such as IDs.
Liebsch, et al. Expires January 14, 2010 [Page 4]
Internet-Draft PMIPv6 Localized Routing PS July 2009
3. Problem Statement for Localized Routing in PMIPv6
The Mobile IPv6 (MIPv6) protocol [RFC3775] has built-in mechanisms
for direct communication between a MN and a CN. Mechanisms for route
optimization in MIPv6 cannot be directly applied in PMIPv6, as MNs do
not take part in mobility management and associated signaling.
Following the architecture of PMIPv6, rather entities of the network
infrastructure are dedicated to perform signaling to set up a more
direct route between an MN and a 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 a direct forwarding path
between the two communication endpoints.
Localized routing is understood in [RFC5213] as optimization of
traffic between a MN and a CN under the same access router, whereas
the MN connects to the MAG function of this access router and is
registered with an LMA, but the CN is a regular IPv6 node without
getting PMIPv6 service. 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 each registered with an LMA and both obtain PMIPv6 mobility
service.
Localized routing is crucial 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. And there are performance benefits in terms of delay
and packet loss, especially when the MNs are attached to the same MAG
and the LMA is topologically far away from that MAG. Even when the
MNs are attached to different MAGs, there could be benefit in
limiting the communication to the access network only, rather than
traversing the transport network to the LMA. Hence, providing the
necessary protocol specification to enable localized routing in
PMIPv6 is necessary.
Liebsch, et al. Expires January 14, 2010 [Page 5]
Internet-Draft PMIPv6 Localized Routing PS July 2009
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.
This problem statement focuses on local communication between PMIPv6
managed nodes within a single PMIPv6 domain. The following list
analyzes different use cases, which are limited to the communication
within a single PMIPv6 domain, but they consider the existence of
multiple LMAs. Figure 1 depicts the network of a PMIPv6 domain with
two mobility anchors.
Liebsch, et al. Expires January 14, 2010 [Page 6]
Internet-Draft PMIPv6 Localized Routing PS July 2009
Internet Backbone
: :
+------------------+
| | . . . . . .
+----+ +----+ ^
|LMA1| |LMA2| |
+----+ +----+ |
| | |
| | |PMIPv6
+----+------------------+-+ |domain
| | |
+----+ +----+ |
|MAG1| |MAG2| v
+----+ +----+ . . . .
: : :
+---+ +---+ +---+
|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 pCoA, the CN can be either connected
to the same or a different MAG or LMA as the MN. Accordingly, these
topological difference are denoted as follows:
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.
A12: MN and CN (CN1) connect to the same MAG (MAG1) and are
registered with different LMAs (LMA1 and LMA2) of the same PMIPv6
domain. 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 set up 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
Liebsch, et al. Expires January 14, 2010 [Page 7]
Internet-Draft PMIPv6 Localized Routing PS July 2009
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) in the same PMIPv6 domain. 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 MNs 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 within a PMIPv6
domain. 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
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 MAGs of the MN
and the CN, is distributed between these LMAs. This may
complicate the set up 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.
Liebsch, et al. Expires January 14, 2010 [Page 8]
Internet-Draft PMIPv6 Localized Routing PS July 2009
4. IPv4 Considerations
According to [I-D.ietf-netlmm-pmip6-ipv4-support], 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.
4.1. Localized Routing 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
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. Probably a capability exchange with
encapsulation mode selection or negotiation scheme between MAGs must
be supported to counteract such failure. Selection of an
encapsulation mode is not needed in case both nodes attach to the
same MAG, but needs to be performed each time a node hands over to a
different MAG.
MAGs must maintain a routing state for each MN-CN-pair and take
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.
4.2. IPv4 Transport Network Considerations
As stated in the beginning of Section 4, LMA and MAG are both IPv4
and IPv6 enabled when IPv4 is supported in PMIPv6. However, when
using IPv4 transport, it is not necessary to enable IPv6 routing
between LMA and MAG. Thus, the MN's MAG and the CN's MAG may use
different IP versions for the transport of PMIPv6 signaling messages
to the LMA. For example, it is possible that the MN's MAG supports
IPv4 home address mobility and IPv6 transport, whereas the CN's MAG
supports IPv4 home address mobility and IPv4 transport. In that
case, it is necessary that the MN's and CN's MAGs negotiate the IP
version for localized routing signaling and data forwarding.
When the MN hands over to a new MAG, the MAG may use a different IP
version for PMIPv6 signaling as the MN's previous MAG. In that case,
the new MAG may need to re-negotiate the IP version of the data
Liebsch, et al. Expires January 14, 2010 [Page 9]
Internet-Draft PMIPv6 Localized Routing PS July 2009
forwarding tunnel for localized routing and signaling or to restart
the localized routing procedure.
4.3. NAT Presence Issues
In [I-D.ietf-netlmm-pmip6-ipv4-support], packets originated from or
sent to a MN are routed by default through a bidirectional tunnel
between MAG and LMA and the presence of a NAT between MAG and LMA is
considered. Even though there may not be any NAT between the MAG and
the LMA, there may exist a NAT on the direct routing path between
MN's MAG and the CN's MAG or between the MN and CN's LMAs.
Therefore, NAT detection and traversal mechanisms should be utilized
during initializing localized routing procedures for IPv4 support.
4.4. IPv4 Address Space Overlapping Issues
As described in [I-D.ietf-netlmm-grekey-option], GRE keys being
encapsulated within tunneled packets can be used to distinguish each
MN's flow between the MAG and the LMA, even though two MNs may have
assigned the same HoA from an overlapping IPv4 address space managed
by each MN's operator. However, special care may be taken of a use
case where a packet from the CN is sent to two MNs which are assigned
the same IPv4 HoA and attach to the same MAG. If the packet does not
traverse the tunnel between the MN's MAG and its LMA but is forwarded
directly from the CN's MAG to the MN's MAG due to localized routing,
the MN's MAG may not be able to identify the MN to which the packet
must be delivered. Therefore, in this context there may be the need
to utilize some service differential mechanism to identify flows
being forwarded directly between MAGs.
Liebsch, et al. Expires January 14, 2010 [Page 10]
Internet-Draft PMIPv6 Localized Routing PS July 2009
5. Security Considerations
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 January 14, 2010 [Page 11]
Internet-Draft PMIPv6 Localized Routing PS July 2009
6. 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, Behcet Sarikaya, Shinta Sugimoto,
Long Le, Alice Qinxia and Jaehwoon Lee. Many thanks also to Rajeev
Koodli for his comments about the structure and scope of this problem
statement.
This version of the problem statement relects the results of the
discussion in the NetExt group based on the initial version of the
document. Many thanks to Hidetoshi Yokota, Carlos Bernardos,
Ashutosh Dutta, Sri Gundavelli and Jouni Korhonen for their comments.
Liebsch, et al. Expires January 14, 2010 [Page 12]
Internet-Draft PMIPv6 Localized Routing PS July 2009
7. References
7.1. Normative References
[I-D.ietf-netlmm-grekey-option]
Muhanna, A., Khalil, M., Gundavelli, S., and K. Leung,
"GRE Key Option for Proxy Mobile IPv6",
draft-ietf-netlmm-grekey-option-09 (work in progress),
May 2009.
[I-D.ietf-netlmm-pmip6-ipv4-support]
Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-13
(work in progress), June 2009.
[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.
7.2. Informative References
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
Liebsch, et al. Expires January 14, 2010 [Page 13]
Internet-Draft PMIPv6 Localized Routing PS July 2009
Appendix A. Change Notes
Changes in version 01
o Added a note about [RFC5213]'s understanding of localized routing
and the difference to the use cases discussed in this problem
statement
o Added the need for the solution to support also termination of
localized routing
o Some editorial revision
o Added chapter about IPv4 support according to the discussed and
relevant issues
Liebsch, et al. Expires January 14, 2010 [Page 14]
Internet-Draft PMIPv6 Localized Routing PS July 2009
Authors' Addresses
Marco Liebsch
NEC Laboratories Europe
NEC Europe Ltd.
Kurfuersten-Anlage 36
69115 Heidelberg,
Germany
Phone: +49 6221 4342146
Email: liebsch@nw.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 January 14, 2010 [Page 15]