Skip to main content

Separation of Control and User Plane for Proxy Mobile IPv6
draft-ietf-netext-pmip-cp-up-separation-02

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7389.
Authors Ryuji Wakikawa , Rajesh Pazhyannur , Sri Gundavelli , Charles E. Perkins
Last updated 2014-02-14
RFC stream Internet Engineering Task Force (IETF)
Formats
Reviews
Additional resources Mailing list discussion
Stream WG state WG Document
Document shepherd (None)
IESG IESG state Became RFC 7389 (Proposed Standard)
Consensus boilerplate Unknown
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ietf-netext-pmip-cp-up-separation-02
NETEXT WG                                                    R. Wakikawa
Internet-Draft                                           Softbank Mobile
Intended status: Standards Track                           R. Pazhyannur
Expires: August 18, 2014                                   S. Gundavelli
                                                                   Cisco
                                                              C. Perkins
                                                          Futurewei Inc.
                                                       February 14, 2014

       Separation of Control and User Plane for Proxy Mobile IPv6
             draft-ietf-netext-pmip-cp-up-separation-02.txt

Abstract

   This document describes splitting of Control Plane (CP) and User
   Plane (UP) for a Proxy Mobile IPv6 based network infrastructure.
   Existing specifications allow a MAG to perform splitting of its
   control and user plane using Alternate Care of address mobility
   option for IPv6, or Alternate IPv4 Care of Address option for IPv4.
   However, the current specification does not have semantics for
   allowing the LMA to perform such functional split.  To realize this
   requirement, this specification defines a mobility option that
   enables a local mobility anchor to provide an alternate LMA address
   to be used for the bi-directional tunnel between the MAG and LMA.
   With this extension, a local mobility anchor will be able to use an
   IP address for its user plane which is different than the IP address
   used for the control plane.

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 August 18, 2014.

Copyright Notice

