From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001
From: Thomas Voss <mail@thomasvoss.com>
Date: Wed, 27 Nov 2024 20:54:24 +0100
Subject: doc: Add RFC documents

---
 doc/rfc/rfc5467.txt | 787 ++++++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 787 insertions(+)
 create mode 100644 doc/rfc/rfc5467.txt

(limited to 'doc/rfc/rfc5467.txt')

diff --git a/doc/rfc/rfc5467.txt b/doc/rfc/rfc5467.txt
new file mode 100644
index 0000000..e6a1f89
--- /dev/null
+++ b/doc/rfc/rfc5467.txt
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group                                          L. Berger
+Request for Comments: 5467                                          LabN
+Category: Experimental                                         A. Takacs
+                                                                Ericsson
+                                                             D. Caviglia
+                                                                Ericsson
+                                                                D. Fedyk
+                                                                  Nortel
+                                                               J. Meuric
+                                                          France Telecom
+                                                              March 2009
+
+
+  GMPLS Asymmetric Bandwidth Bidirectional Label Switched Paths (LSPs)
+
+Status of This Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  It does not specify an Internet standard of any kind.
+   Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (c) 2009 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 in effect on the date of
+   publication of this document (http://trustee.ietf.org/license-info).
+   Please review these documents carefully, as they describe your rights
+   and restrictions with respect to this document.
+
+   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.
+
+
+
+
+
+
+
+Berger, et al.                Experimental                      [Page 1]
+
+RFC 5467         Asymmetric Bandwidth Bidirectional LSP       March 2009
+
+
+Abstract
+
+   This document defines a method for the support of GMPLS asymmetric
+   bandwidth bidirectional Label Switched Paths (LSPs).  The presented
+   approach is applicable to any switching technology and builds on the
+   original Resource Reservation Protocol (RSVP) model for the transport
+   of traffic-related parameters.  The procedures described in this
+   document are experimental.
+
+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
+   Appendix A. Alternate Approach Using ADSPEC Object.................11
+      A.1. Applicability .............................................11
+      A.2. Overview ..................................................11
+      A.3. Procedures ................................................12
+      A.4. Compatibility .............................................13
+
+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].
+
+
+
+
+Berger, et al.                Experimental                      [Page 2]
+
+RFC 5467         Asymmetric Bandwidth Bidirectional LSP       March 2009
+
+
+   Recent work ([GMPLS-PBBTE] and [MEF-TRAFFIC]) has looked at extending
+   GMPLS to control Ethernet switching.  In this context, there has been
+   discussion of the support of bidirectional LSPs with asymmetric
+   bandwidth.  (That is, bidirectional LSPs that have different
+   bandwidth reservations in each direction.)  This discussion motivated
+   the extensions defined in this document, which may be used with any
+   switching technology to signal asymmetric bandwidth bidirectional
+   LSPs.  The procedures described in this document are experimental.
+
+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 allocated 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 [MEF-TRAFFIC]) 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.  An alternative approach was considered and
+   rejected in favor of the more generic approach presented below.  For
+   reference purposes only, the rejected approach is summarized in
+   Appendix A.
+
+   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
+
+
+
+Berger, et al.                Experimental                      [Page 3]
+
+RFC 5467         Asymmetric Bandwidth Bidirectional LSP       March 2009
+
+
+   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
+   the existing objects relate to traffic flowing in the downstream
+   direction.  The new objects also differ in that they are used on
+   messages in the opposite directions.
+
+
+
+
+Berger, et al.                Experimental                      [Page 4]
+
+RFC 5467         Asymmetric Bandwidth Bidirectional LSP       March 2009
+
+
+2.1.  UPSTREAM_FLOWSPEC Object
+
+   The format of an UPSTREAM_FLOWSPEC object is the same as a FLOWSPEC
+   object.  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.  This 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
+   contents of the UPSTREAM_FLOWSPEC object based on application data
+   transmission requirements.
+
+
+
+
+
+Berger, et al.                Experimental                      [Page 5]
+
+RFC 5467         Asymmetric Bandwidth Bidirectional LSP       March 2009
+
+
+   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 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.
+
+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 [MEF-TRAFFIC].  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 [RSVP-BNF] 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)
+
+
+
+
+
+
+
+Berger, et al.                Experimental                      [Page 6]
+
+RFC 5467         Asymmetric Bandwidth Bidirectional LSP       March 2009
+
+
+   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.  To indicate the use of asymmetric
+   bandwidth, three new objects are defined.  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 should 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 may simply
+   terminate the session.
+
+
+
+
+Berger, et al.                Experimental                      [Page 7]
+
+RFC 5467         Asymmetric Bandwidth Bidirectional LSP       March 2009
+
+
+5.  IANA Considerations
+
+   IANA has assigned new values for namespaces defined in this section
+   and reviewed in this subsection.
+
+   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
+
+   A new class named UPSTREAM_FLOWSPEC has been created 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
+
+   A new class named UPSTREAM_TSPEC has been created 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
+
+   A new class named UPSTREAM_ADSPEC has been created 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 exiting 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.
+
+
+
+
+
+
+Berger, et al.                Experimental                      [Page 8]
+
+RFC 5467         Asymmetric Bandwidth Bidirectional LSP       March 2009
+
+
+   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.
+
+   See [RFC3473] for relevant security considerations, and [SEC-
+   FRAMEWORK] 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.
+
+   [RFC2210]       Wroclawski, J., "The Use of RSVP with IETF Integrated
+                   Services", RFC 2210, September 1997.
+
+   [RFC2119]       Bradner, S., "Key words for use in RFCs to Indicate
+                   Requirement Levels", BCP 14, RFC 2119, March 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
+
+   [GMPLS-PBBTE]   Fedyk, D., et al "GMPLS Control of Ethernet", Work in
+                   Progress, July 2008.
+
+   [MEF-TRAFFIC]   Papadimitriou, D., "MEF Ethernet Traffic Parameters,"
+                   Work in Progress, October 2008.
+
+   [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.
+
+
+
+
+
+Berger, et al.                Experimental                      [Page 9]
+
+RFC 5467         Asymmetric Bandwidth Bidirectional LSP       March 2009
+
+
+   [RFC4328]       Papadimitriou, D., Ed., "Generalized Multi-Protocol
+                   Label Switching (GMPLS) Signaling Extensions for
+                   G.709 Optical Transport Networks Control", RFC 4328,
+                   January 2006.
+
+   [RSVP-BNF]      Farrel, A. "Reduced Backus-Naur Form (RBNF) A Syntax
+                   Used in Various Protocol Specifications", Work in
+                   Progress, November 2008.
+
+   [SEC-FRAMEWORK] Fang, L., Ed., "Security Framework for MPLS and GMPLS
+                   Networks", Work in Progress, November 2008.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger, et al.                Experimental                     [Page 10]
+
+RFC 5467         Asymmetric Bandwidth Bidirectional LSP       March 2009
+
+
+A.  Appendix A: Alternate Approach Using ADSPEC Object
+
+   This section is included for historic purposes and its implementation
+   is NOT RECOMMENDED.
+
+A.1.  Applicability
+
+   This section presents an alternate method for the support of
+   asymmetric bandwidth bidirectional LSP establishment with a single
+   RSVP-TE signaling session.  This approach differs in applicability
+   and generality from the approach presented in the main body of this
+   document.  In particular, this approach is technology-specific; it
+   uses the ADSPEC object to carry traffic parameters for upstream data
+   and requires the Metro Ethernet Forum (MEF) Ethernet Traffic
+   Parameter, while the approach presented above is suitable for use
+   with any technology.
+
+   The generalized asymmetric bandwidth bidirectional LSP presented in
+   the main body of this document has the benefit of being applicable to
+   any switching technology, but requires support for three new types of
+   object classes, i.e., the UPSTREAM_TSPEC, UPSTREAM_ADSPEC, and
+   UPSTREAM_FLOWSPEC objects.
+
+   The solution presented in this section is based on the
+    Ethernet-specific ADSPEC object, and is referred to as the "ADSPEC
+   Object" approach.  This approach limits applicability to cases where
+   the [MEF-TRAFFIC] traffic parameters are appropriate, and to
+   switching technologies that define no use for the ADSPEC object.
+   While ultimately it is this limited scope that has resulted in this
+   approach being relegated to an Appendix, the semantics of this
+   approach are quite simple in that they only require the definition of
+   a new ADSPEC object C-Type.
+
+   In summary, the "ADSPEC Object" approach presented in this section
+   SHOULD NOT be implemented.
+
+A.2.  Overview
+
+   The "ADSPEC Object" approach is specific to Ethernet and uses [MEF-
+   TRAFFIC] traffic parameters.  This approach is not generic and is
+   aimed at providing asymmetric bandwidth bidirectional LSPs for just
+   Ethernet transport.  With this approach, the ADSPEC object carries
+   the traffic parameters for the upstream data flow.  SENDER_TSPEC
+   object is used to indicate the traffic parameters for the downstream
+   data flow.  The FLOWSPEC object provides confirmation of the
+   allocated downstream resources.  Confirmation of the upstream
+   resource allocation is a Resv message, as any resource allocation
+
+
+
+
+Berger, et al.                Experimental                     [Page 11]
+
+RFC 5467         Asymmetric Bandwidth Bidirectional LSP       March 2009
+
+
+   failure for the upstream direction will always result in a PathErr
+   message.  Figure 2 shows the bandwidth-related objects used in the
+   first approach.
+
+                            |---|        Path      |---|
+                            | I |----------------->| E |
+                            | n | -SENDER_TSPEC    | g |
+                            | g | -ADSPEC          | r |
+                            | r |                  | e |
+                            | e |        Resv      | s |
+                            | s |<-----------------| s |
+                            | s | -FLOWSPEC        |   |
+                            |---|                  |---|
+
+   Figure 2: Asymmetric Bandwidth Bidirectional LSPs Using ADSPEC Object
+
+   In the "ADSPEC Object" approach, the setup of an asymmetric bandwidth
+   bidirectional LSP would be signaled using the bidirectional
+   procedures defined in [RFC3473] together with the inclusion of a new
+   ADSPEC object.  The new ADSPEC object would be specific to Ethernet
+   and could be called the Ethernet Upstream Traffic Parameter ADSPEC
+   object.  The Ethernet Upstream Traffic Parameter ADSPEC object would
+   use the Class-Number 13 and C-Type UNASSIGNED (this approach should
+   not be implemented).  The format of the object would be the same as
+   the Ethernet SENDER_TSPEC object defined in [MEF-TRAFFIC].
+
+   This approach would not modify behavior of symmetric bandwidth LSPs.
+   Per [MEF-TRAFFIC], such LSPs are signaled either without an ADSPEC or
+   with an INTSERV ADSPEC.
+
+   The defined approach could be reused to support asymmetric bandwidth
+   bidirectional LSPs for other types of switching technologies.  All
+   that would be needed would be to define the proper ADSPEC object.
+
+A.3.  Procedures
+
+   Using the approach presented in this section, the process of
+   establishing an asymmetric bandwidth bidirectional LSP would follow
+   the process of establishing a symmetric bandwidth bidirectional LSP,
+   as defined in Section 3 of [RFC3473], with two modifications.  These
+   modifications would be followed when an incoming Path message is
+   received containing an Upstream_Label object and the Ethernet
+   Upstream Traffic Parameter ADSPEC object.
+
+   The first modification to the symmetric bandwidth process would be
+   that when allocating the upstream label, the bandwidth associated
+   with the upstream label would be taken from the Ethernet Upstream
+   Traffic Parameter ADSPEC object, see Section 3.1 of [RFC3473].
+
+
+
+Berger, et al.                Experimental                     [Page 12]
+
+RFC 5467         Asymmetric Bandwidth Bidirectional LSP       March 2009
+
+
+   Consistent with [RFC3473], a node that is unable to allocate a label
+   or internal resources based on the contents of the ADSPEC object,
+   would issue a PathErr message with a "Routing problem/MPLS label
+   allocation failure" indication.
+
+   The second modification would be that the ADSPEC object would not be
+   modified by transit nodes.
+
+A.4.  Compatibility
+
+   The approach presented in this section reuses semantics and
+   procedures defined in [RFC3473].  To indicate the use of asymmetric
+   bandwidth, a new ADSPEC object C-type would be defined.  Per
+   [RFC2205], nodes not supporting the approach should not recognize
+   this new C-type and respond with an "Unknown object C-Type" error.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Berger, et al.                Experimental                     [Page 13]
+
+RFC 5467         Asymmetric Bandwidth Bidirectional LSP       March 2009
+
+
+Authors' Addresses
+
+   Lou Berger
+   LabN Consulting, L.L.C.
+
+   EMail: lberger@labn.net
+
+
+   Attila Takacs
+   Ericsson
+   1. Laborc u.
+   1037 Budapest, Hungary
+
+   Phone: +36-1-4377044
+   EMail: attila.takacs@ericsson.com
+
+
+   Diego Caviglia
+   Ericsson
+   Via A. Negrone 1/A
+   Genova-Sestri Ponente, Italy
+
+   Phone: +390106003738
+   EMail: diego.caviglia@ericsson.com
+
+
+   Don Fedyk
+   Nortel Networks
+   600 Technology Park Drive
+   Billerica, MA, USA 01821
+
+   Phone: +1-978-288-3041
+   EMail: dwfedyk@nortel.com
+
+
+   Julien Meuric
+   France Telecom
+   Research & Development
+   2, avenue Pierre Marzin
+   22307 Lannion Cedex - France
+
+   Phone: +33 2 96 05 28 28
+   EMail: julien.meuric@orange-ftgroup.com
+
+
+
+
+
+
+
+
+Berger, et al.                Experimental                     [Page 14]
+
-- 
cgit v1.2.3