Skip to main content

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

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-01-13
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-01
NETEXT WG                                                    R. Wakikawa
Internet-Draft                                           Softbank Mobile
Intended status: Standards Track                           R. Pazhyannur
Expires: July 17, 2014                                     S. Gundavelli
                                                                   Cisco
                                                              C. Perkins
                                                          Futurewei Inc.
                                                        January 13, 2014

       Separation of Control and User Plane for Proxy Mobile IPv6
             draft-ietf-netext-pmip-cp-up-separation-01.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 July 17, 2014.

Copyright Notice

Wakikawa, et al.          Expires July 17, 2014                 [Page 1]
Internet-Draft             PMIPv6 CP-UP Split               January 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.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 7
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 8

Wakikawa, et al.          Expires July 17, 2014                 [Page 2]
Internet-Draft             PMIPv6 CP-UP Split               January 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 July 17, 2014                 [Page 3]
Internet-Draft             PMIPv6 CP-UP Split               January 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 July 17, 2014                 [Page 4]
Internet-Draft             PMIPv6 CP-UP Split               January 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 exchnaged 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 July 17, 2014                 [Page 5]
Internet-Draft             PMIPv6 CP-UP Split               January 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 IPv4/IPv6 user plane address of the LMA.

4.  IANA Considerations

   This document requires the following IANA action.

   o  Action-1: This specification defines a new Mobility Header option,
      LMA User Plane Address mobility option.  This mobility option is
      described in Section 3.  The type value <IANA-1> for this message
      needs to be allocated from the Mobility Header Types registry at
      http://www.iana.org/assignments/mobility-parameters.  RFC Editor:

Wakikawa, et al.          Expires July 17, 2014                 [Page 6]
Internet-Draft             PMIPv6 CP-UP Split               January 2014

      Please replace <IANA-1> in Section 3 with the assigned value, and
      update this section accordingly.

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

6.  Acknowledgements

   The authors would like to acknowledge all the discussions on this
   topic in the IETF netext Working Group.

7.  References

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

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

Wakikawa, et al.          Expires July 17, 2014                 [Page 7]
Internet-Draft             PMIPv6 CP-UP Split               January 2014

              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

   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 July 17, 2014                 [Page 8]