[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 6279

NetExt Working Group                                          M. Liebsch
Internet-Draft                                                       NEC
Intended status: Informational                                  S. Jeong
Expires: April 29, 2010                                             ETRI
                                                                   Q. Wu
                                                                  Huawei
                                                        October 26, 2009


               PMIPv6 Localized Routing Problem Statement
                  draft-ietf-netext-pmip6-lr-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 April 29, 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 April 29, 2010                 [Page 1]

Internet-Draft         PMIPv6 Localized Routing PS          October 2009


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 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
     3.1.  General observation  . . . . . . . . . . . . . . . . . . .  5
     3.2.  Analysis of different use cases  . . . . . . . . . . . . .  6
     3.3.  IPv4 consideration . . . . . . . . . . . . . . . . . . . .  8
       3.3.1.  Localized Routing between IPv4 Home Addresses  . . . .  8
       3.3.2.  IPv4 Transport Network Considerations  . . . . . . . .  9
   4.  Identification of required functions . . . . . . . . . . . . . 10
   5.  Roaming Considerations . . . . . . . . . . . . . . . . . . . . 11
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13
   7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Change Notes  . . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17



















Liebsch, et al.          Expires April 29, 2010                 [Page 2]

Internet-Draft         PMIPv6 Localized Routing PS          October 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 April 29, 2010                 [Page 3]

Internet-Draft         PMIPv6 Localized Routing PS          October 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 April 29, 2010                 [Page 4]

Internet-Draft         PMIPv6 Localized Routing PS          October 2009


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 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



Liebsch, et al.          Expires April 29, 2010                 [Page 5]

Internet-Draft         PMIPv6 Localized Routing PS          October 2009


   necessary protocol specification to enable localized routing in
   PMIPv6 is necessary.

3.2.  Analysis of different use cases

   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.


                         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.




Liebsch, et al.          Expires April 29, 2010                 [Page 6]

Internet-Draft         PMIPv6 Localized Routing PS          October 2009


   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
      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



Liebsch, et al.          Expires April 29, 2010                 [Page 7]

Internet-Draft         PMIPv6 Localized Routing PS          October 2009


      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.

3.3.  IPv4 consideration

   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.

   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 two MNs' IPv4
   Home Addresses or transport plane issues.  The following subsections
   analyze these two groups.

3.3.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.

   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.




Liebsch, et al.          Expires April 29, 2010                 [Page 8]

Internet-Draft         PMIPv6 Localized Routing PS          October 2009


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 within a domain 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 a
   PMIP6 domain.  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 April 29, 2010                 [Page 9]

Internet-Draft         PMIPv6 Localized Routing PS          October 2009


4.  Identification of required functions

   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.

























Liebsch, et al.          Expires April 29, 2010                [Page 10]

Internet-Draft         PMIPv6 Localized Routing PS          October 2009


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.

   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 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).  CN should stay with MN within the same domain.












Liebsch, et al.          Expires April 29, 2010                [Page 11]

Internet-Draft         PMIPv6 Localized Routing PS          October 2009


                                     |
           +-----+       +-----+     |      +-----+
           |LMA1 |       |LMA2 |     |      |LMA2'|
           +-----+       +-----+     |      +-----+
                                     |
                                     |
                                     |
                                     |
           +-----+       +-----+     |
           |MAG1 |       |MAG2 |     |
           +-----+       +-----+     |
                                     |
                                     |
                                  A  |  B
       ------------------------------+-------------------------------
                                     C


                          +-----+        +-----+
                          |MAG1'|        |MAG2'|
                          +-----+        +-----+


      Figure 2: PMIPv6 roaming cases considered for Localized Routing



























Liebsch, et al.          Expires April 29, 2010                [Page 12]

Internet-Draft         PMIPv6 Localized Routing PS          October 2009


6.  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 April 29, 2010                [Page 13]

Internet-Draft         PMIPv6 Localized Routing PS          October 2009


7.  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, Mohana Jeyatharan and Jouni Korhonen
   for their comments.



































Liebsch, et al.          Expires April 29, 2010                [Page 14]

Internet-Draft         PMIPv6 Localized Routing PS          October 2009


8.  References

8.1.  Normative References

   [I-D.ietf-netlmm-pmip6-ipv4-support]
              Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-17
              (work in progress), September 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.

8.2.  Informative References

   [RFC3775]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
              in IPv6", RFC 3775, June 2004.
































Liebsch, et al.          Expires April 29, 2010                [Page 15]

Internet-Draft         PMIPv6 Localized Routing PS          October 2009


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)








































Liebsch, et al.          Expires April 29, 2010                [Page 16]

Internet-Draft         PMIPv6 Localized Routing PS          October 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 April 29, 2010                [Page 17]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/