CCAMP Working Group D. Papadimitriou (Alcatel) - Editor Category: Internet Draft Expiration Date: August 2002 Alberto Bellato (Alcatel) Sudheer Dharanikota (Nayna) Michele Fontana (Alcatel) James Fu (Sorrento) Germano Gasparini (Alcatel) Nasir Ghani (Sorrento) Gert Grammel (Alcatel) Dan Guo (Turin) Juergen Heiles (Siemens) Jim Jones (Alcatel) Zhi-Wei Lin (Lucent) Eric Mannie (Ebone) S. Sankaranarayanan (Lucent) Maarten Vissers (Lucent) Yangguang Xu (Lucent) Yong Xue (WorldCom) February 2002 GMPLS Signalling Extensions for G.709 Optical Transport Networks Control draft-fontana-ccamp-gmpls-g709-03.txt (*) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. (*) Current edition reproduces same set of co-authors as the previous version (this list might change based on the new publication rules: http://www.rfc-editor.org/policy.html) See also acknowledgements section. D.Papadimitriou et al. - Internet Draft û Expires August 2002 1 draft-fontana-ccamp-gmpls-g709-03.txt February 2002 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 RFC-2119 [2]. Abstract This document is a companion to the Generalized MPLS (GMPLS) signalling documents [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It describes the G.709 [ITUT-G709] technology specific information needed to extend GMPLS signalling to control Optical Transport Networks (OTN); it also includes the so-called pre-OTN developments. DISCLAIMER In this document, the presented views on ITU-T G.709 OTN Recommendation (and referenced) are intentionally restricted as needed from 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, the reader interested in going into more details concerning the corresponding technologies is strongly invited to consult the corresponding ITU- T documents (also referenced in this memo). 1. Introduction Generalized MPLS extends MPLS from supporting Packet Switching Capable (PSC) interfaces and switching to include support of three new classes of interfaces and switching: Time-Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch (FSC) Capable. A functional description of the extensions to MPLS signaling needed to support these new classes of interfaces and switching is provided in [GMPLS-SIG]. [GMPLS-RSVP] describes RSVP-TE specific formats and mechanisms needed to support all four classes of interfaces, and CR-LDP extensions can be found in [GMPLS-LDP]. 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 [GMPLS-SIG], G.709 specific parameters are carried through the signaling protocol in traffic parameter specific objects. Note: 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 G.709 compliant. Details concerning pre-OTN SONET/SDH based solutions including Optical Sections (OS), Regenerator Section(RS)/Section and Multiplex D.Papadimitriou et al. - Internet Draft û Expires August 2002 2 draft-fontana-ccamp-gmpls-g709-03.txt February 2002 Section(MS)/ Line overhead transparency are covered in [GMLS-SSS] and [GMPLS-SSS-EXT]. 2. GMPLS Extensions for G.709 Although G.709 defines several networking layers (OTS, OMS, OPS, OCh, OChr constituting the optical transport hierarchy and OTUk, ODUk constituting the digital transport hierarchy) only the OCh (Optical Channel) and the ODUk (Optical Channel Data Unit) 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 (so also referred to as the non-associated overhead û naOH) in the 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 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), [ITUT-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 Therefore, adapting GMPLS to control G.709 OTN, can be achieved by considering that: - a Digital Path layer by extending the previously defined ôDigital Wrapperö in [GMPLS-SIG] corresponding to the ODUk (digital) path layer. - an Optical Path layer by extending the ôLambdaö concept defined in [GMPLS-SIG] 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 to identify the exact position of a particular ODUj signal in an ODUk multiplexing structure. Thus, GMPLS extensions for G.709 need to cover the Generalized Label Request, the Generalized Label as well as the specific technology dependent fields equivalent to the one currently specified for SDH/SONET in [GMPLS-SSS]. Since the multiplexing in the digital domain (such as ODUk multiplexing) has been considered in the updated version of the G.709 recommendation (October 2001), we also propose a label space definition suitable for that purpose. Notice also that we directly use the G.709 ODUk (i.e. Digital Path) and OCh layers in order to define the corresponding label spaces. 3. Generalized Label Request D.Papadimitriou et al. - Internet Draft û Expires August 2002 3 draft-fontana-ccamp-gmpls-g709-03.txt February 2002 The Generalized Label Request as defined in [GMPLS-SIG], includes a technology independent part and a technology dependent part (i.e. the traffic parameters). In this section, we suggest to adapt both parts in order to accommodate the GMPLS Signalling to the G.709 recommendation [ITUT-G709]. 3.1 Technology Independent Part As defined in [GMPLS-SIG], the LSP Encoding Type and the Generalized Protocol Identifier (Generalized-PID) constitute the technology independent part of the Generalized Label Request. The information carried in the technology independent part of the Generalized Label Request is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSP Enc. Type |Switching Type | G-PID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ As mentioned here above, we suggest here to adapt the LSP Encoding Type and the G-PID (Generalized-PID) to accommodate G.709 recommendation [ITUT-G709]. 3.1.1 LSP Encoding Type Since G.709 defines two networking layers (ODUk layers and OCh layer), the LSP Encoding Type code-points can reflect these two layers currently defined in [GMPLS-SIG] as ôDigital Wrapperö and ôLambdaö code. The LSP Encoding Type is specified per networking layer or more precisely per group of functional networking layer: the ODUk layers and the OCh layer. Therefore, the current ôDigital Wrapperö code-point defined in [GMPLS-SIG] can be replaced by two separated code-points: - code-point for the G.709 Digital Path layer - code-point for the non-standard Digital Wrapper layer In the same way, two separated code-points can replace the current defined ôLambdaö code-point: - code-point for the G.709 Optical Channel layer - code-point for the non-standard Lambda layer (also referred to as Lambda layer which includes the pre-OTN Optical Channel layer) Consequently, we have the following additional code-points for the LSP Encoding Type: Value Type D.Papadimitriou et al. - Internet Draft û Expires August 2002 4 draft-fontana-ccamp-gmpls-g709-03.txt February 2002 ----- ---- 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 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. 3.1.2 Switching Type The Switching Type indicates the type of switching that should be performed at the termination of a particular link. This field is only needed for links that advertise more than one type of switching capability (see [GMPLS-RTG]). Here, no additional values are to be considered in order to accommodate G.709 switching types since an ODUk switching (and so LSPs) belongs to the TDM class while an OCh switching (and so LSPs) to the Lambda class (i.e. LSC). Moreover, in a strict layered G.709 network architecture, when a downstream node receives a Generalized Label Request with one of these values as Switching Type, this value is ignored. 3.1.3 Generalized-PID (G-PID) The G-PID (16 bits field) as defined in [GMPLS-SIG], 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 already defined in [GMPLS-SIG]: - 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 Path at 2.5, 10 and 40 Gbps 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 already defined in [GMPLS-SIG]: - 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 D.Papadimitriou et al. - Internet Draft û Expires August 2002 5 draft-fontana-ccamp-gmpls-g709-03.txt February 2002 When the client payloads such as Ethernet/MAC and IP/PPP are encapsulated through the Generic Framing Procedure (GFP) as described in ITU-T G.7041, we use dedicated G-PID values. Notice that additional G-PID values such as ESCON, FICON and Fiber Channel could complete this list in future releases. In order to include pre-OTN developments as defined above, the G-PID can take one of the values currently defined in [GMPLS-SIG], when the client payload is transported over an Optical Channel (i.e. a lambda): - Gigabit Ethernet: 1 Gbps and 10 Gbps - ESCON and FICON : left for further consideration - Fiber Channel : left for further consideration The following table summarizes the G-PID with respect to the LSP Encoding Type: Value G-PID Type LSP Encoding Type ----- ---------- ----------------- 44 G.709 ODUj G.709 ODUk (with k > j) 45 G.709 OTUk(v) G.709 OCh (ODUk mapped into OTUk(v)) 46 CBR/CBRa G.709 ODUk, G.709 OCh 47 CBRb G.709 ODUk 48 BSOT G.709 ODUk 49 BSNT G.709 ODUk 50 IP/PPP (GFP) G.709 ODUk 51 Ethernet (GFP) G.709 ODUk Note: Value 46 and 47 includes mapping of SDH/Sonet The following table summarizes the update of the G-PID values defined in [GMPLS-SIG]: Value G-PID Type LSP Encoding Type ----- ---------- ----------------- 32 ATM Mapping SONET, SDH, G.709 ODUk 33 Ethernet (GbE) G.709 OCh, Lambda, Fiber 34 SDH G.709 OCh, Lambda, Fiber 35 SONET G.709 OCh, Lambda, Fiber 3.2 G.709 Traffic-Parameters When G.709 Digital Path Layer or G.709 Optical Channel Layer is specified in the LSP Encoding Type field, the information referred to as technology dependent information or simply traffic-parameters is carried additionally to the one included in the Generalized Label Request and is defined as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Signal Type | Reserved | NMC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ D.Papadimitriou et al. - Internet Draft û Expires August 2002 6 draft-ietf-ccamp-gmpls-g709-00.txt February 2002 | NVC | Multiplier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ In this frame, NMC stands for Number of Multiplexed Components and NVC for Number of Virtual Components. Each of these fields is tailored in order to support G.709 LSP. 3.2.1 Signal Type This field (8 bits) indicates the requested G.709 elementary Signal Type. The possible values are: Value Type ----- ---- 0 irrelevant 1 ODU1 (i.e. 2.5 Gbps) 2 ODU2 (i.e. 10 Gbps) 3 ODU3 (i.e. 40 Gbps) 4 Reserved for future use 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 [GMPLS-SIG]: - 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) 3.2.3 Number of Multiplexed Components (NMC) The NMC field (16 bits) indicates the number of ODU tributary slots used by an ODUj when multiplexed into an ODUk (k > j) for the requested LSP. This field is not applicable when an ODUk is mapped into an OTUk and irrelevant at the Optical Channel layer. In both cases, it MUST be set to zero (NMC = 0) when sent and should be ignored when received. When applied at the Digital Path layer, in particular for ODU2 connections multiplexed into one ODU3 payload, the NMC field specifies the number of individual tributary slots (NMC = 4) constituting the requested connection. These components are still processed within the context of a single connection entity. For all D.Papadimitriou et al. - Internet Draft û Expires August 2002 7 draft-fontana-ccamp-gmpls-g709-03.txt February 2002 other currently defined multiplexing cases (see Section 2), the NMC field is set to 1. 3.2.4 Number of Virtual Components (NVC) The NVC field (16 bits) is dedicated to ODUk virtual concatenation (i.e. ODUk Inverse Multiplexing) purposes. It indicates the number of ODU1, ODU2 or ODU3 elementary signals that are requested to be virtually concatenated to form an ODUk-Xv signal. By definition, these signals MUST be of the same type. This field is set to 0 (default value) to indicate that no virtual concatenation is requested. Note: the current usage of this field only applies for G.709 ODUk LSP. Therefore, it must be set to zero when requesting G.709 OCh LSP. 3.2.5 Multiplier (MT) The multiplier field (16 bits) indicates the number of identical composed signals requested for the LSP. A composed signal is the resulting signal from the application of the NMC and NVC fields to an elementary Signal Type. GMPLS signalling implies today that all the composed signals must be part of the same LSP. The multiplier field is set to one (default value) to indicate that exactly one base signal is being requested. Zero is an invalid value. When the multiplier field is greater than one, the resulting signal is referred to as a multiplied signal. 3.2.6 Reserved Fields The reserved fields (8 bits and 32 bits) are dedicated for future use. Reserved bits should be set to zero when sent and must be ignored when received. 4. Generalized Label This section describes the Generalized Label space for the Digital Path and the Optical Channel Layer. The label distribution rules follows the ones defined in [GMPLS-SSS] and are detailed in Section 4.2. 4.1 ODUk Label Space At the Digital Path layer (i.e. ODUk layers), G.709 defines three different client payload bit rates. An Optical Data Unit (ODU) frame has been defined for each of these bit rates. ODUk refers to the frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps) or 3 (for 40 Gbps). D.Papadimitriou et al. - Internet Draft û Expires August 2002 8 draft-fontana-ccamp-gmpls-g709-03.txt February 2002 In addition to the support of ODUk mapping into OTUk, the G.709 label space supports the sub-levels of ODUk multiplexing. ODUk multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk (k > j), in particular: - ODU1 into ODU2 multiplexing - ODU1 into ODU3 multiplexing - ODU2 into ODU3 multiplexing - ODU1 and ODU2 into ODU3 multiplexing More precisely, ODUj into ODUk multiplexing (k > j) is defined when an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an ODTUG constituted by ODU tributary slots) which is mapped into an OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is mapped into an OTUk. Therefore, the label space structure is a tree whose root is an OTUk signal and leaves the ODUj signals (k >= j) that can be transported via the tributary slots and switched between these slots. A G.709 Digital Path layer label identifies the exact position of a particular ODUj signal in an ODUk multiplexing structure. The G.709 Digital Path Layer label or ODUk label has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | t3 | t2 |t1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The specification of the three fields t1, t2 and t3 self- consistently characterizes the ODUk label space. The value space of 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 (t1=0). 2. t2 (3-bit): - t2=1 indicates a not further sub-divided ODU2 signal. - 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 (t2=0). 3. t3 (6-bit): - t3=1 indicates a not further sub-divided ODU3 signal. - 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). D.Papadimitriou et al. - Internet Draft û Expires August 2002 9 draft-fontana-ccamp-gmpls-g709-03.txt February 2002 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). We refer to this 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 4.2 Label Distribution Rules In case of ODUk in OTUk mapping, only one of label can appear in the Label field of a Generalized Label. 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). 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. 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. D.Papadimitriou et al. - Internet Draft û Expires August 2002 10 draft-fontana-ccamp-gmpls-g709-03.txt February 2002 Note: As defined in [GMPLS-SIG], label field values only have significance between two neighbors, and the receiver may need (in some particular cases) to convert the received value into a value that has local significance. 4.3 Optical Channel Label Space At the Optical Channel layer, the label space must be consistently defined as a flat space whose values reflect the local assignment of OCh identifiers corresponding to the OTM-n.m sub-interface signals (m = 1, 2 or 3). Notice that these identifiers do not cover OChr since the corresponding Connection Function (OChr-CF) between OTM- nr.m/OTM-0r.m is not yet defined in [ITUT-G798]. The OCh identifiers could be defined as specified in [GMPLS-SIG] either with absolute values (channel identifiers (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 while the former could be defined as a local or a global label space. Such an OCh label space is applicable to both OTN Optical Channel layer and pre-OTN Optical Channel layer. For this layer, label distribution rules are defined in [GMPSL-SIG]. 5. Examples The following examples are given in order to illustrate the processing described in the previous sections of this document. 1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is directly transported in an OTU1 (OTU2 or OTU3), the upstream node requests results simply in an ODU1 (ODU2 or ODU3) signal request. In such conditions, the downstream node has to return a unique label since the ODU1 (ODU2 or ODU3) is directly mapped into the corresponding OTU1 (OTU2 or OTU3). Since a single ODUk signal is requested (Signal Type = 1, 2 or 3), the downstream node has to return a single ODUk label which can be for instance one of the following when the Signal Type = 1: - t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1 - t3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2 - t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3 2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed into the payload of a structured ODU2 (or ODU3), the upstream node requests results simply in a ODU1 signal request. In such conditions, the downstream node has to return a unique label since 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). Since a single ODU1 multiplexed signal is requested (Signal Type D.Papadimitriou et al. - Internet Draft û Expires August 2002 11 draft-fontana-ccamp-gmpls-g709-03.txt February 2002 = 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 a 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 [GMPLS-SIG]. 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 a ODU3, it returns an ordered list of four labels to the upstream node: the first ODU1 label corresponding to the first signal of the LSP, the second ODU1 label corresponding 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) 6. Signalling Protocol Extensions This section specifies the [GMPLS-RSVP] and [GMPLS-LDP] protocol extensions needed to accommodate G.709 traffic parameters. 6.1 RSVP-TE Details For RSVP-TE, the G.709 traffic parameters are carried in the G.709 SENDER_TSPEC and FLOWSPEC objects. The same format is used both D.Papadimitriou et al. - Internet Draft û Expires August 2002 12 draft-fontana-ccamp-gmpls-g709-03.txt February 2002 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 = 4 (TBA) - G.709 FLOWSPEC Object: Class = 9, C-Type = 4 (TBA) There is no Adspec associated with the SONET/SDH 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. 6.2 CR-LDP Details For CR-LDP, the G.709 traffic parameters are carried in the G.709 Traffic Parameters TLV. The content of the TLV is defined in Section 3.2. The header of the TLV has the following format: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |U|F| Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The type field indicates G.709 OTN: 0xTBA 7. Security Considerations This document introduces no new security considerations to either [GMPLS-RSVP] or [GMPLS-LDP]. 8. References [ITUT-G707] ITU-T G.707 Recommendation, æNetwork node interface for the synchronous digital hierarchy (SDH)Æ, ITU-T, April 2000. [ITUT-G709] ITU-T G.709 version 1.0 (+ addendum), æInterface for the Optical Transport Network (OTN)Æ, ITU-T, October 2001. [ITUT-G798] ITU-T G.798 version 1.0, æCharacteristics of Optical Transport Network Hierarchy Equipment Functional BlocksÆ, ITU-T, October 2001. D.Papadimitriou et al. - Internet Draft û Expires August 2002 13 draft-fontana-ccamp-gmpls-g709-03.txt February 2002 [ITUT-G872] ITU-T G.872 Recommendation version 1.0, revision 6, æArchitecture of Optical Transport NetworkÆ, ITU-T, August 2001. [ITUT-GASTN] ITU-T G.807 Recommendation version 1.0, æAutomated Switched Transport NetworkÆ, ITU-T, February 2001. [GMPLS-ARCH] E.Mannie (Editor) et al., æGeneralized Multi-Protocol Label Switching (GMPLS) ArchitectureÆ, Internet Draft, Work in progress, draft-ietf-ccamp-gmpls-architecture- 01.txt, November 2001. [GMPLS-LDP] L.Berger (Editor) et al., æGeneralized MPLS Signaling - CR-LDP ExtensionsÆ, Internet Draft, Work in progress, draft-ietf-mpls-generalized-cr-ldp-05.txt, November 2001. [GMPLS-RSVP] L.Berger (Editor) et al., æGeneralized MPLS Signaling - RSVP-TE ExtensionsÆ, Internet Draft, Work in progress, draft-ietf-mpls-generalized-rsvp-te-06.txt, November 2001. [GMPLS-RTG] K. Kompella et al., ôRouting Extensions in Support of Generalized MPLS,ö Internet Draft, Work in Progress, draft-kompella-ccamp-gmpls-routing-02.txt, February 2002. [GMPLS-SIG] L.Berger (Editor) et al., æGeneralized MPLS - Signaling Functional DescriptionÆ, Internet Draft, Work in progress, draft-ietf-mpls-generalized- signaling-07.txt, October 2001. [GMPLS-SSS] E.Mannie (Editor) et al., æGeneralized MPLS û SDH/Sonet SpecificsÆ, Internet Draft, Work in progress, draft- ietf-ccamp-gmpls-sonet-sdh-02.txt, October 2001. [GMPLS-SSS-EXT] E.Mannie (Editor) et al., æGeneralized MPLS û SDH/Sonet Specifics ExtensionsÆ, Internet Draft, Work in progress, draft-ietf-ccamp- gmpls-sonet-sdh-extensions-00.txt, July 2001. [G709-FRM] A. Bellato, D.Papadimitriou et al., æG.709 Optical Transport Networks GMPLS Control FrameworkÆ, Internet Draft, Work in progress, draft-bellato-ccamp-g709- framework-01.txt, November 2001. [RFC-2210] J. Wroclawski, æThe Use of RSVP with IETF Integrated ServicesÆ, Internet RFC 2210, IETF Standard Track, September 1997. 9. Acknowledgments D.Papadimitriou et al. - Internet Draft û Expires August 2002 14 draft-fontana-ccamp-gmpls-g709-03.txt February 2002 The authors would like to be thank Bernard Sales, Emmanuel Desmet, Jean-Loup Ferrant, Mathieu Garnot, Massimo Canali and Fong Liaw for their constructive comments and inputs. This draft incorporates (upon agreement) material and ideas from draft-lin-ccamp-ipo-common-label-request-00.txt resulting in the inclusion of its authors into the present document. 10. Author's Addresses Alberto Bellato Alcatel Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-7215 Email: alberto.bellato@netit.alcatel.it Michele Fontana Alcatel Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-7053 Email: michele.fontana@netit.alcatel.it Germano Gasparini Alcatel Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-7670 Email: germano.gasparini@netit.alcatel.it Nasir Ghani Sorrento Networks 9990 Mesa Rim Road, San Diego, CA 92121, USA Phone: +1 858 646-7192 Email: nghani@sorrentonet.com Gert Grammel Alcatel Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-4453 Email: gert.grammel@netit.alcatel.it Dan Guo Turin Networks 1415 N. McDowell Blvd Petaluma, CA 94954, USA Phone: +1 707 665-4357 Email: dguo@turinnetworks.com Juergen Heiles D.Papadimitriou et al. - Internet Draft û Expires August 2002 15 draft-fontana-ccamp-gmpls-g709-03.txt February 2002 Siemens AG Hofmannstr. 51 D-81379 Munich, Germany Phone: +49 89 7 22 - 4 86 64 Email: Juergen.Heiles@icn.siemens.de Jim Jones Alcatel 3400 W. Plano Parkway, Plano, TX 75075, USA Phone: +1 972 519-2744 Email: Jim.D.Jones1@usa.alcatel.com Zhi-Wei Lin Lucent 101 Crawfords Corner Rd, Rm 3C-512 Holmdel, New Jersey 07733-3030, USA Tel: +1 732 949-5141 Email: zwlin@lucent.com Eric Mannie EBone (GTS) Terhulpsesteenweg, 6A 1560 Hoeilaart, Belgium Phone: +32 2 658-5652 Email: eric.mannie@ebone.com Dimitri Papadimitriou (Editor) Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: Dimitri.Papadimitriou@alcatel.be Siva Sankaranarayanan Lucent 101 Crawfords Corner Rd Holmdel, NJ 07733-3030, USA Email: siva@hotair.hobl.lucent.com Maarten Vissers Lucent Boterstraat 45 Postbus 18 1270 AA Huizen, Netherlands Email: mvissers@lucent.com Yangguang Xu Lucent 21-2A41, 1600 Osgood Street North Andover, MA 01845, USA Email: xuyg@lucent.com D.Papadimitriou et al. - Internet Draft û Expires August 2002 16 draft-fontana-ccamp-gmpls-g709-03.txt February 2002 Yong Xue WorldCom 22001 Loudoun County Parkway Ashburn, VA 20147, USA Tel: +1 703 886-5358 Email: yong.xue@wcom.com D.Papadimitriou et al. - Internet Draft û Expires August 2002 17 draft-ietf-ccamp-gmpls-g709-00.txt February 2002 Appendix 1 û Abbreviations BSNT Bit Stream without Octet Timing BSOT Bit Stream with Octet Timing CBR Constant Bit Rate ESCON Enterprise Systems Connection FC Fiber Channel FEC Forward Error Correction FICON Fiber Connector FSC Fiber Switch Capable GFP Generic Framing Procedure LSC Lambda Switch Capable LSP Label Switched Path MS Multiplex Section naOH non-associated Overhead NMC Number of Multiplexed Components NNI Network-to-Network interface NVC Number of Virtual Components OCC Optical Channel Carrier OCG Optical Carrier Group OCh Optical Channel (with full functionality) OChr Optical Channel (with reduced functionality) ODTUG Optical Date Tributary Unit Group ODU Optical Channel Data Unit OH Overhead OMS Optical Multiplex Section OMU Optical Multiplex Unit OOS OTM Overhead Signal OPS Optical Physical Section OPU Optical Channel Payload Unit OSC Optical Supervisory Channel OTH Optical transport hierarchy OTM Optical transport module OTN Optical transport network OTS Optical transmission section OTU Optical Channel Transport Unit OTUkV Functionally Standardized OTUk PPP Point to Point Protocol PSC Packet Switch Capable RES Reserved RS Regenerator Section TDM Time Division Multiplex UNI User-to-Network Interface Appendix 2 û G.709 Indexes - Index k: The index "k" is used to represent a supported bit rate and the different versions of OPUk, ODUk and OTUk. k=1 represents an approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate bit rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s and k = 4 an approximate bit rate of 160 Gbit/s (under definition). The exact bit-rate values are in kbits/s: . OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322 D.Papadimitriou et al. - Internet Draft û Expires August 2002 18 draft-ietf-ccamp-gmpls-g709-00.txt February 2002 . ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983 . OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559 - Index m: The index "m" is used to represent the bit rate or set of bit rates supported on the interface. This is a one or more digit ôkö, where each ôkö represents a particular bit rate. The valid values for m are (1, 2, 3, 12, 23, 123). - Index n: The index "n" is used to represent the order of the OTM, OTS, OMS, OPS, OCG and OMU. This index represents the maximum number of wavelengths that can be supported at the lowest bit rate supported on the wavelength. It is possible that a reduced number of higher bit rate wavelengths are supported. The case n=0 represents a single channel without a specific wavelength assigned to the channel. - Index r: The index "r", if present, is used to indicate a reduced functionality OTM, OCG, OCC and OCh (non-associated overhead is not supported). Note that for n=0 the index r is not required as it implies always reduced functionality. D.Papadimitriou et al. - Internet Draft û Expires August 2002 19 draft-ietf-ccamp-gmpls-g709-00.txt February 2002 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." D.Papadimitriou et al. - Internet Draft û Expires August 2002 20