Network Working Group D. Papadimitriou, Ed. Request for Comments: 4328 Alcatel Updates: 3471 January 2006 Category: Standards Track Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2006).
AbstractThis document is a companion to the Generalized Multi-Protocol Label Switching (GMPLS) signaling documents. It describes the technology- specific information needed to extend GMPLS signaling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. 1. Introduction ....................................................2 1.1. Conventions Used in This Document ..........................3 2. GMPLS Extensions for G.709 - Overview ...........................3 3. Generalized Label Request .......................................4 3.1. Common Part ................................................5 3.1.1. LSP Encoding Type ...................................5 3.1.2. Switching Type ......................................6 3.1.3. Generalized-PID (G-PID) .............................6 3.2. G.709 Traffic Parameters ...................................8 3.2.1. Signal Type (ST) ....................................8 3.2.2. Number of Multiplexed Components (NMC) ..............9 3.2.3. Number of Virtual Components (NVC) .................10 3.2.4. Multiplier (MT) ....................................10 3.2.5. Reserved Fields ....................................10 4. Generalized Label ..............................................10 4.1. ODUk Label Space ..........................................11 4.2. Label Distribution Rules ..................................13
4.3. Optical Channel Label Space ...............................14 5. Examples .......................................................14 6. RSVP-TE Signaling Protocol Extensions ..........................16 7. Security Considerations ........................................16 8. IANA Considerations ............................................16 9. Acknowledgements ...............................................18 10. References ....................................................18 10.1. Normative References .....................................18 10.2. Informative References ...................................19 11. Contributors ..................................................19 Appendix A. Abbreviations .........................................21 Appendix B. G.709 Indexes .........................................22 RFC3945] extends MPLS from supporting Packet Switching Capable (PSC) interfaces and switching to include support of four new classes of interfaces and switching: Layer-2 Switching (L2SC), Time-Division Multiplex (TDM), Lambda Switch (LSC), and Fiber-Switch (FSC) Capable. A functional description of the extensions to MPLS signaling that are needed to support these new classes of interfaces and switching is provided in [RFC3471]. [RFC3473] describes the RSVP-TE-specific formats and mechanisms needed to support all four classes of interfaces. This document presents the technology details that are specific to G.709 Optical Transport Networks (OTN) as specified in the ITU-T G.709 recommendation [ITUT-G709] (and referenced documents), including pre-OTN developments. Per [RFC3471], G.709 technology- specific parameters are carried through the signaling protocol in dedicated traffic parameter objects. The G.709 traffic parameters defined hereafter (see Section 3.2) MUST be used when the label is encoded as defined in this document. Moreover, the label MUST be encoded as defined in Section 4 when these G.709 traffic parameters are used. In the context of this memo, by pre-OTN developments, one refers to Optical Channel, Digital Wrapper and Forward Error Correction (FEC) solutions that are not fully G.709 compliant. Details concerning pre-OTN Synchronous Optical Network (SONET)/Synchronous Digital Hierarchy (SDH) based solutions including Section/Regenerator Section overhead (SOH/RSOH) and Line/Multiplex Section overhead (LOH/MSOH) transparency are covered in [RFC3946].
*** Note on ITU-T G.709 Recommendation *** The views on the ITU-T G.709 OTN Recommendation presented in this document are intentionally restricted to the GMPLS perspective within the IETF CCAMP WG context. Hence, the objective of this document is not to replicate the content of the ITU-T OTN recommendations. Therefore, readers interested in more details concerning the corresponding technologies are strongly invited to consult the corresponding ITU-T documents (also referenced in this memo). RFC2119]. In addition, the reader is assumed to be familiar with the terminology used in ITU-T [ITUT-G709], as well as [RFC3471] and [RFC3473]. Abbreviations used in this document are detailed in Appendix 1. ITUT-G709] defines several networking layers constituting the optical transport hierarchy: - with full functionality: . Optical Transmission Section (OTS) . Optical Multiplex Section (OMS) . Optical Channel (OCh) - with reduced functionality: . Optical Physical Section (OPS) . Optical Channel with reduced functionality (OChr) It also defines two layers constituting the digital transport hierarchy: - Optical Channel Transport Unit (OTUk) - Optical Channel Data Unit (ODUk) However, only the OCh and the ODUk layers are defined as switching layers. Both OCh (but not OChr) and ODUk layers include the overhead for supervision and management. The OCh overhead is transported in a non-associated manner (also referred to as the non-associated overhead naOH) in the Optical Transport Module (OTM) Overhead Signal (OOS), together with the OTS and OMS non-associated overhead. The OOS is transported via a dedicated wavelength, referred to as the Optical Supervisory Channel (OSC). It should be noticed that the
naOH is only functionally specified and as such, it is open to vendor-specific solutions. The ODUk overhead is transported in an associated manner as part of the digital ODUk frame. As described in [ITUT-G709], in addition to the support of ODUk mapping into OTUk (k = 1, 2, 3), G.709 supports ODUk multiplexing. It refers to the multiplexing of ODUj (j = 1, 2) into an ODUk (k > j) signal, in particular: - ODU1 into ODU2 multiplexing - ODU1 into ODU3 multiplexing - ODU2 into ODU3 multiplexing - ODU1 and ODU2 into ODU3 multiplexing Adapting GMPLS to control G.709 OTN can be achieved by creating: - a Digital Path layer, by extending the previously defined "Digital Wrapper" in [RFC3471] corresponding to the ODUk (digital) path layer. - an Optical Path layer, by extending the "Lambda" concept (defined in [RFC3471]) to the OCh (optical) path layer. - a label space structure, by considering a tree whose root is an OTUk signal and leaves the ODUj signals (k >= j); enabling the identification of the exact position of a particular ODUj signal in an ODUk multiplexing structure. Thus, the GMPLS signaling extensions for G.709 need to cover the Generalized Label Request, the Generalized Label as well as the specific technology dependent objects included in the so-called traffic parameters as specified in [RFC3946] for SONET/SDH networks. Moreover, because multiplexing in the digital domain (such as ODUk multiplexing) has been specified in the amended version of the G.709 ITU-T recommendation (October 2001), this document also proposes a label space definition suitable for that purpose. Notice also that one uses the G.709 ODUk (i.e., Digital Path) and OCh (i.e., Optical Path) layers directly in order to define the corresponding label spaces. RFC3471], includes a common part (i.e., used for any switching technology) and a technology dependent part (i.e., the traffic parameters). In this section, both parts are extended to accommodate GMPLS Signaling to the G.709 transport plane recommendation (see [ITUT-G709]).
RFC3471], the LSP Encoding Type, the Switching Type and the Generalized Protocol Identifier (Generalized-PID) constitute the common part of the Generalized Label Request. The encoding of the RSVP-TE GENERALIZED_LABEL_REQUEST object is specified in [RFC3473] Section 2.1. As mentioned above, this document extends the LSP Encoding Type, the Switching Type, and G-PID (Generalized-PID) values to accommodate G.709 Recommendation [ITUT-G709]. RFC3471] Section 3.1 as "Digital Wrapper" and "Lambda" code. The LSP Encoding Type is specified per networking layer or, more precisely, per group of functional networking layers: the ODUk layers and the OCh layer. Therefore, an additional LSP Encoding Type code-point for the G.709 Digital Path layer is defined; it enlarges the existing "Digital Wrapper" code-point defined in [RFC3471]. The former MUST be generated when the interface or tunnel on which the traffic will be transmitted supports G.709 compliant Digital Path layer encoding. The latter MUST only be used for non-G.709 compliant Digital Wrapper layer(s) encoding. A transit or an egress node (receiving a Path message containing a GENERALIZED_LABEL_REQUEST object) MUST generate a PathErr message, with a "Routing problem/Unsupported Encoding" indication, if the requested LSP Encoding Type cannot be supported on the corresponding incoming interface. In the same way, an additional LSP Encoding Type code-point for the G.709 Optical Channel layer is defined; it enlarges the existing "Lambda" code-point defined in [RFC3471]. The former MUST be generated when the interface or tunnel on which the traffic will be transmitted supports G.709-compliant Optical Channel layer encoding. The latter MUST only be used for non-G.709 compliant Lambda layer(s) encoding. A transit or an egress node (receiving a Path message that contains a GENERALIZED_LABEL_REQUEST object) MUST generate a PathErr message with a "Routing problem/Unsupported Encoding" indication, if the requested LSP Encoding Type cannot be supported on the corresponding incoming interface.
Consequently, the following additional code-points for the LSP Encoding Type are defined: Value Type ----- ---- 12 G.709 ODUk (Digital Path) 13 G.709 Optical Channel Moreover, the code-point for the G.709 Optical Channel (OCh) layer will indicate the requested capability of an end-system to use the G.709 non-associated overhead (naOH), i.e., the OTM Overhead Signal (OOS) multiplexed into the OTM-n.m interface signal. RFC4202]). No additional Switching Type values are to be considered in order to accommodate G.709 switching types, because an ODUk switching (and thus LSPs) belongs to the TDM class, while an OCh switching (and thus LSPs) belong to the Lambda class (i.e., LSC). Intermediate and egress nodes MUST verify that the value indicated in the Switching Type field is supported on the corresponding incoming interface. If the requested value can not be supported, the node MUST generate a PathErr message with a "Routing problem/Switching Type" indication. RFC3471], identifies the payload carried by an LSP, i.e., an identifier of the client layer of that LSP. This identifier is used by the endpoints of the G.709 LSP. The G-PID can take one of the following values when the client payload is transported over the Digital Path layer, in addition to the payload identifiers defined in [RFC3471]: - CBRa: asynchronous Constant Bit Rate (i.e., mapping of STM-16/OC- 48, STM-64/OC-192 and STM-256/OC-768) - CBRb: bit synchronous Constant Bit Rate (i.e., mapping of STM- 16/OC-48, STM-64/OC-192 and STM-256/OC-768) - ATM: mapping at 2.5, 10 and 40 Gbps - BSOT: non-specific client Bit Stream with Octet Timing (i.e., Mapping of 2.5, 10 and 40 Gbps Bit Stream) - BSNT: non-specific client Bit Stream without Octet Timing (i.e., Mapping of 2.5, 10 and 40 Gbps Bit Stream)
- ODUk: transport of Digital Paths at 2.5, 10 and 40 Gbps - ESCON: Enterprise Systems Connection - FICON: Fiber Connection The G-PID can take one of the following values when the client payload is transported over the Optical Channel layer, in addition to the payload identifiers defined in [RFC3471]: - CBR: Constant Bit Rate (i.e., mapping of STM-16/OC-48, STM-64/OC- 192 and STM-256/OC-768) - OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps Also, when client payloads such as Ethernet MAC/PHY and IP/PPP are encapsulated through the Generic Framing Procedure (GFP), as described in ITU-T G.7041, dedicated G-PID values are defined. In order to include pre-OTN developments, the G-PID field can take one of the values (currently defined in [RFC3471]) when the following client payloads are transported over a so-called lambda LSP: - Ethernet PHY (1 Gbps and 10 Gbps) - Fiber Channel The following table summarizes the G-PID with respect to the LSP Encoding Type: Value G-PID Type LSP Encoding Type ----- ---------- ----------------- 47 G.709 ODUj G.709 ODUk (with k > j) 48 G.709 OTUk(v) G.709 OCh ODUk mapped into OTUk(v) 49 CBR/CBRa G.709 ODUk, G.709 OCh 50 CBRb G.709 ODUk 51 BSOT G.709 ODUk 52 BSNT G.709 ODUk 53 IP/PPP (GFP) G.709 ODUk (and SDH) 54 Ethernet MAC (framed GFP) G.709 ODUk (and SDH) 55 Ethernet PHY (transparent GFP) G.709 ODUk (and SDH) 56 ESCON G.709 ODUk, Lambda, Fiber 57 FICON G.709 ODUk, Lambda, Fiber 58 Fiber Channel G.709 ODUk, Lambda, Fiber Note: Values 49 and 50 include mapping of SDH.
The following table summarizes the update of the G-PID values defined in [RFC3471]: Value G-PID Type LSP Encoding Type ----- ---------- ----------------- 32 ATM Mapping SDH, G.709 ODUk 33 Ethernet PHY SDH, G.709 OCh, Lambda, Fiber 34 Sonet/SDH G.709 OCh, Lambda, Fiber 35 Reserved (SONET Dep.) G.709 OCh, Lambda, Fiber Section 6.
5 Reserved (for future use) 6 OCh at 2.5 Gbps 7 OCh at 10 Gbps 8 OCh at 40 Gbps 9-255 Reserved (for future use) The value of the Signal Type field depends on LSP Encoding Type value defined in Section 3.1.1 and [RFC3471]: - if the LSP Encoding Type value is the G.709 Digital Path layer, then the valid values are the ODUk signals (k = 1, 2 or 3). - if the LSP Encoding Type value is the G.709 Optical Channel layer, then the valid values are the OCh at 2.5, 10, or 40 Gbps. - if the LSP Encoding Type is "Lambda" (which includes the pre-OTN Optical Channel layer) then the valid value is irrelevant (Signal Type = 0). - if the LSP Encoding Type is "Digital Wrapper", then the valid value is irrelevant (Signal Type = 0). Several transforms can be sequentially applied on the Elementary Signal to build the Final Signal that is actually requested for the LSP. Each transform application is optional and must be ignored if zero; this does not include the Multiplier (MT), which cannot be zero and must be ignored if equal to one. Transforms must be applied strictly in the following order: - First, virtual concatenation (by using the NVC field) can be optionally applied directly on the Elementary Signal to form a Composed Signal - Second, a multiplication (by using the Multiplier field) can be optionally applied, either directly on the Elementary Signal, or on the virtually concatenated signal obtained from the first phase. The resulting signal is referred to as Final Signal.
[RFC3471]. The format of the corresponding RSVP-TE GENERALIZED_LABEL object is specified in [RFC3473] Section 2.3. The label distribution rules detailed in Section 4.2 follow (when applicable) the ones defined in [RFC3946].
The specification of the fields t1, t2, and t3 self-consistently characterizes the ODUk label space. The value space for the t1, t2, and t3 fields is defined as follows: 1. t1 (1-bit): - t1=1 indicates an ODU1 signal. - t1 is not significant for the other ODUk signal types (i.e., t1 value MUST be set to 0 and ignored). 2. t2 (3-bit): - t2=1 indicates an ODU2 signal that is not further sub- divided. - t2=[2..5] indicates the tributary slot (t2th-2) used by the ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2). - t2 is not significant for an ODU3 (i.e., t2 value MUST be set to 0 and ignored). 3. t3 (6-bit): - t3=1 indicates an ODU3 signal that is not further sub- divided. - t3=[2..17] indicates the tributary slot (t3th-1) used by the ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3). - t3=[18..33] indicates the tributary slot (t3th-17) used by the ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3). Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required to identify the 4 tributary slots used by the ODU2; these tributary time slots have to be allocated in ascending order. If the label sub-field value t[i]=1 (i, j = 1, 2 or 3) and t[j]=0 (j > i), the corresponding ODUk signal ODU[i] is directly mapped into the corresponding OTUk signal (k=i). This is referred to as the mapping of an ODUk signal into an OTUk of the same order. Therefore, the numbering starts at 1; zero is used to indicate a non-significant field. A label field equal to zero is an invalid value. Examples: - t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1 - t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2 - t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3 - t3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2 - t3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3
Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered list of the labels in the multiplex is given (this list can be restricted to only one label when NMC = 1). Each label indicates a component (ODUj tributary slot) of the multiplexed signal. The order of the labels must reflect the order of the ODUj into the multiplex (not the physical order of tributary slots). This ordered list of labels is encoded as a sequence of 32-bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). In case of ODUk virtual concatenation, the explicit ordered list of all labels in the concatenation is given. Each label indicates a component of the virtually concatenated signal. The order of the labels must reflect the order of the ODUk to concatenate (not the physical order of time-slots). This representation limits virtual concatenation to remain within a single (component) link. In case of multiplexed virtually concatenated signals, the first set of labels indicates the components (ODUj tributary slots) of the first virtually concatenated signal, the second set of labels indicates the components (ODUj tributary slots) of the second virtually concatenated signal, and so on. This ordered list of labels is encoded as a sequence of 32-bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). In case of ODUk virtual concatenation, the number of label values is determined by the NVC value. Multiplexed ODUk virtual concatenation additionally uses the NMC value to determine the number of labels per set (equal in size). In case of multiplication (i.e., when using the MT field), the explicit ordered list of all labels taking part in the composed signal is given. The above representation limits multiplication to remain within a single (component) link. In case of multiplication of multiplexed virtually concatenated signals, the first set of labels indicates the components of the first multiplexed virtually concatenated signal, the second set of labels indicates components of the second multiplexed virtually concatenated signal, and so on. This ordered list of labels is encoded as a sequence of 32-bit label values (as defined in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). In case of multiplication of (equal) ODUk virtual concatenated signals, the number of label values per signal is determined by the NVC value. Multiplication of multiplexed
(equal) ODUk virtual concatenation additionally uses the NMC value to determine the number of labels per set (equal in size). ITUT-G798]. The OCh label space values are defined by either absolute values (i.e., channel identifiers or Channel ID, also referred to as wavelength identifiers) or relative values (channel spacing, also referred to as inter-wavelength spacing). The latter is strictly confined to a per-port label space, whereas the former could be defined as a local or a global (per node) label space. Such an OCh label space is applicable to both OTN Optical Channel layer and pre- OTN Optical Channel layer. Optical Channel label encoding (and distribution) rules are defined in [RFC3471]. They MUST be used for the Upstream Label, the Suggested Label, and the Generalized Label.
In such conditions, the downstream node has to return a unique label because the ODU1 is multiplexed into one ODTUG2 (or ODTUG3). The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or OPU3) and then mapped into the corresponding OTU2 (or OTU3). Because a single ODU1 multiplexed signal is requested (Signal Type = 1 and NMC = 1), the downstream node has to return a single ODU1 label, which can take, for instance, one of the following values: - t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2 - t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3 - t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3 3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is multiplexed into the payload of a structured ODU3, the upstream node requests results simply in an ODU2 signal request. In such conditions, the downstream node has to return four labels since the ODU2 is multiplexed into one ODTUG3. The latter is mapped into an ODU3 (via OPU3) and then mapped into an OTU3. Since an ODU2 multiplexed signal is requested (Signal Type = 2, and NMC = 4), the downstream node has to return four ODU labels which can take for instance the following values: - t3=18, t2=0, t1=0 (first part of ODU2 in first TS of ODTUG3) - t3=22, t2=0, t1=0 (second part of ODU2 in fifth TS of ODTUG3) - t3=23, t2=0, t1=0 (third part of ODU2 in sixth TS of ODTUG3) - t3=26, t2=0, t1=0 (fourth part of ODU2 in ninth TS of ODTUG3) 4. When a single OCh signal of 40 Gbps is requested (Signal Type = 8), the downstream node must return a single wavelength label as specified in [RFC3471]. 5. When requesting multiple ODUk LSP (i.e., with a multiplier (MT) value > 1), an explicit list of labels is returned to the requestor node. When the downstream node receives a request for a 4 x ODU1 signal (Signal Type = 1, NMC = 1 and MT = 4) multiplexed into an ODU3, it returns an ordered list of four labels to the upstream node: the first ODU1 label corresponds to the first signal of the LSP, the second ODU1 label corresponds to the second signal of the LSP, etc. For instance, the corresponding labels can take the following values: - First ODU1: t3=2, t2=0, t1=0 (in first TS of ODTUG3) - Second ODU1: t3=10, t2=0, t1=0 (in ninth TS of ODTUG3) - Third ODU1: t3=7, t2=0, t1=0 (in sixth TS of ODTUG3) - Fourth ODU1: t3=6, t2=0, t1=0 (in fifth TS of ODTUG3)
RFC3473] protocol extensions needed to accommodate G.709 traffic parameters. The G.709 traffic parameters are carried in the G.709 SENDER_TSPEC and FLOWSPEC objects. The same format is used both for SENDER_TSPEC object and FLOWSPEC objects. The content of the objects is defined above in Section 3.2. The objects have the following class and type for G.709: - G.709 SENDER_TSPEC Object: Class = 12, C-Type = 5 - G.709 FLOWSPEC Object: Class = 9, C-Type = 5 There is no Adspec associated with the G.709 SENDER_TSPEC. Either the Adspec is omitted or an Int-serv Adspec with the Default General Characterization Parameters and Guaranteed Service fragment is used, see [RFC2210]. For a particular sender in a session, the contents of the FLOWSPEC object received in a Resv message SHOULD be identical to the contents of the SENDER_TSPEC object received in the corresponding Path message. If the objects do not match, a ResvErr message with a "Traffic Control Error/Bad Flowspec value" error SHOULD be generated. Intermediate and egress nodes MUST verify that the node itself, and the interfaces on which the LSP will be established, can support the requested Signal Type, NMC, and NVC values (as defined in Section 3.2). If the requested value(s) cannot be supported, the receiver node MUST generate a PathErr message with a "Traffic Control Error/Service unsupported" indication (see [RFC2205]). In addition, if the MT field is received with a zero value, the node MUST generate a PathErr message with a "Traffic Control Error/Bad Tspec value" indication (see [RFC2205]). RFC3473]. http://www.iana.org/assignments/rsvp-parameters
- A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5 - see Section 6. - A G.709 FLOWSPEC object: Class = 9, C-Type = 5 - see Section 6. IANA will also track the code-point spaces extended and/or updated by this document. For this purpose, the following new registry entries have been added in the newly requested registry entry: http://www.iana.org/assignments/gmpls-sig-parameters - LSP Encoding Type: Name: LSP Encoding Type Format: 8-bit number Values: [1..11] defined in [RFC3471] 12 defined in Section 3.1.1 13 defined in Section 3.1.1 Allocation Policy: [0..239] Assigned by IANA via IETF Standards Track RFC Action. [240..255] Assigned temporarily for Experimental Usage. These will not be registered with IANA - Switching Type: Name: Switching Type Format: 8-bit number Values: defined in [RFC3471] Allocation Policy: [0..255] Assigned by IANA via IETF Standards Track RFC Action. - Generalized PID (G-PID): Name: G-PID Format: 16-bit number Values: [0..31] defined in [RFC3471] [32..35] defined in [RFC3471] and updated by Section 3.1.3 [36..46] defined in [RFC3471] [47..58] defined in Section 3.1.3 Allocation Policy: [0..31743] Assigned by IANA via IETF Standards Track RFC Action. [31744..32767] Assigned temporarily for Experimental Usage
[32768..65535] Not assigned. Before any assignments can be made in this range, there MUST be a Standards Track RFC that specifies IANA Considerations that covers the range being assigned. Note: per [RFC3471], Section 3.1.1, standard Ethertype values are used as G-PIDs for packet and Ethernet LSPs. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, R., 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. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC3946] Mannie, E. and D. Papadimitriou, "Generalized Multi- Protocol Label Switching (GMPLS) Extensions for Synchronous Optical Network (SONET) and Synchronous Digital Hierarchy (SDH) Control", RFC 3946, October 2004.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, September 2005. [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching (GMPLS) Architecture", RFC 3945, October 2004. For information on the availability of the following documents, please see http://www.itu.int [ITUT-G709] ITU-T, "Interface for the Optical Transport Network (OTN)," G.709 Recommendation (and Amendment 1), February 2001 (October 2001). [ITUT-G798] ITU-T, "Characteristics of Optical Transport Network Hierarchy Equipment Functional Blocks," G.798 Recommendation, October 2001.
Dan Guo (Turin Networks) 1415 N. McDowell Blvd, Petaluma, CA 94954, USA EMail: firstname.lastname@example.org Juergen Heiles (Siemens) Hofmannstr. 51, D-81379 Munich, Germany EMail: email@example.com Jim Jones (Alcatel) 3400 W. Plano Parkway, Plano, TX 75075, USA EMail: firstname.lastname@example.org Zhi-Wei Lin (Lucent) 101 Crawfords Corner Rd, Rm 3C-512 Holmdel, New Jersey 07733-3030, USA EMail: email@example.com Eric Mannie (Consult) EMail: firstname.lastname@example.org Maarten Vissers (Alcatel) Lorenzstrasse, 10, 70435 Stuttgart, Germany EMail: email@example.com Yong Xue (WorldCom) 22001 Loudoun County Parkway, Ashburn, VA 20147, USA EMail: firstname.lastname@example.org
Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at email@example.com. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).