doc: Add RFC documents

1 files changed, 619 insertions, 0 deletions

diff --git a/doc/rfc/rfc6387.txt b/doc/rfc/rfc6387.txt
new file mode 100644
index 0000000..54fe803
--- /dev/null
+++ b/doc/rfc/rfc6387.txt
@@ -0,0 +1,619 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                         A. Takacs
+Request for Comments: 6387                                      Ericsson
+Obsoletes: 5467                                                L. Berger
+Category:  Standards Track                       LabN Consulting, L.L.C.
+ISSN:  2070-1721                                             D. Caviglia
+                                                                Ericsson
+                                                                D. Fedyk
+                                                          Alcatel-Lucent
+                                                               J. Meuric
+                                                   France Telecom Orange
+                                                          September 2011
+
+
+  GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
+
+Abstract
+
+   This document defines a method for the support of GMPLS asymmetric
+   bandwidth bidirectional Label Switched Paths (LSPs).  The approach
+   presented is applicable to any switching technology and builds on the
+   original Resource Reservation Protocol (RSVP) model for the transport
+   of traffic-related parameters.  This document moves the experiment
+   documented in RFC 5467 to the standards track and obsoletes RFC 5467.
+
+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/rfc6387.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Takacs, et. al.              Standards Track                    [Page 1]
+
+RFC 6387         Asymmetric Bandwidth Bidirectional LSP   September 2011
+
+
+Copyright Notice
+
+   Copyright (c) 2011 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
+     1.1.  Background . . . . . . . . . . . . . . . . . . . . . . . .  3
+     1.2.  Approach Overview  . . . . . . . . . . . . . . . . . . . .  3
+     1.3.  Conventions Used in This Document  . . . . . . . . . . . .  4
+   2.  Generalized Asymmetric Bandwidth Bidirectional LSPs  . . . . .  4
+     2.1.  UPSTREAM_FLOWSPEC Object . . . . . . . . . . . . . . . . .  5
+       2.1.1.  Procedures . . . . . . . . . . . . . . . . . . . . . .  5
+     2.2.  UPSTREAM_TSPEC Object  . . . . . . . . . . . . . . . . . .  5
+       2.2.1.  Procedures . . . . . . . . . . . . . . . . . . . . . .  5
+     2.3.  UPSTREAM_ADSPEC Object . . . . . . . . . . . . . . . . . .  6
+       2.3.1.  Procedures . . . . . . . . . . . . . . . . . . . . . .  6
+   3.  Packet Formats . . . . . . . . . . . . . . . . . . . . . . . .  6
+   4.  Compatibility  . . . . . . . . . . . . . . . . . . . . . . . .  7
+   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
+     5.1.  UPSTREAM_FLOWSPEC Object . . . . . . . . . . . . . . . . .  8
+     5.2.  UPSTREAM_TSPEC Object  . . . . . . . . . . . . . . . . . .  8
+     5.3.  UPSTREAM_ADSPEC Object . . . . . . . . . . . . . . . . . .  8
+   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
+   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
+     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
+     7.2.  Informative References . . . . . . . . . . . . . . . . . .  9
+
+1.  Introduction
+
+   GMPLS [RFC3473] introduced explicit support for bidirectional Label
+   Switched Paths (LSPs).  The defined support matched the switching
+   technologies covered by GMPLS, notably Time Division Multiplexing
+   (TDM) and lambdas; specifically, it only supported bidirectional LSPs
+   with symmetric bandwidth allocation.  Symmetric bandwidth
+   requirements are conveyed using the semantics objects defined in
+   [RFC2205] and [RFC2210].
+
+
+
+Takacs, et. al.              Standards Track                    [Page 2]
+
+RFC 6387         Asymmetric Bandwidth Bidirectional LSP   September 2011
+
+
+   GMPLS asymmetric bandwidth bidirectional LSPs are bidirectional LSPs
+   that have different bandwidth reservations in each direction.
+   Support for bidirectional LSPs with asymmetric bandwidth was
+   previously discussed in the context of Ethernet, notably [RFC6060]
+   and [RFC6003].  In that context, asymmetric bandwidth support was
+   considered to be a capability that was unlikely to be deployed, and
+   hence [RFC5467] was published as Experimental.  The MPLS Transport
+   Profile, MPLS-TP, requires that asymmetric bandwidth bidirectional
+   LSPs be supported (see [RFC5654]); therefore, this document is being
+   published on the Standards Track.  This document has no technical
+   changes from the approach defined in [RFC5467].  This document moves
+   the experiment documented in [RFC5467] to the standards track and
+   obsoletes [RFC5467].  This document also removes the Ethernet-
+   technology-specific alternative approach discussed in the appendix of
+   [RFC5467] and maintains only one approach that is suitable for use
+   with any technology.
+
+1.1.  Background
+
+   Bandwidth parameters are transported within RSVP ([RFC2210],
+   [RFC3209], and [RFC3473]) via several objects that are opaque to
+   RSVP.  While opaque to RSVP, these objects support a particular model
+   for the communication of bandwidth information between an RSVP
+   session sender (ingress) and receiver (egress).  The original model
+   of communication, defined in [RFC2205] and maintained in [RFC3209],
+   used the SENDER_TSPEC and ADSPEC objects in Path messages and the
+   FLOWSPEC object in Resv messages.  The SENDER_TSPEC object was used
+   to indicate a sender's data generation capabilities.  The FLOWSPEC
+   object was issued by the receiver and indicated the resources that
+   should be allocated to the associated data traffic.  The ADSPEC
+   object was used to inform the receiver and intermediate hops of the
+   actual resources available for the associated data traffic.
+
+   With the introduction of bidirectional LSPs in [RFC3473], the model
+   of communication of bandwidth parameters was implicitly changed.  In
+   the context of [RFC3473] bidirectional LSPs, the SENDER_TSPEC object
+   indicates the desired resources for both upstream and downstream
+   directions.  The FLOWSPEC object is simply confirmation of the
+   allocated resources.  The definition of the ADSPEC object is either
+   unmodified and only has meaning for downstream traffic, or is
+   implicitly or explicitly ([RFC4606] and [RFC6003]) irrelevant.
+
+1.2.  Approach Overview
+
+   The approach for supporting asymmetric bandwidth bidirectional LSPs
+   defined in this document builds on the original RSVP model for the
+   transport of traffic-related parameters and GMPLS's support for
+   bidirectional LSPs.
+
+
+
+Takacs, et. al.              Standards Track                    [Page 3]
+
+RFC 6387         Asymmetric Bandwidth Bidirectional LSP   September 2011
+
+
+   The defined approach is generic and can be applied to any switching
+   technology supported by GMPLS.  With this approach, the existing
+   SENDER_TSPEC, ADSPEC, and FLOWSPEC objects are complemented with the
+   addition of new UPSTREAM_TSPEC, UPSTREAM_ADSPEC, and
+   UPSTREAM_FLOWSPEC objects.  The existing objects are used in the
+   original fashion defined in [RFC2205] and [RFC2210], and refer only
+   to traffic associated with the LSP flowing in the downstream
+   direction.  The new objects are used in exactly the same fashion as
+   the old objects, but refer to the upstream traffic flow Figure 1
+   shows the bandwidth-related objects used for asymmetric bandwidth
+   bidirectional LSPs.
+
+                    |---|        Path        |---|
+                    | I |------------------->| E |
+                    | n | -SENDER_TSPEC      | g |
+                    | g | -ADSPEC            | r |
+                    | r | -UPSTREAM_FLOWSPEC | e |
+                    | e |                    | s |
+                    | s |        Resv        | s |
+                    | s |<-------------------|   |
+                    |   | -FLOWSPEC          |   |
+                    |   | -UPSTREAM_TSPEC    |   |
+                    |   | -UPSTREAM_ADSPEC   |   |
+                    |---|                    |---|
+
+         Figure 1: Generic Asymmetric Bandwidth Bidirectional LSPs
+
+   The extensions defined in this document are limited to Point-to-Point
+   (P2P) LSPs.  Support for Point-to-Multipoint (P2MP) bidirectional
+   LSPs is not currently defined and, as such, not covered in this
+   document.
+
+1.3.  Conventions Used in This Document
+
+   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 [RFC2119].
+
+2.  Generalized Asymmetric Bandwidth Bidirectional LSPs
+
+   The setup of an asymmetric bandwidth bidirectional LSP is signaled
+   using the bidirectional procedures defined in [RFC3473] together with
+   the inclusion of the new UPSTREAM_FLOWSPEC, UPSTREAM_TSPEC, and
+   UPSTREAM_ADSPEC objects.
+
+   The new upstream objects carry the same information and are used in
+   the same fashion as the existing downstream objects; they differ in
+   that they relate to traffic flowing in the upstream direction while
+
+
+
+Takacs, et. al.              Standards Track                    [Page 4]
+
+RFC 6387         Asymmetric Bandwidth Bidirectional LSP   September 2011
+
+
+   the existing objects relate to traffic flowing in the downstream
+   direction.  The new objects also differ in that they are carried in
+   messages traveling in the opposite direction.
+
+2.1.  UPSTREAM_FLOWSPEC Object
+
+   The format of an UPSTREAM_FLOWSPEC object is the same as a FLOWSPEC
+   object [RFC2210].  This includes the definition of class types and
+   their formats.  The class number of the UPSTREAM_FLOWSPEC object is
+   120 (of the form 0bbbbbbb).
+
+2.1.1.  Procedures
+
+   The Path message of an asymmetric bandwidth bidirectional LSP MUST
+   contain an UPSTREAM_FLOWSPEC object and MUST use the bidirectional
+   LSP formats and procedures defined in [RFC3473].  The C-Type of the
+   UPSTREAM_FLOWSPEC object MUST match the C-Type of the SENDER_TSPEC
+   object used in the Path message.  The contents of the
+   UPSTREAM_FLOWSPEC object MUST be constructed using a format and
+   procedures consistent with those used to construct the FLOWSPEC
+   object that will be used for the LSP, e.g., [RFC2210] or [RFC4328].
+
+   Nodes processing a Path message containing an UPSTREAM_FLOWSPEC
+   object MUST use the contents of the UPSTREAM_FLOWSPEC object in the
+   upstream label and the resource allocation procedure defined in
+   Section 3.1 of [RFC3473].  Consistent with [RFC3473], a node that is
+   unable to allocate a label or internal resources based on the
+   contents of the UPSTREAM_FLOWSPEC object MUST issue a PathErr message
+   with a "Routing problem/MPLS label allocation failure" indication.
+
+2.2.  UPSTREAM_TSPEC Object
+
+   The format of an UPSTREAM_TSPEC object is the same as a SENDER_TSPEC
+   object, which includes the definition of class types and their
+   formats.  The class number of the UPSTREAM_TSPEC object is 121 (of
+   the form 0bbbbbbb).
+
+2.2.1.  Procedures
+
+   The UPSTREAM_TSPEC object describes the traffic flow that originates
+   at the egress.  The UPSTREAM_TSPEC object MUST be included in any
+   Resv message that corresponds to a Path message containing an
+   UPSTREAM_FLOWSPEC object.  The C-Type of the UPSTREAM_TSPEC object
+   MUST match the C-Type of the corresponding UPSTREAM_FLOWSPEC object.
+   The contents of the UPSTREAM_TSPEC object MUST be constructed using a
+   format and procedures consistent with those used to construct the
+   FLOWSPEC object that will be used for the LSP, e.g., [RFC2210] or
+   [RFC4328].  The contents of the UPSTREAM_TSPEC object MAY differ from
+
+
+
+Takacs, et. al.              Standards Track                    [Page 5]
+
+RFC 6387         Asymmetric Bandwidth Bidirectional LSP   September 2011
+
+
+   contents of the UPSTREAM_FLOWSPEC object based on application data
+   transmission requirements.
+
+   When an UPSTREAM_TSPEC object is received by an ingress, the ingress
+   MAY determine that the original reservation is insufficient to
+   satisfy the traffic flow.  In this case, the ingress MAY tear down
+   the LSP and send a PathTear message.  Alternatively, the ingress MAY
+   issue a Path message with an updated UPSTREAM_FLOWSPEC object to
+   modify the resources requested for the upstream traffic flow.  This
+   modification might require the LSP to be re-routed, and in extreme
+   cases might result in the LSP being torn down when sufficient
+   resources are not available along the path of the LSP.
+
+2.3.  UPSTREAM_ADSPEC Object
+
+   The format of an UPSTREAM_ADSPEC object is the same as an ADSPEC
+   object.  This includes the definition of class types and their
+   formats.  The class number of the UPSTREAM_ADSPEC object is 122 (of
+   the form 0bbbbbbb).
+
+2.3.1.  Procedures
+
+   The UPSTREAM_ADSPEC object MAY be included in any Resv message that
+   corresponds to a Path message containing an UPSTREAM_FLOWSPEC object.
+   The C-Type of the UPSTREAM_TSPEC object MUST be consistent with the
+   C-Type of the corresponding UPSTREAM_FLOWSPEC object.  The contents
+   of the UPSTREAM_ADSPEC object MUST be constructed using a format and
+   procedures consistent with those used to construct the ADSPEC object
+   that will be used for the LSP, e.g., [RFC2210] or [RFC6003].  The
+   UPSTREAM_ADSPEC object is processed using the same procedures as the
+   ADSPEC object and, as such, MAY be updated or added at transit nodes.
+
+3.  Packet Formats
+
+   This section presents the RSVP message-related formats as modified by
+   this section.  This document modifies formats defined in [RFC2205],
+   [RFC3209], and [RFC3473].  See [RFC5511] for the syntax used by RSVP.
+   Unmodified formats are not listed.  Three new objects are defined in
+   this section:
+
+      Object name            Applicable RSVP messages
+      ---------------        ------------------------
+      UPSTREAM_FLOWSPEC      Path, PathTear, PathErr, and Notify
+                                 (via sender descriptor)
+      UPSTREAM_TSPEC         Resv, ResvConf, ResvTear, ResvErr, and
+                                 Notify (via flow descriptor list)
+      UPSTREAM_ADSPEC        Resv, ResvConf, ResvTear, ResvErr, and
+                                 Notify (via flow descriptor list)
+
+
+
+Takacs, et. al.              Standards Track                    [Page 6]
+
+RFC 6387         Asymmetric Bandwidth Bidirectional LSP   September 2011
+
+
+   The format of the sender description for bidirectional asymmetric
+   LSPs is:
+
+      <sender descriptor> ::=  <SENDER_TEMPLATE> <SENDER_TSPEC>
+                               [ <ADSPEC> ]
+                               [ <RECORD_ROUTE> ]
+                               [ <SUGGESTED_LABEL> ]
+                               [ <RECOVERY_LABEL> ]
+                               <UPSTREAM_LABEL>
+                               <UPSTREAM_FLOWSPEC>
+
+   The format of the flow descriptor list for bidirectional asymmetric
+   LSPs is:
+
+      <flow descriptor list> ::= <FF flow descriptor list>
+                               | <SE flow descriptor>
+
+      <FF flow descriptor list> ::= <FLOWSPEC>
+                               <UPSTREAM_TSPEC> [ <UPSTREAM_ADSPEC> ]
+                               <FILTER_SPEC>
+                               <LABEL> [ <RECORD_ROUTE> ]
+                               | <FF flow descriptor list>
+                               <FF flow descriptor>
+
+      <FF flow descriptor> ::= [ <FLOWSPEC> ]
+                               [ <UPSTREAM_TSPEC>] [ <UPSTREAM_ADSPEC> ]
+                               <FILTER_SPEC> <LABEL>
+                               [ <RECORD_ROUTE> ]
+
+      <SE flow descriptor> ::= <FLOWSPEC>
+                               <UPSTREAM_TSPEC> [ <UPSTREAM_ADSPEC> ]
+                               <SE filter spec list>
+
+      <SE filter spec list> is unmodified by this document.
+
+4.  Compatibility
+
+   This extension reuses and extends semantics and procedures defined in
+   [RFC2205], [RFC3209], and [RFC3473] to support bidirectional LSPs
+   with asymmetric bandwidth.  Three new objects are defined to indicate
+   the use of asymmetric bandwidth.  Each of these objects is defined
+   with class numbers in the form 0bbbbbbb.  Per [RFC2205], nodes not
+   supporting this extension will not recognize the new class numbers
+   and will respond with an "Unknown Object Class" error.  The error
+   message will propagate to the ingress, which can then take action to
+   avoid the path with the incompatible node or can simply terminate the
+   session.
+
+
+
+
+Takacs, et. al.              Standards Track                    [Page 7]
+
+RFC 6387         Asymmetric Bandwidth Bidirectional LSP   September 2011
+
+
+5.  IANA Considerations
+
+   The IANA has made the assignments described below in the "Class
+   Names, Class Numbers, and Class Types" section of the "RSVP
+   PARAMETERS" registry.
+
+5.1.  UPSTREAM_FLOWSPEC Object
+
+   The class named UPSTREAM_FLOWSPEC has been assigned in the 0bbbbbbb
+   range (120) with the following definition:
+
+        Class Types or C-types:
+
+        Same values as FLOWSPEC object (C-Num 9)
+
+5.2.  UPSTREAM_TSPEC Object
+
+   The class named UPSTREAM_TSPEC has been assigned in the 0bbbbbbb
+   range (121) with the following definition:
+
+        Class Types or C-types:
+
+        Same values as SENDER_TSPEC object (C-Num 12)
+
+5.3.  UPSTREAM_ADSPEC Object
+
+   The class named UPSTREAM_ADSPEC has been assigned in the 0bbbbbbb
+   range (122) with the following definition:
+
+        Class Types or C-types:
+
+        Same values as ADSPEC object (C-Num 13)
+
+6.  Security Considerations
+
+   This document introduces new message objects for use in GMPLS
+   signaling [RFC3473] -- specifically the UPSTREAM_TSPEC,
+   UPSTREAM_ADSPEC, and UPSTREAM_FLOWSPEC objects.  These objects
+   parallel the existing SENDER_TSPEC, ADSPEC, and FLOWSPEC objects but
+   are used in the opposite direction.  As such, any vulnerabilities
+   that are due to the use of the old objects now apply to messages
+   flowing in the reverse direction.
+
+   From a message standpoint, this document does not introduce any new
+   signaling messages or change the relationship between LSRs that are
+   adjacent in the control plane.  As such, this document introduces no
+   additional message- or neighbor-related security considerations.
+
+
+
+
+Takacs, et. al.              Standards Track                    [Page 8]
+
+RFC 6387         Asymmetric Bandwidth Bidirectional LSP   September 2011
+
+
+   See [RFC3473] for relevant security considerations and [RFC5920] for
+   a more general discussion on RSVP-TE security discussions.
+
+7.  References
+
+7.1.  Normative References
+
+   [RFC2205]   Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
+               S. Jamin, "Resource ReSerVation Protocol (RSVP) --
+               Version 1 Functional Specification", RFC 2205, September
+               1997.
+
+   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
+               Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2210]   Wroclawski, J., "The Use of RSVP with IETF Integrated
+               Services", RFC 2210, September 1997.
+
+   [RFC3209]   Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
+               and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
+               Tunnels", RFC 3209, December 2001.
+
+   [RFC3473]   Berger, L., Ed., "Generalized Multi-Protocol Label
+               Switching (GMPLS) Signaling Resource ReserVation
+               Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
+               3473, January 2003.
+
+7.2.  Informative References
+
+   [RFC4606]   Mannie, E. and D. Papadimitriou, "Generalized Multi-
+               Protocol Label Switching (GMPLS) Extensions for
+               Synchronous Optical Network (SONET) and Synchronous
+               Digital Hierarchy (SDH) Control", RFC 4606, August 2006.
+
+   [RFC4328]   Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
+               Switching (GMPLS) Signaling Extensions for G.709 Optical
+               Transport Networks Control", RFC 4328, January 2006.
+
+   [RFC5511]   Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
+               Used to Form Encoding Rules in Various Routing Protocol
+               Specifications", RFC 5511, April 2009.
+
+   [RFC5654]   Niven-Jenkins, B., Ed., Brungard, D., Ed., Betts, M.,
+               Ed., Sprecher, N., and S. Ueno, "Requirements of an MPLS
+               Transport Profile", RFC 5654, September 2009.
+
+   [RFC5920]   Fang, L., Ed., "Security Framework for MPLS and GMPLS
+               Networks", RFC 5920, July 2010.
+
+
+
+Takacs, et. al.              Standards Track                    [Page 9]
+
+RFC 6387         Asymmetric Bandwidth Bidirectional LSP   September 2011
+
+
+   [RFC5467]   Berger, L., Takacs, A., Caviglia, D., Fedyk, D., and J.
+               Meuric, "GMPLS Asymmetric Bandwidth Bidirectional Label
+               Switched Paths (LSPs)", RFC 5467, March 2009.
+
+   [RFC6003]   Papadimitriou, D., "Ethernet Traffic Parameters", RFC
+               6003, October 2010.
+
+   [RFC6060]   Fedyk, D., Shah, H., Bitar, N., and A. Takacs,
+               "Generalized Multiprotocol Label Switching (GMPLS)
+               Control of Ethernet Provider Backbone Traffic Engineering
+               (PBB-TE)", RFC 6060, March 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Takacs, et. al.              Standards Track                   [Page 10]
+
+RFC 6387         Asymmetric Bandwidth Bidirectional LSP   September 2011
+
+
+Authors' Addresses
+
+   Attila Takacs
+   Ericsson
+   Konyves Kalman krt. 11.
+   Budapest, 1097
+   Hungary
+
+   EMail: attila.takacs@ericsson.com
+
+
+   Lou Berger
+   LabN Consulting, L.L.C.
+
+   EMail: lberger@labn.net
+
+
+   Diego Caviglia
+   Ericsson
+   Via A. Negrone 1/A
+   Genova-Sestri Ponente,
+   Italy
+
+   Phone: +390106003738
+   Fax:
+   EMail: diego.caviglia@ericsson.com
+
+
+   Don Fedyk
+   Alcatel-Lucent
+   Groton, MA
+   USA
+
+   EMail: donald.fedyk@alcatel-lucent.com
+
+
+   Julien Meuric
+   France Telecom Orange
+   2, avenue Pierre Marzin
+   Lannion Cedex,   22307
+   France
+
+   EMail: julien.meuric@orange.com
+
+
+
+
+
+
+
+
+Takacs, et. al.              Standards Track                   [Page 11]
+