NETEXT WG
Internet Engineering Task Force (IETF)                       R. Wakikawa
Internet-Draft
Request for Comments: 7389                               Softbank Mobile
Intended status:
Category: Standards Track                                  R. Pazhyannur
Expires: March 3, 2015
ISSN: 2070-1721                                            S. Gundavelli
                                                                   Cisco
                                                              C. Perkins
                                                          Futurewei Inc.
                                                         August 30,
                                                            October 2014

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

Abstract

   This document specifies a method to split the Control Plane control plane (CP) and
   User Plane
   user plane (UP) for a network infrastructure based on Proxy Mobile
   IPv6 based network infrastructure. (PMIPv6).  Existing specifications allow a mobile access gateway
   (MAG) to separate its control and user plane using the Alternate Care of
   address
   Care-of Address mobility option for IPv6, IPv6 or Alternate IPv4 Care of Care-of
   Address option for IPv4.  However, the current specification does not
   provide any mechanism allowing the local mobility anchor (LMA) to
   perform an analogous functional split.  To remedy that shortcoming,
   this document specifies a mobility option enabling a an LMA to provide
   an alternate LMA address to be used for the bi-directional user plane bidirectional user-plane
   traffic between the MAG and LMA.  With this new option, a an LMA will
   be able to use an IP address for its user plane which that is different
   than the IP address used for the control plane.

Status of this This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list  It represents the consensus of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid the IETF community.  It has
   received public review and has been approved for a maximum publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of six months RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained 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 3, 2015.
   http://www.rfc-editor.org/info/rfc7389.

Copyright Notice

   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
   2. Conventions and Terminology  . . . . . . . . . . . . . . . . .  5 .....................................5
      2.1. Conventions  . . . . . . . . . . . . . . . . . . . . . . .  5 ................................................5
      2.2. Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5 ................................................5
   3. Additional Fields in Conceptual Data Structures  . . . . . . .  6 .................6
   4. LMA User Plane User-Plane Address Mobility Option . . . . . . . . . . . .  6 ..........................6
   5. Protocol Configuration Variable  . . . . . . . . . . . . . . .  8 .................................8
   6. IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  9 .............................................9
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 10
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Security Considerations .........................................9
   8. References .....................................................10
      8.1. Normative References ......................................10
      8.2. Informative References ....................................10
   Acknowledgements ..................................................12
   Authors' Addresses ................................................12

