doc: Add RFC documents

1 files changed, 675 insertions, 0 deletions

diff --git a/doc/rfc/rfc7389.txt b/doc/rfc/rfc7389.txt
new file mode 100644
index 0000000..4d06198
--- /dev/null
+++ b/doc/rfc/rfc7389.txt
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       R. Wakikawa
+Request for Comments: 7389                               Softbank Mobile
+Category: Standards Track                                  R. Pazhyannur
+ISSN: 2070-1721                                            S. Gundavelli
+                                                                   Cisco
+                                                              C. Perkins
+                                                          Futurewei Inc.
+                                                            October 2014
+
+
+       Separation of Control and User Plane for Proxy Mobile IPv6
+
+Abstract
+
+   This document specifies a method to split the control plane (CP) and
+   user plane (UP) for a network infrastructure based on Proxy Mobile
+   IPv6 (PMIPv6).  Existing specifications allow a mobile access gateway
+   (MAG) to separate its control and user plane using the Alternate
+   Care-of Address mobility option for IPv6 or Alternate IPv4 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 an LMA to provide
+   an alternate LMA address to be used for the bidirectional user-plane
+   traffic between the MAG and LMA.  With this new option, an LMA will
+   be able to use an IP address for its user plane that is different
+   than the IP address used for the control plane.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc7389.
+
+
+
+
+
+
+
+
+
+
+Wakikawa, et al.             Standards Track                    [Page 1]
+
+RFC 7389                   PMIPv6 CP-UP Split               October 2014
+
+
+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 ....................................................2
+   2. Conventions and Terminology .....................................5
+      2.1. Conventions ................................................5
+      2.2. Terminology ................................................5
+   3. Additional Fields in Conceptual Data Structures .................6
+   4. LMA User-Plane Address Mobility Option ..........................6
+   5. Protocol Configuration Variable .................................8
+   6. IANA Considerations .............................................9
+   7. Security Considerations .........................................9
+   8. References .....................................................10
+      8.1. Normative References ......................................10
+      8.2. Informative References ....................................10
+   Acknowledgements ..................................................12
+   Authors' Addresses ................................................12
+
+1.  Introduction
+
+   A 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, such as the Proxy Binding
+   Update (PBU) and Proxy Binding Acknowledgement (PBA) 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 a 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 bidirectional tunnel.
+
+
+
+
+
+
+Wakikawa, et al.             Standards Track                    [Page 2]
+
+RFC 7389                   PMIPv6 CP-UP Split               October 2014
+
+
+   Widely deployed mobility management systems for wireless
+   communications require separation of IP transport for forwarding
+   user-plane and control-plane traffic.  This separation offers more
+   flexible deployment options for LMA and MAG entities in Proxy Mobile
+   IPv6, as described in [MOBILE-SEPARATION].  To meet this requirement
+   would also require that the control-plane functions of the LMA 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 and user-plane components of a MAG 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 a MAG or LMA in separate physical entities.  For example, in a
+   WLAN (Wireless LAN) network, it may be desirable to have the control-
+   plane component of the MAG reside on the Access Controller (also
+   sometimes referred to as Wireless LAN Controller (WLC)) while the
+   user-plane component of the MAG resides on the WLAN Access Point.
+   This enables all the control-plane messages to the LMA to be
+   centralized while the user plane would be distributed across the
+   multiple Access Points.  Similarly, there is a need for either the
+   control-plane or user-plane component of the LMA to be separated
+   according to different scaling requirements or, in other cases, the
+   need to centralize the control plane in one geographical location
+   while distributing the 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 while maintaining separate connectivity via Generic Routing
+   Encapsulation (GRE) or IP-in-IP tunneling for forwarding user-plane
+   traffic.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wakikawa, et al.             Standards Track                    [Page 3]
+
+RFC 7389                   PMIPv6 CP-UP Split               October 2014
+
+
+                     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
+   Care-of Address option, and [RFC6275] defines an Alternate Care-of
+   Address option for IPv6.  The MAG may provide an Alternate Care-of
+   Address in the PBU, and if the LMA supports this option, then a
+   bidirectional tunnel is set up between the LMA address and the MAG's
+   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, as
+   shown in Figure 1.
+
+   The LMA control-plane and the LMA user-plane functions are typically
+   deployed on the same IP node, and in such a scenario, the interface
+   between these functions is internal to the implementation.
+   Deployments may also choose to deploy the LMA control-plane and the
+   LMA user-plane functions on separate IP nodes.  In such deployment
+   models, there needs to be a protocol interface between these two
+   functions, but that is outside the scope of this document.  Possible
+   options for such an interface include OpenFlow
+   [OpenFlow-Spec-v1.4.0], Forwarding and Control Element Separation
+   (ForCES) [RFC5810], use of routing infrastructure [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 and the
+   LMA user-plane functions are deployed on separate IP nodes, the
+   requirement related to user-plane address anchoring (specified in
+
+
+
+Wakikawa, et al.             Standards Track                    [Page 4]
+
+RFC 7389                   PMIPv6 CP-UP Split               October 2014
+
+
+   Section 5.6.2 of [RFC5213] and Section 3.1.3 of [RFC5844]) must be
+   met by the node hosting the LMA user-plane functionality.  The LMA
+   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 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].
+
+   GRE
+
+      Generic Routing Encapsulation [RFC1701].
+
+   UDP Encapsulation
+
+      Encapsulation mode based on UDP transport specified in [RFC5844].
+
+   LMA Control-Plane Address (LMA-CPA)
+
+      The IP address on the LMA that is used for sending and receiving
+      control-plane traffic from the MAG.
+
+   LMA User-Plane Address (LMA-UPA)
+
+      The IP address on the LMA that is used for sending and receiving
+      user-plane traffic from the MAG.
+
+   MAG Control-Plane Address (MAG-CPA)
+
+      The IP address on the MAG that is used for sending and receiving
+      control-plane traffic from the LMA.
+
+
+
+
+
+
+Wakikawa, et al.             Standards Track                    [Page 5]
+
+RFC 7389                   PMIPv6 CP-UP Split               October 2014
+
+
+   MAG User-Plane Address (MAG-UPA)
+
+      The IP address on the MAG that is used for sending and receiving
+      user-plane traffic from the LMA.  This address is also referred to
+      as the Alternate 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:
+
+   o  The IP address of the LMA that carries user-plane traffic.
+
+   o  The IP address of the LMA that handles control-plane traffic.
+
+4.  LMA User-Plane Address Mobility Option
+
+   The LMA 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 IPv6 or IPv4 address.  There can be zero, one,
+   or two instances of the LMA 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, and
+   the other instance must be for IPv6 transport.
+
+   The LMA 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 Address                    +
+   |                                                               |
+   +                                                               +
+   |                                                               |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+          Figure 2: LMA User-Plane Address Mobility Option Format
+
+
+
+
+
+Wakikawa, et al.             Standards Track                    [Page 6]
+
+RFC 7389                   PMIPv6 CP-UP Split               October 2014
+
+
+   Type
+
+      59
+
+   Length
+
+      An 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 zero (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 address of
+      the LMA user plane.  When the LMA User-Plane Address mobility
+      option is included in a PBU message, this field can be a zero-
+      length field, or it can have a value of ALL_ZERO, with all bits in
+      the 32-bit IPv4 address or the 128-bit IPv6 address set to zero.
+
+   When including the LMA User-Plane Address mobility option in the PBU,
+   the MAG must apply the following rules:
+
+   o  When using IPv4 transport for the user plane, the IP address field
+      in the option MUST be either a zero-length field or a 4-octet
+      field with ALL_ZERO value.
+
+   o  When using IPv6 transport for the user plane, the IP address field
+      in the option MUST be either a zero-length field or a 16-octet
+      field with ALL_ZERO value.
+
+   When the LMA includes the LMA 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, the IP address field
+      in the option is the IPv4 address carrying user-plane traffic.
+
+   o  When using IPv6 transport for the 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 between
+   the MAG and the LMA has to based on the considerations specified in
+   [RFC5213] and [RFC5844].
+
+
+
+
+
+Wakikawa, et al.             Standards Track                    [Page 7]
+
+RFC 7389                   PMIPv6 CP-UP Split               October 2014
+
+
+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
+   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
+         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 by including
+         the LMA 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 Address mobility
+         option in the PBA.  In this case, the MAG MAY choose not to
+         include the LMA 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 Address mobility option in the
+         PBA unless the MAG has indicated support for this feature by
+         including the LMA 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 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, and the default
+         behavior of an LMA is to include this option in a PBA only if
+         the option is present in the PBU.
+
+
+
+
+
+
+
+Wakikawa, et al.             Standards Track                    [Page 8]
+
+RFC 7389                   PMIPv6 CP-UP Split               October 2014
+
+
+6.  IANA Considerations
+
+   This specification defines a new mobility header option -- the LMA
+   User-Plane Address mobility option.  The format of this option is
+   described in Section 4.  The Type value 59 for this mobility option
+   has been allocated by IANA in the "Mobility Options" registry at
+   <http://www.iana.org/assignments/mobility-parameters>.
+
+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-plane and 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 functions still have to meet the
+   [RFC5213] security 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 function of the MAG and LMA.  Additional documents may
+   specify alternative security mechanisms for securing Proxy Mobile
+   IPv6 signaling messages.  The mobility entities in a Proxy Mobile
+   IPv6 domain can enable a specific security mechanism based on either
+   (1) static configuration or (2) dynamic negotiation (using any
+   standard security negotiation protocols).
+
+   As per the Proxy Mobile IPv6 specification, the use of IPsec for
+   protecting the mobile node's user-plane traffic is optional.  This
+   specification keeps the same requirement and therefore requires the
+   nodes hosting the user-plane functions of the MAG and the LMA to have
+   IPsec as a mandatory-to-implement security mechanism but make the use
+   of IPsec optional for user-plane traffic protection.
+
+   The LMA 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].
+
+
+
+
+
+
+
+Wakikawa, et al.             Standards Track                    [Page 9]
+
+RFC 7389                   PMIPv6 CP-UP Split               October 2014
+
+
+   The IP address of the LMA user plane (the LMA-UPA), provided 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 user-plane and the LMA control-plane functions are hosted
+   in different entities, any control messages between these two
+   entities containing the LMA User-Plane Address mobility option MUST
+   be protected using end-to-end security association(s) offering
+   integrity and data origin authentication.
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997,
+              <http://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
+              Internet Protocol", RFC 4301, December 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,
+              <http://www.rfc-editor.org/info/rfc5213>.
+
+   [RFC5844]  Wakikawa, R. and S. Gundavelli, "IPv4 Support for Proxy
+              Mobile IPv6", RFC 5844, May 2010,
+              <http://www.rfc-editor.org/info/rfc5844>.
+
+8.2.  Informative References
+
+   [MOBILE-SEPARATION]
+              Wakikawa, R., Matsushima, S., Patil, B., Chen, B.,
+              Joachimpillai, D., and H. Deng, "Requirements and use
+              cases for separating control and user planes in mobile
+              network architectures", Work in Progress,
+              draft-wakikawa-req-mobile-cp-separation-00, November 2013.
+
+   [OpenFlow-Spec-v1.4.0]
+              Open Networking Foundation, "OpenFlow Switch
+              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,
+              <http://www.rfc-editor.org/info/rfc1701>.
+
+
+
+
+Wakikawa, et al.             Standards Track                   [Page 10]
+
+RFC 7389                   PMIPv6 CP-UP Split               October 2014
+
+
+   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
+              IPv6 Specification", RFC 2473, December 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,
+              <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,
+              <http://www.rfc-editor.org/info/rfc5810>.
+
+   [RFC6275]  Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
+              in IPv6", RFC 6275, July 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,
+              <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,
+              <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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wakikawa, et al.             Standards Track                   [Page 11]
+
+RFC 7389                   PMIPv6 CP-UP Split               October 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
+   Tokyo  105-7322
+   Japan
+
+   EMail: ryuji.wakikawa@gmail.com
+
+
+   Rajesh S. Pazhyannur
+   Cisco
+   170 West Tasman Drive
+   San Jose, CA  95134
+   United States
+
+   EMail: rpazhyan@cisco.com
+
+
+   Sri Gundavelli
+   Cisco
+   170 West Tasman Drive
+   San Jose, CA  95134
+   United States
+
+   EMail: sgundave@cisco.com
+
+
+   Charles E. Perkins
+   Futurewei Inc.
+   2330 Central Expressway
+   Santa Clara, CA  95050
+   United States
+
+   EMail: charliep@computer.org
+
+
+
+
+
+
+Wakikawa, et al.             Standards Track                   [Page 12]
+