Wakikawa, et al.         Expires August 18, 2014                [Page 1]
Internet-Draft             PMIPv6 CP-UP Split              February 2014

   Copyright (c) 2014 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
   (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
     2.1.  Conventions  . . . . . . . . . . . . . . . . . . . . . . .  4
     2.2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  LMA User Plane Address Mobility Option . . . . . . . . . . . .  5
   4.  Protocol Considerations  . . . . . . . . . . . . . . . . . . .  6
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  Protocol Configuration Variables . . . . . . . . . . . . . . .  8
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  9
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     9.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10

Wakikawa, et al.         Expires August 18, 2014                [Page 2]
Internet-Draft             PMIPv6 CP-UP Split              February 2014

1.  Introduction

   Widely deployed mobility management systems for wireless
   communications require isolation between the path for forwarding data
   packets (the user plane) and the control plane signaling for mobility
   management.  To meet this requirement, Proxy Mobile IPv6 requires
   that the control plane functions of the local mobility anchor (LMA)
   to be addressable at a different IP address than the IP address
   assigned for the user plane.  However, the current specification does
   not have semantics for allowing the LMA to perform such functional
   split.  The LMA is required to associate the IP address of the tunnel
   source with the target IP address of the control messages received
   from the MAG.

   A PMIPv6 infrastructure comprises two primary entities: LMA and MAG
   (Mobility Access Gateway).  The interface between MAG and LMA
   consists of the control plane and user plane.  The control plane is
   responsible for signaling messages between MAG and LMA such as the
   Proxy Binding Update and Proxy Binding Acknowledge messages to
   establish a mobility binding.  In addition, the control plane
   components in the MAG and LMA are also responsible for setting up and
   tearing down of the bi-directional tunnel between the MAG and LMA.
   The user plane is responsible for forwarding the mobile node's IP
   packets between the MAG and the LMA over the bi-directional tunnel.

   The control plane and user plane components (of the MAG and LMA) are
   typically co-located in the same physical entity.  However, there are
   deployments where it is desirable to have the control and user plane
   of the MAG and LMA in separate physical entities.  For example, in a
   WLAN (Wireless LAN) deployment, it may be desirable to have the
   control plane component of the MAG to be on Access Controller (also
   sometimes referred to as Wireless LAN Controller) while the user
   plane component of the MAG resides on the WLAN Access Point.  This
   would enable all the signaling messages to the LMA to be centralized
   while the user plane would be distributed across the multiple Access
   Points.  Similarly the control plane and user plane component of the
   LMA may be split according to different scaling requirements, or the
   need to centralize the control plane in one geo-location while
   distributing the user plane component across multiple geo-locations.

   [RFC6463] and [RFC6275] enable splitting the control and user plane
   in the MAG.  Specifically, [RFC6463] defines the Alternate IPv4 Proxy
   Care of Address Option while [RFC6275] defines an Alternate Care of
   Address for IPv6 address.  The MAG can provide an Alternate Care of
   Address in the Proxy Binding Update (PBU) and if the LMA supports
   this option then a bidirectional tunnel is setup between the LMA
   address and the MAG's alternate Care of address.  However, there is
   no corresponding option for the LMA to provide an alternate address

Wakikawa, et al.         Expires August 18, 2014                [Page 3]
Internet-Draft             PMIPv6 CP-UP Split              February 2014

   to the MAG.

   CP: Control Plane
   UP: User Plane
                +------------+             +------------+
                |     MAG    |             |     LMA    |
                | +--------+ |             | +--------+ |
   +------+     | | MAG-CP |-|-------------|-| LMA-CP | |      _----_
   |  MN  |     | |        | |    PMIPv6   | |        | |    _(      )_
   |      |-----| +--------+ |             | +--------+ |===( Internet )
   +------+     |      :     |             |      :     |    (_      _)
                | +--------+ |             | +--------+ |      '----'
                | | MAG-UP |-|-------------|-| LMA-UP | |
                | |        | |GRE/IP-in-IP | |        | |
                | +--------+ |             | +--------+ |
                +------------+             +------------+

         Figure 1: Functional Split of the Control and User Plane

   This specification therefore defines a new mobility option that
   enables a local mobility anchor to provide an alternate LMA address
   to be used for the bi-directional tunnel between the MAG and LMA.

2.  Conventions and Terminology

2.1.  Conventions

   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 RFC 2119 [RFC2119].

2.2.  Terminology

   3GPP terms can be found in [RFC6459].  Other mobility related terms
   used in this document are to be interpreted as defined in [RFC5213]
   and [RFC5844].  Additionally, this document uses the following terms:

   IP-in-IP

      IP-within-IP encapsulation [RFC2473]

   GRE

Wakikawa, et al.         Expires August 18, 2014                [Page 4]
Internet-Draft             PMIPv6 CP-UP Split              February 2014

      Generic Record Encapsulation [RFC1701]

   LMA Control Plane Address (LMA-CP)

      The IP address on the LMA that is provided to the MAG for
      establishing control plane connections.

   LMA User Plane Address (LMA-UP)

      The IP address on the LMA that is used for establishing user plane
      tunnels with the mobile access gateway.

   MAG Control Plane Address (MAG-CP)

      The IP address on the MAG that is provided to the LMA for
      establishing control plane connections.

   MAG User Plane Address (MAG-UP)

      The IP address on the MAG that is supports user plane tunnels with
      the LMA.

3.  LMA User Plane Address Mobility Option

   A new mobility header option, LMA User Plane Address mobility option
   is defined for use with Proxy Binding Update and Proxy Binding
   Acknowledgement messages exchanged between the LMA and the MAG.  This
   option is used for notifying the LMA's user plane IPv6 or IPv4
   address.  There can be multiple instances of the LMA User Plane
   Address mobility option present in the message, one for IPv4 and the
   other for IPv6 transport.

   The LMA User Plane Address mobility option has an alignment
   requirement of 8n+2.  Its format is as follows:

Wakikawa, et al.         Expires August 18, 2014                [Page 5]
Internet-Draft             PMIPv6 CP-UP Split              February 2014

   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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      Type     |   Length      |           Reserved            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                                                               +
   |                                                               |
   .                                                               .
   +                     LMA User Plane Address                    +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      To be assigned by IANA.

   Length

      8-bit unsigned integer indicating the length of the option in
      octets, excluding the type and length fields.

   Reserved

      This field is unused in this specification.  The value MUST be set
      to 0 by the sender and MUST be ignored by the receiver.

   LMA User Plane Address

      Contains the 32-bit IPv4 address, or the 128-bit IPv6 of the LMA.
      When this option is included in a Proxy Binding Update message as
      a capability hint, this field can be a zero length field, or it
      can be a ALL_ZERO value with all bits in the 32-bit IPv4 address,
      or the 128-bit IPv6 address set to a value of zero.

4.  Protocol Considerations

   o  If the protocol configuration variable, Domain-wide-LMA-UPA-
      Support, is set to a value of (0), the MAG is required to
      explicitly indicate to LMA on its support-capability for this

Wakikawa, et al.         Expires August 18, 2014                [Page 6]
Internet-Draft             PMIPv6 CP-UP Split              February 2014

      feature.  Not including this option in the Proxy Binding Update
      will result in LMA disabling this feature for this MAG.

   o  If the protocol configuration variable, Domain-wide-LMA-UPA-
      Support, is set to a value of (1), the MAG is not required to
      explicitly indicate to LMA on its support-capability for this
      feature.  The MAG may choose not to include the LMA User Plane
      Address mobility option in the Proxy Binding Update.

   o  The MAG when including the LMA User Plane Address mobility option
      in the Proxy Binding Update has to the apply the following
      considerations:

      *  When using IPv4 transport for the user-plane, the IP address
         field in the option can be either a zero-length field, or it
         can be 4-octet field with ALL_ZERO value.

      *  When using IPv6 transport for the user-plane, the IP address
         field in the option can be either a zero-length field, or it
         can be 16-octet field with ALL_ZERO value.

   o  When the LMA is configured to provide an alternate IP address to
      be used for the bi-directional tunnel between the MAG and LMA, it
      must apply the following considerations.

      *  If the protocol configuration variable, Domain-wide-LMA-UPA-
         Support, is set to a value of (0) and if the received Proxy
         Binding Update did not include the LMA User Plane Address
         mobility option, then the LMA MUST disable this feature for
         that MAG.  The LMA MUST NOT include the LMA User Plane Address
         mobility Option in the Proxy Binding Acknowledgement.

      *  If the protocol configuration variable, Domain-wide-LMA-UPA-
         Support, is set to a value of (1), or if the LMA User Plane
         Address mobility option is present in the received Proxy
         Binding Update, then the LMA should include the LMA User Plane
         Address mobility Option in the Proxy Binding Acknowledgement.
         The IP address field in the option must be set to the IPv4 or
         IPv6 address used for the user-plane.

         +  When using IPv4 transport for the user-plane, the IP address
            field in the option must be the IPv4 address used for the
            user-plane.

         +  When using IPv6 transport for the user-plane, the IP address
            field in the option must be the IPv6 address used for the
            user-plane.

Wakikawa, et al.         Expires August 18, 2014                [Page 7]
Internet-Draft             PMIPv6 CP-UP Split              February 2014

5.  IANA Considerations

   This document requires the following IANA actions.

   o  Action-1: This specification defines a new mobility header option,
      LMA User Plane Address mobility option.  The format of this option
      is described in Section 3.  The type value <IANA-1> for this
      mobility option needs to be allocated from the Mobility Options
      registry at <http://www.iana.org/assignments/mobility-parameters>.
      RFC Editor: Please replace <IANA-1> in Section 3 with the assigned
      value and update this section accordingly.

6.  Protocol Configuration Variables

   This specification defines the following configuration variable.  The
   mobility entities, LMA and MAG must allow this variable to be
   configured by the system management.  The configured values for this
   protocol variable must survive server reboots and service restarts.

   Domain-wide-LMA-UPA-Support

         This variables indicates if all the mobility entities in the
         Proxy Mobile IPv6 domain have support for the feature specified
         in this document.

         When this variable on the MAG is set to a value of (0), the MAG
         must explicitly indicate its support-capability for this
         feature by including the LMA User Plane Address mobility Option
         in the Proxy Binding Acknowledgement.  If the option is not
         present in the Proxy Binding Update, the local mobility anchor
         will not enable this feature for that mobility session.

         When this variable on the MAG is set to a value of (1), it is
         an indication that there is domain-wide support for this
         feature and the MAG is not required to explicitly indicate its
         support-capability for this feature by including the LMA User
         Plane Address mobility Option in the Proxy Binding
         Acknowledgement.

         When this variable on the LMA is set to a value of (0), the LMA
         MUST NOT include the LMA User Plane Address mobility Option in
         the Proxy Binding Acknowledgement unless the MAG has explicitly
         indicated its support-capability for this feature by including
         the LMA User Plane Address mobility option in the Proxy Binding
         Update.

Wakikawa, et al.         Expires August 18, 2014                [Page 8]
Internet-Draft             PMIPv6 CP-UP Split              February 2014

         When this variable on the LMA is set to a value of (1), it is
         an indication that there is domain-wide support for this
         feature and the LMA MAY choose to include this LMA User Plane
         Address mobility Option in the Proxy Binding Acknowledgement
         even if the option is not present in the Proxy Binding Update
         message.

7.  Security Considerations

   The LMA User Plane Address mobility Option defined in this
   specification is for use in Proxy Binding Acknowledgement message.
   This option is carried like any other mobility header option as
   specified in [RFC5213].  Therefore, it inherits security guidelines
   from [RFC5213].

   The LMA-UP provided as data within the LMA User Plane Address
   mobility Option MUST be a valid address under the administrative
   control associated with the LMA functional block.

   If the LMA-UP and the LMA-CP functions are hosted in different
   entities, any signaling between these two entities MUST be protected
   by IPsec security association.

8.  Acknowledgements

   The authors of this document thank the NetExt Working Group for the
   valuable feedback to different versions of this specification.  In
   particular the authors want to thank John Kaippallimalil, Sridhar
   Bhaskaran, Nirav Salot and Bruno landais for their valuable comments
   and suggestions to improve this specification.

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.

Wakikawa, et al.         Expires August 18, 2014                [Page 9]
Internet-Draft             PMIPv6 CP-UP Split              February 2014

9.2.  Informative References

   [RFC1701]  Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
              Routing Encapsulation (GRE)", RFC 1701, October 1994.

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, December 1998.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011.

   [RFC6459]  Korhonen, J., Soininen, J., Patil, B., Savolainen, T.,
              Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation
              Partnership Project (3GPP) Evolved Packet System (EPS)",
              RFC 6459, January 2012.

   [RFC6463]  Korhonen, J., Gundavelli, S., Yokota, H., and X. Cui,
              "Runtime Local Mobility Anchor (LMA) Assignment Support
              for Proxy Mobile IPv6", RFC 6463, February 2012.

Authors' Addresses

   Ryuji Wakikawa
   Softbank Mobile
   1-9-1,Higashi-Shimbashi,Minato-Ku
   Tokyo  105-7322
   Japan

   Email: ryuji.wakikawa@gmail.com

   Rajesh S. Pazhyannur
   Cisco
   170 West Tasman Drive
   San Jose, CA 95134,
   USA

   Email: rpazhyan@cisco.com

Wakikawa, et al.         Expires August 18, 2014               [Page 10]
Internet-Draft             PMIPv6 CP-UP Split              February 2014

   Sri Gundavelli
   Cisco
   170 West Tasman Drive
   San Jose, CA  95134
   USA

   Email: sgundave@cisco.com

   Charles E. Perkins
   Futurewei Inc.
   2330 Central Expressway
   Santa Clara, CA 95050,
   USA

   Email: charliep@computer.org

Wakikawa, et al.         Expires August 18, 2014               [Page 11]