1.  Introduction

   A PMIPv6 Proxy Mobile IPv6 (PMIPv6) infrastructure comprises two primary
   entities: LMA (local mobility anchor) and MAG (mobile access
   gateway).  The interface between the MAG and LMA consists of the
   control plane and user plane.  The control plane is responsible for
   signaling messages between the MAG and LMA LMA, such as the Proxy Binding
   Update (PBU) and Proxy Binding Acknowledgement (PBA) messages to
   establish a mobility binding.  In addition, the control plane control-plane
   components in the MAG and LMA are also responsible for setting up and
   tearing down a bi-directional bidirectional tunnel between the MAG and LMA.  The
   user plane is used for carrying the mobile node's IP traffic between
   the MAG and the LMA over the bi-
   directional bidirectional tunnel.

   Widely deployed mobility management systems for wireless
   communications require separation of IP transport for forwarding user
   plane
   user-plane and control plane control-plane traffic.  This separation offers more
   flexible deployment options for LMA and MAG entities in Proxy Mobile
   IPv6
   IPv6, as described in [I-D.wakikawa-req-mobile-cp-separation]. [MOBILE-SEPARATION].  To meet this requirement, Proxy Mobile IPv6 (PMIPv6) requires requirement
   would also require that the
   control plane control-plane functions of the LMA to be
   addressable at a different IP address than the IP address assigned
   for the user plane.  However, PMIPv6 does not currently specify a
   mechanism for allowing the LMA to separate the control plane from the
   user plane.  The LMA is currently required to associate the IP
   address of the tunnel source with the target IP address for the
   control messages received from the MAG.

   The control plane control-plane and user plane user-plane components (of the of a MAG and LMA) or LMA are
   typically co-located in the same physical entity.  However, there are
   situations where it is desirable to have the control and user plane
   of the a MAG and or LMA in separate physical entities.  For example, in a
   WLAN (Wireless LAN) network, it may be desirable to have the control control-
   plane component of the MAG reside on the Access Controller (also
   sometimes referred to as Wireless LAN Controller (WLC)) while the
   user plane
   user-plane component of the MAG resides on the WLAN Access Point.
   This enables all the control plane control-plane messages to the LMA to be
   centralized while the user plane would be distributed across the
   multiple Access Points.  Similarly  Similarly, there is a need for either the
   control plane and user plane
   control-plane or user-plane component of the LMA to be separated
   according to different scaling requirements, or requirements or, in other cases cases, the
   need to centralize the control plane in one geographical location
   while distributing the user plane user-plane component across multiple
   locations.  For example, as illustrated in Figure 1, the LMA and MAG
   could have one control session established for PMIPv6 control
   signaling,
   signaling while maintaining separate connectivity via GRE Generic Routing
   Encapsulation (GRE) or IP-in-IP tunneling for forwarding user plane user-plane
   traffic.

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

   MN: Mobile Node
   CP: Control Plane
   UP: User Plane

       Figure 1: Functional Separation of the Control and User Plane

   [RFC6463] and [RFC6275] enable separating the control and user plane
   in the MAG.  In particular, [RFC6463] defines the Alternate IPv4
   Proxy Care of
   Care-of Address Option, option, and [RFC6275] defines an Alternate Care
   of Care-of
   Address option for IPv6 address. IPv6.  The MAG may provide an Alternate Care
   of Care-of
   Address in the PBU, and if the LMA supports this option option, then a bi-
   directional
   bidirectional tunnel is setup set up between the LMA address and the MAG's
   alternate Care of address.
   Alternate Care-of Address.  However, these documents do not specify a
   corresponding option for the LMA to provide an alternate tunnel
   endpoint address to the MAG.

   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 bidirectional tunnel between the MAG and LMA LMA, as
   shown in Figure 1.

   The LMA Control Plane control-plane and the LMA User Plane user-plane functions are typically
   deployed on the same IP node node, and in such scenario a scenario, the interface
   between these functions is internal to the implementation.
   Deployments may also choose to deploy the LMA Control Plane control-plane and the
   LMA User Plane user-plane functions on separate IP nodes.  In such deployment
   models, there needs to be a protocol interface between these two
   functions and which
   functions, but that is outside the scope of this document.  Possible
   options for such an interface include OpenFlow
   [OpenFlow-Spec-v1.4.0],
   FORCES Forwarding and Control Element Separation
   (ForCES) [RFC5810], use of routing infrastructure
   [I-D.matsushima-stateless-uplane-vepc] or vendor specific [STATELESS-UPLANE],
   and vendor-specific approaches.  This specification does not mandate
   a specific protocol interface and views this interface as a generic
   interface relevant more broadly for many other protocol systems in
   addition to Proxy Mobile IPv6.  When the LMA Control Plane control-plane and the
   LMA User Plane user-plane functions are deployed on separate IP nodes, the
   requirement related to user-plane address anchoring specified (specified in
   Section 5.6.2 of [RFC5213] and Section 3.1.3 of [RFC5844] [RFC5844]) must be
   met by the node hosting the LMA user plane user-plane functionality.  The LMA user plane
   user-plane node must be a topological anchor point for the IP
   address/prefixes allocated to the mobile node.

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 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], [RFC4213] Encapsulation [RFC2473] [RFC4213].

   GRE

      Generic Routing Encapsulation [RFC1701] [RFC1701].

   UDP Encapsulation

      Encapsulation mode based on UDP transport specified in [RFC5844] [RFC5844].

   LMA Control Plane Control-Plane Address (LMA-CPA)

      The IP address on the LMA that is used for sending and receiving
      control plane
      control-plane traffic from the MAG.

   LMA User Plane User-Plane Address (LMA-UPA)

      The IP address on the LMA that is used for sending and receiving
      user plane
      user-plane traffic from the MAG.

   MAG Control Plane Control-Plane Address (MAG-CPA)

      The IP address on the MAG that is used for sending and receiving
      control plane
      control-plane traffic from the LMA.

   MAG User Plane User-Plane Address (MAG-UPA)

      The IP address on the MAG that is used for sending and receiving
      user plane
      user-plane traffic from the LMA.  This address is also referred to
      as the Alternate Care of Care-of Address.

3.  Additional Fields in Conceptual Data Structures

   To support the capability specified in this document, the conceptual
   Binding Update List entry data structure maintained by the LMA and
   the MAG is extended with the following additional fields. fields:

   o  The IP address of the LMA that carries user plane user-plane traffic.

   o  The IP address of the LMA that handles control plane control-plane traffic.

