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

NETEXT WG                                                    R. Wakikawa
Internet-Draft                                           Softbank Mobile
Intended status: Standards Track                              C. Perkins
Expires: March 23, 2014                                   Futurewei Inc.
                                                           R. Pazhyannur
                                                           S. Gundavelli
                                                                   Cisco
                                                      September 19, 2013

       Separation of Control and User Plane for Proxy Mobile IPv6
             draft-ietf-netext-pmip-cp-up-separation-00.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 what is 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 March 23, 2014.

Copyright Notice

Wakikawa, et al.         Expires March 23, 2014                 [Page 1]
Internet-Draft             PMIPv6 CP-UP Split             September 2013

   Copyright (c) 2013 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   4
     2.1.  Conventions . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  LMA User Plane Address Mobility Option  . . . . . . . . . . .   4
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   Widely deployed mobility management systems for wireless
   communications have isolated the path for forwarding data packets
   from the control plane signaling for mobility management.  To realize
   this requirement, Proxy Mobile IPv6 requires that the control plane
   functions of the local mobility anchor to be addressable at a
   different IP address than the IP address used for the user plane.
   However, the current specification does not have semantics for
   allowing the LMA to perform such functional split.  The local
   mobility anchor is required to associate the IP address of the tunnel
   source with the target IP address of the control messages received
   from the MAG.  Note that the concept of control- and user- planes are
   well established and understood in cellular networks.

   A PMIPv6 infrastructure contains of two primary entities: MAG and
   LMA.  The interface between MAG and LMA consists of two components:
   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

Wakikawa, et al.         Expires March 23, 2014                 [Page 2]
Internet-Draft             PMIPv6 CP-UP Split             September 2013

   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.

   In most deployments, the control plane and user plane components (of
   the MAG and LMA) are 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 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 there is a case to
   split the control and user plane component of the LMA motivated by
   different scaling requirements on the control and user plane
   components or need to centralize the control plane in one geo-
   location while distributing the user plane component across multiple
   geo-locations

   [RFC6463] and [RFC6275] contains a mechanism of splitting the control
   and user plane in MAG.  Specifically, [RFC6463] defines an 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 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 | |        | |
                | +--------+ |             | +--------+ |
                +------------+             +------------+

Wakikawa, et al.         Expires March 23, 2014                 [Page 3]
Internet-Draft             PMIPv6 CP-UP Split             September 2013

         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

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

   LMA User Plane Address (LMA-UPA)

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

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 Acknowledgment message sent
   from the local mobility anchor to the mobile access gateway.  This
   option is used for notifying the LMA's user plane IPv4/IPv6 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:

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

Wakikawa, et al.         Expires March 23, 2014                 [Page 4]
Internet-Draft             PMIPv6 CP-UP Split             September 2013

   +                       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 for now.  The value MUST be initialized 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  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: 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 from [RFC5213] its
   security guidelines and does not require any additional security
   considerations.

Wakikawa, et al.         Expires March 23, 2014                 [Page 5]
Internet-Draft             PMIPv6 CP-UP Split             September 2013

6.  Acknowledgements

   Authors would like Acknowledge all the discussions on this topic in
   the NETLMM 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

   [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

Wakikawa, et al.         Expires March 23, 2014                 [Page 6]
Internet-Draft             PMIPv6 CP-UP Split             September 2013

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

   Email: charliep@computer.org

   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

Wakikawa, et al.         Expires March 23, 2014                 [Page 7]