doc: Add RFC documents

1 files changed, 787 insertions, 0 deletions

diff --git a/doc/rfc/rfc6041.txt b/doc/rfc/rfc6041.txt
new file mode 100644
index 0000000..47f6379
--- /dev/null
+++ b/doc/rfc/rfc6041.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         A. Crouch
+Request for Comments: 6041                                   H. Khosravi
+Category: Informational                                            Intel
+ISSN: 2070-1721                                            A. Doria, Ed.
+                                                                     LTU
+                                                                 X. Wang
+                                                                  Huawei
+                                                                K. Ogawa
+                                                         NTT Corporation
+                                                            October 2010
+
+
+           Forwarding and Control Element Separation (ForCES)
+                        Applicability Statement
+
+Abstract
+
+   The Forwarding and Control Element Separation (ForCES) protocol
+   defines a standard framework and mechanism for the interconnection
+   between control elements and forwarding elements in IP routers and
+   similar devices.  In this document we describe the applicability of
+   the ForCES model and protocol.  We provide example deployment
+   scenarios and functionality, as well as document applications that
+   would be inappropriate for ForCES.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   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).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see 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/rfc6041.
+
+
+
+
+
+
+
+
+
+
+
+Crouch, et al.                Informational                     [Page 1]
+
+RFC 6041             ForCES Applicability Statement         October 2010
+
+
+Copyright Notice
+
+   Copyright (c) 2010 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.
+
+   This document may contain material from IETF Documents or IETF
+   Contributions published or made publicly available before November
+   10, 2008.  The person(s) controlling the copyright in some of this
+   material may not have granted the IETF Trust the right to allow
+   modifications of such material outside the IETF Standards Process.
+   Without obtaining an adequate license from the person(s) controlling
+   the copyright in such materials, this document may not be modified
+   outside the IETF Standards Process, and derivative works of it may
+   not be created outside the IETF Standards Process, except to format
+   it for publication as an RFC or to translate it into languages other
+   than English.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crouch, et al.                Informational                     [Page 2]
+
+RFC 6041             ForCES Applicability Statement         October 2010
+
+
+Table of Contents
+
+   1. Introduction ....................................................3
+   2. Purpose .........................................................4
+   3. Terminology .....................................................4
+   4. Applicability to IP Networks ....................................4
+      4.1. Applicable Services ........................................5
+           4.1.1. Association, Capability Discovery, and
+                  Information Exchange ................................5
+           4.1.2. Topology Information Exchange .......................6
+           4.1.3. Configuration .......................................6
+           4.1.4. Routing Exchange ....................................6
+           4.1.5. QoS Capabilities Exchange and Configuration .........7
+           4.1.6. Security Exchange ...................................7
+           4.1.7. Filtering Exchange and Firewalls ....................7
+           4.1.8. Encapsulation/Tunneling Exchange ....................7
+           4.1.9. NAT and Application-Level Gateways ..................7
+           4.1.10. Measurement and Accounting .........................7
+           4.1.11. Diagnostics ........................................8
+           4.1.12. Redundancy and Failover ............................8
+      4.2. CE-FE Link Capability ......................................8
+      4.3. CE/FE Locality .............................................8
+   5. Security Considerations .........................................9
+   6. ForCES Manageability ............................................9
+      6.1. The NE as an Atomic Element ...............................10
+      6.2. The NE as Composed of Manageable Elements .................10
+      6.3. ForCES Protocol MIB .......................................10
+           6.3.1. MIB Management of an FE ............................11
+      6.4. The FEM and CEM ...........................................12
+   7. Contributors ...................................................12
+   8. Acknowledgments ................................................12
+   9. References .....................................................12
+      9.1. Normative References ......................................12
+      9.2. Informative References ....................................13
+
+1.  Introduction
+
+   The Forwarding and Control Element Separation (ForCES) protocol
+   defines a standard framework and mechanism for the exchange of
+   information between the logically separate functionality of the
+   control and data forwarding planes of IP routers and similar devices.
+   It focuses on the communication necessary for separation of control
+   plane functionality such as routing protocols, signaling protocols,
+   and admission control from data forwarding plane per-packet
+   activities such as packet forwarding, queuing, and header editing.
+
+
+
+
+
+
+Crouch, et al.                Informational                     [Page 3]
+
+RFC 6041             ForCES Applicability Statement         October 2010
+
+
+   This document defines the applicability of the ForCES mechanisms.  It
+   describes types of configurations and settings where ForCES is most
+   appropriately applied.  This document also describes scenarios and
+   configurations where ForCES would not be appropriate for use.
+
+2.  Purpose
+
+   The purpose of the ForCES Applicability Statement is to capture the
+   intent of the ForCES protocol [RFC5810] designers as to how the
+   protocol could be used in conjunction with the ForCES model [RFC5812]
+   and a Transport Mapping Layer [RFC5811].
+
+3.  Terminology
+
+   A set of concepts associated with ForCES was introduced in
+   "Requirements for Separation of IP Control and Forwarding" [RFC3654]
+   and in "Forwarding and Control Element Separation (ForCES) Framework"
+   [RFC3746].  The terminology associated with these concepts and with
+   the protocol elements in ForCES is defined in the "Forwarding and
+   Control Element Separation (ForCES) Protocol Specification"
+   [RFC5810].
+
+   The reader is directed to these documents for the conceptual
+   introduction and for definitions, including the following acronyms:
+
+   o  CE: control element
+
+   o  CEM: CE Manager
+
+   o  FE: forwarding element
+
+   o  FEM: FE Manager
+
+   o  ForCES: Forwarding and Control Element Separation protocol
+
+   o  LFB: Logical Function Block
+
+   o  NE: ForCES network element
+
+   o  TML: Transport Mapping Layer
+
+4.  Applicability to IP Networks
+
+   This section lists the areas of ForCES applicability in IP network
+   devices.  Some relatively low-end routing systems may be implemented
+   on simple hardware that performs both control and packet forwarding
+   functionality.  ForCES may not be useful for such devices.
+
+
+
+
+Crouch, et al.                Informational                     [Page 4]
+
+RFC 6041             ForCES Applicability Statement         October 2010
+
+
+   Higher-end routing systems typically distribute work amongst several
+   interface-processing elements, and these devices (FEs) therefore need
+   to communicate with the control element(s) to perform their job.  A
+   higher-end router may also distribute control processing amongst
+   several processing elements (CEs).  ForCES provides a standard way to
+   do this communication.  ForCES also provides support for high-
+   availability configurations that include a primary CE and one or more
+   secondary CEs.
+
+   The remainder of this section lists the applicable services that
+   ForCES may support, applicable FE functionality, applicable CE-FE
+   link scenarios, and applicable topologies in which ForCES may be
+   deployed.
+
+4.1.  Applicable Services
+
+   In this section we describe the applicability of ForCES for the
+   following control-forwarding-plane services:
+
+   o  Association, Capability Discovery, and Information Exchange
+
+   o  Topology Information Exchange
+
+   o  Configuration
+
+   o  Routing Exchange
+
+   o  Quality of Service (QoS) Exchange
+
+   o  Security Exchange
+
+   o  Filtering Exchange
+
+   o  Encapsulation/Tunneling Exchange
+
+   o  NAT and Application-Level Gateways
+
+   o  Measurement and Accounting
+
+   o  Diagnostics
+
+   o  CE Redundancy or CE Failover
+
+4.1.1.  Association, Capability Discovery, and Information Exchange
+
+   Association is the first step of the ForCES protocol exchange in
+   which capability discovery and exchange happens between one or more
+   CEs and the FEs.  ForCES assumes that CEs and FEs already have
+
+
+
+Crouch, et al.                Informational                     [Page 5]
+
+RFC 6041             ForCES Applicability Statement         October 2010
+
+
+   sufficient information to begin communication in a secure manner.
+   The ForCES protocol is only applicable after CEs and FEs have
+   discovered each other.  ForCES makes no assumption about whether
+   discovery was performed using a dynamic protocol or merely static
+   configuration.  Some discussion about how this can occur can be found
+   in Section 6.4 of this document.
+
+   During the association phase, CEs and FEs exchange capability
+   information with each other.  For example, the FEs express the number
+   of interface ports they provide, as well as the static and
+   configurable attributes of each port.
+
+   In addition to initial configuration, the CEs and FEs also exchange
+   dynamic configuration changes using ForCES.  For example, FEs
+   asynchronously inform the CEs of an increase/decrease in available
+   resources or capabilities on the FE.
+
+4.1.2.  Topology Information Exchange
+
+   In this context, topology information relates to how the FEs are
+   interconnected with each other with respect to packet forwarding.
+   Topology discovery is outside the scope of the ForCES protocol.  An
+   implementation can choose its own method of topology discovery (for
+   example, it can use a standard topology discovery protocol or apply a
+   static topology configuration policy).  Once the topology is
+   established, the ForCES protocol may be used to transmit the
+   resulting information to the CEs.
+
+4.1.3.  Configuration
+
+   ForCES is used to perform FE configuration.  For example, CEs set
+   configurable FE attributes such as IP addresses, etc. for their
+   interfaces.
+
+4.1.4.  Routing Exchange
+
+   ForCES may be used to deliver packet forwarding information resulting
+   from CE routing calculations.  For example, CEs may send forwarding
+   table updates to the FEs, so that they can make forwarding decisions.
+   FEs may inform the CEs in the event of a forwarding table miss.
+   ForCES may also be used to configure Equal Cost Multi-Path (ECMP)
+   capability.
+
+
+
+
+
+
+
+
+
+Crouch, et al.                Informational                     [Page 6]
+
+RFC 6041             ForCES Applicability Statement         October 2010
+
+
+4.1.5.  QoS Capabilities Exchange and Configuration
+
+   ForCES may be used to exchange QoS capabilities between CEs and FEs.
+   For example, an FE may express QoS capabilities to the CE.  Such
+   capabilities might include metering, policing, shaping, and queuing
+   functions.  The CE may use ForCES to configure these capabilities.
+
+4.1.6.  Security Exchange
+
+   ForCES may be used to exchange security information between a CE and
+   the FEs it controls.  For example, the FE may use ForCES to express
+   the types of encryption that it is capable of using in an IP Security
+   (IPsec) tunnel.  The CE may use ForCES to configure such a tunnel.
+   The CEs would be responsible for the NE dynamic key exchanges and
+   updates.
+
+4.1.7.  Filtering Exchange and Firewalls
+
+   ForCES may be used to exchange filtering information.  For example,
+   FEs may use ForCES to express the filtering functions, such as
+   classification and action, that they can perform, and the CE may
+   configure these capabilities.
+
+4.1.8.  Encapsulation/Tunneling Exchange
+
+   ForCES may be used to exchange encapsulation capabilities of an FE,
+   such as tunneling, and the configuration of such capabilities.
+
+4.1.9.  NAT and Application-Level Gateways
+
+   ForCES may be used to exchange configuration information for Network
+   Address Translators.  Whilst ForCES is not specifically designed for
+   the configuration of application-level gateway functionality, this
+   may be in scope for some types of application-level gateways.
+
+4.1.10.  Measurement and Accounting
+
+   ForCES may be used to exchange configuration information regarding
+   traffic measurement and accounting functionality.  In this area,
+   ForCES may overlap somewhat with functionality provided by network
+   management mechanisms such as the Simple Network Management Protocol
+   (SNMP).  In some cases, ForCES may be used to convey information to
+   the CE to be reported externally using SNMP.  A further discussion of
+   this capability is covered in Section 6 of this document.
+
+
+
+
+
+
+
+Crouch, et al.                Informational                     [Page 7]
+
+RFC 6041             ForCES Applicability Statement         October 2010
+
+
+4.1.11.  Diagnostics
+
+   ForCES may be used for CEs and FEs to exchange diagnostic
+   information.  For example, an FE can send self-test results to a CE.
+
+4.1.12.  Redundancy and Failover
+
+   The ForCES architecture includes mechanisms that allow for multiple
+   redundant CEs and FEs in a ForCES NE.  The ForCES-model LFB
+   definitions provide sufficient component details via component
+   identifiers to be universally unique within an NE.  The ForCES
+   protocol includes mechanisms to facilitate transactions as well as
+   atomicity across the NE.
+
+   Given the above, it is possible to deploy redundant CEs and FEs that
+   incorporate failover.
+
+4.2.  CE-FE Link Capability
+
+   When using ForCES, the bandwidth of the CE-FE link is a
+   consideration, and cannot be ignored.  For example, sending a full
+   routing table is reasonable over a high-bandwidth link, but could be
+   non-trivial over a lower-bandwidth link.  ForCES should be
+   sufficiently future-proof to be applicable in scenarios where routing
+   tables grow to several orders of magnitude greater than their current
+   size.  However, we also note that not all IP routers need full
+   routing tables.
+
+4.3.  CE/FE Locality
+
+   ForCES is intended for environments where one of the following
+   applies:
+
+   o  The control interconnect is some form of local bus, switch, or
+      LAN, where reliability is high, closely controlled, and not
+      susceptible to external disruption that does not also affect the
+      CEs and/or FEs.
+
+   o  The control interconnect shares its fate with the FE's forwarding
+      function.  Typically this is because the control connection is
+      also the FE's primary packet forwarding connection, and so if that
+      link goes down, the FE cannot forward packets anyway.
+
+   The key guideline is that the reliability of the device should not be
+   significantly reduced by the separation of control and forwarding
+   functionality.
+
+
+
+
+
+Crouch, et al.                Informational                     [Page 8]
+
+RFC 6041             ForCES Applicability Statement         October 2010
+
+
+   Taking this into account, ForCES is applicable in the following CE/FE
+   localities:
+
+   Single Box NE:
+      chassis with multiple CEs and FEs set up.  ForCES is applicable in
+      localities consisting of control and forwarding elements that are
+      components in the same physical box.
+
+      Example: a network element with a single control blade, and one or
+      more forwarding blades, all present in the same chassis and
+      sharing an interconnect such as Ethernet or Peripheral Component
+      Interconnect (PCI).  In this locality, the majority of the data
+      traffic being forwarded typically does not traverse the same links
+      as the ForCES control traffic.
+
+   Multiple Box NE:
+      separated CE and FE, where physical locality could be the same
+      rack, room, or building; or long distances that could span across
+      continents and oceans.  ForCES is applicable in localities
+      consisting of control and forwarding elements that are separated
+      by a single hop or multiple hops in the network.
+
+5.  Security Considerations
+
+   The ForCES protocol allows for a variety of security levels
+   [RFC5810].  When operating under a secured physical environment, or
+   for other operational concerns (in some cases, performance issues),
+   the operator may turn off all the security functions between CEs and
+   FEs.  When the operator makes a decision to secure the path between
+   the FEs and CEs, then the operator chooses from one of the options
+   provided by the TML.  Security choices provided by the TML take
+   effect during the pre-association phase of the ForCES protocol.  An
+   operator may choose to use all, some, or none of the security
+   services provided by the TML in a CE-FE connection.  A ForCES NE is
+   required to provide CE/FE node authentication services, and may
+   provide message integrity and confidentiality services.  The NE may
+   provide these services by employing IPsec or Transport Layer Security
+   (TLS), depending on the choice of TML used in the deployment of
+   the NE.
+
+6.  ForCES Manageability
+
+   From the architectural perspective, the ForCES NE is a single network
+   element.  As an example, if the ForCES NE is specifically a router
+   that needs to be managed, then it should be managed in essentially
+   the same way any router should be managed.  From another perspective,
+   element management could directly view the individual entities and
+   interfaces that make up a ForCES NE.  However, any element management
+
+
+
+Crouch, et al.                Informational                     [Page 9]
+
+RFC 6041             ForCES Applicability Statement         October 2010
+
+
+   updates made directly on these entities and interfaces may compromise
+   the control relationship between the CEs and the FEs, unless the
+   update mechanism has been accounted for in the model used by the NE.
+
+6.1.  The NE as an Atomic Element
+
+   From the ForCES Requirements [RFC3654], Section 4, point 4:
+
+      A NE MUST support the appearance of a single functional device.
+
+   As a single functional device, a ForCES NE runs protocols, and each
+   of the protocols has its own existing manageability aspects that are
+   documented elsewhere.  As an example, a router would also have a
+   configuration interface.  When viewed in this manner, the NE is
+   controlled as a single routing entity, and no new management beyond
+   what is already available for routers and routing protocols would be
+   required for a ForCES NE.  Management commands on a management
+   interface to the NE will arrive at the CE and may require ForCES
+   interactions between the CE and FEs to complete.  This may impact the
+   atomicity of such commands and may require careful implementation by
+   the CE.
+
+6.2.  The NE as Composed of Manageable Elements
+
+   When viewed as a decomposed set of elements from the management
+   perspective, the ForCES NE is divided into a set of one of more
+   control elements, forwarding elements, and the interfaces between
+   them.  The interface functionality between the CE and the FE is
+   provided by the ForCES protocol.  A MIB module is provided for the
+   purpose of gaining management information on the operation of the
+   protocol described in Section 6.3 of this document.
+
+   Additionally, the architecture makes provisions for configuration
+   control of the individual CEs and FEs.  This is handled by elements
+   called the FE Manager (FEM) and the CE Manager (CEM).  Specifically,
+   from the ForCES Requirements RFC [RFC3654], Section 4, point 4:
+
+      However, external entities (e.g., FE Managers and CE Managers) MAY
+      have direct access to individual ForCES protocol elements for
+      providing information to transition them from the pre-association
+      to the post-association phase.
+
+6.3.  ForCES Protocol MIB
+
+   The ForCES MIB [RFC5813] defines a primarily read-only MIB module
+   that captures information related to the ForCES protocol.  This
+   includes state information about the associations between CE(s) and
+   FE(s) in the NE.
+
+
+
+Crouch, et al.                Informational                    [Page 10]
+
+RFC 6041             ForCES Applicability Statement         October 2010
+
+
+   The ForCES MIB does not include information that is specified in
+   other MIB modules, such as packet counters for interfaces, etc.
+
+   More specifically, the information in the ForCES MIB module relative
+   to associations includes:
+
+   o  identifiers of the elements in the association
+
+   o  state of the association
+
+   o  configuration parameters of the association
+
+   o  statistics of the association
+
+6.3.1.  MIB Management of an FE
+
+   While it is possible to manage an FE from an element manager, several
+   requirements relating to this have been included in the ForCES
+   Requirements.
+
+   From the ForCES Requirements [RFC3654], Section 4, point 14:
+
+      1. The ability for a management tool (e.g., SNMP) to be used to
+         read (but not change) the state of FE SHOULD NOT be precluded.
+
+      2. It MUST NOT be possible for management tools (e.g., SNMP, etc)
+         to change the state of a FE in a manner that affects overall NE
+         behavior without the CE being notified.
+
+   The ForCES Framework [RFC3746], Section 5.7, goes further in
+   discussing the manner in which FEs should handle management requests
+   that are specifically directed to the FE:
+
+      (For a ForCES NE that is an IP router,) RFC 1812 [RFC1812] also
+      dictates that "Routers must be manageable by SNMP".  In general,
+      for the post-association phase, most external management tasks
+      (including SNMP) should be done through interaction with the CE in
+      order to support the appearance of a single functional device.
+      Therefore, it is recommended that an SNMP agent be implemented by
+      CEs and that the SNMP messages received by FEs be redirected to
+      their CEs.  AgentX framework defined in RFC 2741 [RFC2741]) may be
+      applied here such that CEs act in the role of master agent to
+      process SNMP messages while FEs act in the role of subagent to
+      provide access to the MIB objects residing on FEs.  AgentX
+      protocol messages between the master agent (CE) and the subagent
+      (FE) are encapsulated and transported via ForCES, just like data
+      packets from any other application layer protocols.
+
+
+
+
+Crouch, et al.                Informational                    [Page 11]
+
+RFC 6041             ForCES Applicability Statement         October 2010
+
+
+6.4.  The FEM and CEM
+
+   Though out of scope for the initial ForCES specification effort, the
+   ForCES architecture includes two entities: the CE Manager (CEM) and
+   the FE Manager (FEM).  From the ForCES Protocol Specification
+   [RFC5810]:
+
+   CE Manager (CEM):
+      A logical entity responsible for generic CE management tasks.  It
+      is particularly used during the pre-association phase to determine
+      with which FE(s) a CE should communicate.
+
+   FE Manager (FEM):
+      A logical entity responsible for generic FE management tasks.  It
+      is used during the pre-association phase to determine with which
+      CE(s) an FE should communicate.
+
+7.  Contributors
+
+   Mark Handley was an initial author involved in the earlier versions
+   of this document.
+
+8.  Acknowledgments
+
+   Many of the participants in the ForCES WG, as well as fellow
+   employees of the authors, have provided valuable input into this
+   work.  Particular thanks go to Jamal Hadi Salim, our WG chair and
+   document shepherd; and to Adrian Farrel, the AD for the area; for
+   their review, comments, and encouragement, without which this
+   document might never have been completed.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC1812]   Baker, F., "Requirements for IP Version 4 Routers",
+               RFC 1812, June 1995.
+
+   [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.
+
+   [RFC5811]   Hadi Salim, J. and K. Ogawa, "SCTP-Based Transport
+               Mapping Layer (TML) for the Forwarding and Control
+               Element Separation (ForCES) Protocol", RFC 5811,
+               March 2010.
+
+
+
+
+Crouch, et al.                Informational                    [Page 12]
+
+RFC 6041             ForCES Applicability Statement         October 2010
+
+
+   [RFC5812]   Halpern, J. and J. Hadi Salim, "Forwarding and Control
+               Element Separation (ForCES) Forwarding Element Model",
+               RFC 5812, March 2010.
+
+   [RFC5813]   Haas, R., "Forwarding and Control Element Separation
+               (ForCES) MIB", RFC 5813, March 2010.
+
+9.2.  Informative References
+
+   [RFC2741]   Daniele, M., Wijnen, B., Ellison, M., and D. Francisco,
+               "Agent Extensibility (AgentX) Protocol Version 1",
+               RFC 2741, January 2000.
+
+   [RFC3654]   Khosravi, H. and T. Anderson, "Requirements for
+               Separation of IP Control and Forwarding", RFC 3654,
+               November 2003.
+
+   [RFC3746]   Yang, L., Dantu, R., Anderson, T., and R. Gopal,
+               "Forwarding and Control Element Separation (ForCES)
+               Framework", RFC 3746, April 2004.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Crouch, et al.                Informational                    [Page 13]
+
+RFC 6041             ForCES Applicability Statement         October 2010
+
+
+Authors' Addresses
+
+   Alan Crouch
+   Intel
+   2111 NE 25th Avenue
+   Hillsboro, OR  97124
+   USA
+
+   Phone: +1 503 264 2196
+   EMail: alan.crouch@intel.com
+
+
+   Hormuzd Khosravi
+   Intel
+   2111 NE 25th Avenue
+   Hillsboro, OR  97124
+   USA
+
+   Phone: 1-503-264-0334
+   EMail: hormuzd.m.khosravi@intel.com
+
+
+   Avri Doria (editor)
+   LTU
+   Lulea University of Technology
+   Sweden
+
+   Phone: +46 73 277 1788
+   EMail: avri@acm.org
+
+
+   Xin-ping Wang
+   Huawei
+   Beijing
+   China
+
+   Phone: +86 10 82836067
+   EMail: carly.wang@huawei.com
+
+
+   Kentaro Ogawa
+   NTT Corporation
+   3-9-11 Midori-cho
+   Musashino-shi, Tokyo  180-8585
+   Japan
+
+   EMail: ogawa.kentaro@lab.ntt.co.jp
+
+
+
+
+Crouch, et al.                Informational                    [Page 14]
+