4.  LMA User Plane User-Plane Address Mobility Option

   The LMA User Plane User-Plane Address mobility option is a new mobility header
   option defined for use with PBU and PBA messages exchanged between
   the LMA and the MAG.  This option is used for notifying the MAG about
   the LMA's user plane user-plane IPv6 or IPv4 address.  There can be zero, one one,
   or two instances of the LMA User Plane User-Plane Address mobility option
   present in the message.  When two instances of the option are
   present, one instance of the option must be for IPv4 transport transport, and
   the other instance must be for IPv6 transport.

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

   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 User-Plane Address                    +
   |                                                               |
   +                                                               +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 2: LMA User Plane User-Plane Address option format Mobility Option Format
   Type
      <IANA-1> To be assigned by IANA.

      59

   Length

      8-bit

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

   Reserved

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

   LMA User Plane User-Plane Address

      Contains the 32-bit IPv4 address, address or the 128-bit IPv6 address of
      the LMA User user plane.  When the LMA User Plane User-Plane Address Mobility mobility
      option is included in a PBU message, this field can be a zero zero-
      length field, or it can have a value of ALL_ZERO, with all bits in
      the 32-bit IPv4 address, address or the 128-bit IPv6 address set to zero.

   When including the LMA User Plane User-Plane Address mobility option in the PBU,
   the MAG must apply the following rules:

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

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

   When the LMA includes the LMA User Plane User-Plane Address mobility option in
   the PBA, the IP address field in the option MUST be set to the LMA's
   IPv4 or IPv6 address carrying user-plane traffic.

   o  When using IPv4 transport for the user-plane, user plane, the IP address field
      in the option is the IPv4 address carrying user-plane traffic.

   o  When using IPv6 transport for the user-plane, user plane, the IP address field
      in the option is the IPv6 address carrying user-plane traffic.

   The encapsulation mode that will be chosen for the user-plane user plane between
   the MAG and the LMA has to based on the considerations specified in
   [RFC5213] and [RFC5844].

5.  Protocol Configuration Variable

   This specification defines the following configuration variable,
   which must be configurable (e.g., by the system management) on the
   LMA and MAG mobility entities.  The configured value for this
   protocol variable MUST survive server reboots and service restarts, restarts
   and MUST be the same for every LMA and MAG in the network domain
   supporting PMIPv6.

   Domain-wide-LMA-UPA-Support

         This variable indicates whether or not all the mobility
         entities in the PMIPv6 domain support the LMA User Plane User-Plane
         Address mobility option.

         When this variable on the MAG is set to zero (0), the MAG MUST
         indicate whether or not it supports this feature, feature by including
         the LMA
         User Plane User-Plane Address mobility option in the PBU.  If the
         option is not present in the PBU, the LMA SHALL disable this
         feature for the mobility session corresponding to the PBU.

         Setting this variable to one (1) on the MAG indicates that
         there is domain-wide support for this feature and the MAG is
         not required to include the LMA User Plane User-Plane Address mobility
         option in the PBA.  In this case, the MAG MAY choose not to
         include the LMA User Plane User-Plane Address mobility option in the PBU.

         When this variable on the LMA is set to zero (0), the LMA MUST
         NOT include the LMA User Plane User-Plane Address mobility option in the
         PBA,
         PBA unless the MAG has indicated support for this feature by
         including the LMA User Plane User-Plane Address mobility option in the PBU
         message.

         Setting this variable to one (1) on the LMA indicates that
         there is domain-wide support for this feature and the LMA
         SHOULD choose to include this LMA User Plane User-Plane Address mobility
         option in the PBA even if the option is not present in the PBU
         message.

         On both the LMA and the MAG, the default value for this
         variable is zero (0).  This implies that the default behavior
         of a MAG is to include this option in the PBU PBU, and the default
         behavior of a an LMA is to include this option in a PBA only if
         the option is present in the PBU.

6.  IANA Considerations

   This document requires the following IANA actions.

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

7.  Security Considerations

   The Proxy Mobile IPv6 specification [RFC5213] requires the signaling
   messages between the MAG and the LMA to be protected using end-to-end
   security association(s) offering integrity and data origin
   authentication.  The Proxy Mobile IPv6 specification also requires
   IPsec [RFC4301] to be a mandatory-to-implement security mechanism.

   This document specifies an approach where the Control control-plane and User Plane user-
   plane functions of the MAG and LMA are separated and hosted on
   different IP nodes.  In such deployment models, the nodes hosting
   those respective
   Control Plane control-plane functions still have to still meet the above the
   [RFC5213] security
   requirement.  Specifically, requirement listed above; specifically, the Proxy
   Mobile IPv6 signaling messages exchanged between these entities MUST
   be protected using end-to-end security association(s) offering
   integrity and data origin authentication.  Furthermore, IPsec is a
   mandatory-to-implement security mechanism for the nodes hosting the Control Plane
   control-plane function of the MAG and LMA.  Additional documents may
   specify alternative security mechanisms and the for securing Proxy Mobile
   IPv6 signaling messages.  The mobility entities in a Proxy Mobile
   IPv6 domain can enable a specific security mechanism
   for securing Proxy Mobile IPv6 signaling messages, based on either a
   (1) static configuration or after a (2) dynamic negotiation using (using any
   standard security negotiation protocols. protocols).

   As per the Proxy Mobile IPv6 specification, the use of IPsec for
   protecting the mobile node's User Plane user-plane traffic is optional.  This
   specification keeps the same requirement and therefore requires the
   nodes hosting the User Plane user-plane functions of the MAG and the LMA to have
   IPsec as a mandatory-to-implement security mechanism, mechanism but make the use
   of IPsec as optional for User Plane user-plane traffic protection.

   The LMA User Plane User-Plane Address mobility option defined in this
   specification is for use in PBU and PBA messages.  This option is
   carried like any other mobility header option as specified in
   [RFC5213].  Therefore, it inherits security guidelines from
   [RFC5213].

   The LMA-UPA IP address of the LMA user plane (the LMA-UPA), provided within
   the LMA User Plane User-Plane Address mobility option option, MUST be a valid address
   under the administrative control associated with the LMA functional
   block.

   If the LMA-UP LMA user-plane and the LMA-CP LMA control-plane functions are hosted
   in different entities, any control messages between these two
   entities containing the LMA User Plane User-Plane Address mobility option MUST
   be protected by
   IPsec.

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, Bruno Landais, Brian Carpenter, Pete Resnick,
   Stephen Farrell and Brian Haberman for their valuable comments using end-to-end security association(s) offering
   integrity and
   suggestions to improve this specification.

9. data origin authentication.

8.  References

9.1.

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997. 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005. 2005,
              <http://www.rfc-editor.org/info/rfc4301>.

   [RFC5213]  Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K.,
              and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 2008,
              <http://www.rfc-editor.org/info/rfc5213>.

   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
              Mobile IPv6", RFC 5844, May 2010.

9.2. 2010,
              <http://www.rfc-editor.org/info/rfc5844>.

8.2.  Informative References

   [I-D.matsushima-stateless-uplane-vepc]
              Matsushima, S. and R. Wakikawa, "Stateless user-plane
              architecture for virtualized EPC (vEPC)",
              draft-matsushima-stateless-uplane-vepc-03 (work in
              progress), July 2014.

   [I-D.wakikawa-req-mobile-cp-separation]

   [MOBILE-SEPARATION]
              Wakikawa, R., Matsushima, S., Patil, B., Chen, B., DJ,
              Joachimpillai, D., and H. Deng, "Requirements and use
              cases for separating control and user planes in mobile
              network architectures",
              draft-wakikawa-req-mobile-cp-separation-00 (work Work in
              progress), Progress,
              draft-wakikawa-req-mobile-cp-separation-00, November 2013.

   [OpenFlow-Spec-v1.4.0]
              Open Networking Foundation, "OpenFlow Switch
              Specification",
              Specification, Version 1.4.0", October 2013.

   [RFC1701]  Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic
              Routing Encapsulation (GRE)", RFC 1701, October 1994. 1994,
              <http://www.rfc-editor.org/info/rfc1701>.

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, December 1998. 1998,
              <http://www.rfc-editor.org/info/rfc2473>.

   [RFC4213]  Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms
              for IPv6 Hosts and Routers", RFC 4213, October 2005. 2005,
              <http://www.rfc-editor.org/info/rfc4213>.

   [RFC5810]  Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang,
              W., Dong, L., Gopal, R., and J. Halpern, "Forwarding and
              Control Element Separation (ForCES) Protocol
              Specification", RFC 5810, March 2010. 2010,
              <http://www.rfc-editor.org/info/rfc5810>.

   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
              in IPv6", RFC 6275, July 2011. 2011,
              <http://www.rfc-editor.org/info/rfc6275>.

   [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. 2012,
              <http://www.rfc-editor.org/info/rfc6459>.

   [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. 2012,
              <http://www.rfc-editor.org/info/rfc6463>.

   [STATELESS-UPLANE]
              Matsushima, S. and R. Wakikawa, "Stateless user-plane
              architecture for virtualized EPC (vEPC)", Work in
              Progress, draft-matsushima-stateless-uplane-vepc-03,
              July 2014.

Acknowledgements

   The authors of this document thank the NetExt Working Group for the
   valuable feedback on different versions of this specification.  In
   particular, the authors want to thank John Kaippallimalil, Sridhar
   Bhaskaran, Nirav Salot, Bruno Landais, Brian Carpenter, Pete Resnick,
   Stephen Farrell, and Brian Haberman for their valuable comments and
   suggestions to improve this specification.

Authors' Addresses

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

   Email:

   EMail: ryuji.wakikawa@gmail.com

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

   Email:  95134
   United States

   EMail: rpazhyan@cisco.com

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

   Email:
   United States

   EMail: sgundave@cisco.com

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

   Email:  95050
   United States

   EMail: charliep@computer.org