idnits 2.17.1 draft-ietf-ccamp-gmpls-g709-02.txt: -(145): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(168): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(815): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(824): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(835): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(839): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(872): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1026): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 65 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 20 longer pages, the longest (page 4) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 664 has weird spacing: '... (first part ...' == Line 666 has weird spacing: '... (third part ...' == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2002) is 7857 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 16 == Missing Reference: 'ITUT-G.709' is mentioned on line 154, but not defined == Missing Reference: 'GMPSL-SIG' is mentioned on line 612, but not defined == Missing Reference: 'RFC2210' is mentioned on line 710, but not defined == Missing Reference: 'RFC2205' is mentioned on line 728, but not defined == Missing Reference: 'RFC3212' is mentioned on line 753, but not defined == Missing Reference: 'RFC 3031' is mentioned on line 774, but not defined == Unused Reference: 'ITUT-G707' is defined on line 815, but no explicit reference was found in the text == Unused Reference: 'ITUT-G872' is defined on line 827, but no explicit reference was found in the text == Unused Reference: 'GMPLS-ARCH' is defined on line 830, but no explicit reference was found in the text == Unused Reference: 'RFC-2119' is defined on line 859, but no explicit reference was found in the text == Unused Reference: 'RFC-2205' is defined on line 864, but no explicit reference was found in the text == Unused Reference: 'RFC-2210' is defined on line 868, but no explicit reference was found in the text == Unused Reference: 'RFC-3036' is defined on line 872, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G707' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G709' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G798' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G872' == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-03 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-08 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-routing-05 == Outdated reference: A later version (-08) exists of draft-ietf-ccamp-gmpls-sonet-sdh-06 ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) Summary: 6 errors (**), 0 flaws (~~), 22 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group D. Papadimitriou - Editor 3 Category: Internet Draft Alcatel 4 Expiration Date: April 2003 5 October 2002 7 Generalized MPLS Signalling Extensions 8 for G.709 Optical Transport Networks Control 10 draft-ietf-ccamp-gmpls-g709-02.txt 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026 [1]. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. Internet-Drafts are draft documents valid for a maximum of 21 six months and may be updated, replaced, or obsoleted by other 22 documents at any time. It is inappropriate to use Internet- Drafts 23 as reference material or to cite them other than as "work in 24 progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document is a companion to the Generalized MPLS (GMPLS) 35 signalling documents. It describes the technology specific 36 information needed to extend GMPLS signalling to control Optical 37 Transport Networks (OTN); it also includes the so-called pre-OTN 38 developments. 40 *** DISCLAIMER *** 42 In this document, the presented views on ITU-T G.709 OTN 43 Recommendation (and referenced) are intentionally restricted as 44 needed from the GMPLS perspective within the IETF CCAMP WG context. 46 Hence, the objective of this document is not to replicate the 47 content of the ITU-T OTN recommendations. Therefore, the reader 48 interested in going into more details concerning the corresponding 49 technologies is strongly invited to consult the corresponding ITU- 50 T documents (also referenced in this memo). 52 D.Papadimitriou et al. - Internet Draft � Expires April 2003 1 53 Table of Content 55 Status of this Memo 1 56 Abstract 1 57 Table of Content 2 58 1. Introduction 2 59 2. GMPLS Extensions for G.709 � Overview 3 60 3. Generalized Label Request 4 61 3.1 Technology Independent Part 4 62 3.1.1. LSP Encoding Type 4 63 3.1.2. Switching-Type 5 64 3.1.3. Generalized-PID (G-PID) 5 65 3.2. G.709 Traffic-Parameters 7 66 3.2.1. Signal Type (ST) 7 67 3.2.2. Number of Multiplexed Components (NMC) 8 68 3.2.3. Number of Virtual Components (NVC) 8 69 3.2.4. Multiplier (MT) 9 70 3.2.5. Reserved Fields 9 71 4. Generalized Label 9 72 4.1. ODUk Label Space 9 73 4.2. Label Distribution Rules 11 74 4.3. OCh Label Space 11 75 5. Examples 12 76 6. Signalling Protocol Extensions 13 77 6.1. RSVP-TE Details 13 78 6.2. CR-LDP Details 14 79 7. Security Considerations 14 80 8. IANA Considerations 15 81 9. Acknowledgments 15 82 10. Intellectual Property Notice 15 83 11. References 16 84 11.1 Normative References 16 85 12. Contributors 17 86 13. Author�s Address 18 87 Appendix 1 � Abbreviations 19 88 Appendix 2 � G.709 Indexes 19 89 Full Copyright Statement 21 91 Conventions used in this document: 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 95 this document are to be interpreted as described in RFC-2119. 97 In addition, the reader is assumed to be familiar with the 98 terminology used in ITU-T [ITUT-G709] as well as [GMPLS-SIG], 99 [GMPLS-RSVP] and [GMPLS-LDP]. Abbreviations used in this document 100 are also detailed in Appendix 1. 102 1. Introduction 104 Generalized MPLS extends MPLS from supporting Packet Switching 105 Capable (PSC) interfaces and switching to include support of three 107 D.Papadimitriou et al. - Internet Draft � Expires April 2003 2 108 new classes of interfaces and switching: Time-Division Multiplex 109 (TDM), Lambda Switch (LSC) and Fiber-Switch (FSC) Capable. A 110 functional description of the extensions to MPLS signaling needed 111 to support these new classes of interfaces and switching is 112 provided in [GMPLS-SIG]. [GMPLS-RSVP] describes RSVP-TE specific 113 formats and mechanisms needed to support all four classes of 114 interfaces, and CR-LDP extensions can be found in [GMPLS-LDP]. 116 This document presents the technology details that are specific to 117 G.709 Optical Transport Networks (OTN) as specified in the ITU-T 118 G.709 recommendation [ITUT-G709] (and referenced documents), 119 including pre-OTN developments. Per [GMPLS-SIG], G.709 specific 120 parameters are carried through the signaling protocol in traffic 121 parameter specific objects. 123 The G.709 traffic parameters defined hereafter (see Section 3.2) 124 MUST be used when the label is encoded as defined in this 125 document. Moreover, the label MUST be encoded as defined in 126 Section 4 when these G.709 traffic parameters are used. 128 Note: in the context of this memo, by pre-OTN developments, one 129 refers to Optical Channel, Digital Wrapper and Forward Error 130 Correction (FEC) solutions that are not fully G.709 compliant. 131 Details concerning pre-OTN SONET/SDH based solutions including 132 Optical Sections (OS), Regenerator Section (RS)/Section and 133 Multiplex Section (MS)/ Line overhead transparency are covered in 134 [GMPLS-SONET-SDH]. 136 2. GMPLS Extensions for G.709 - Overview 138 Although G.709 defines several networking layers (OTS, OMS, OPS, 139 OCh, OChr constituting the optical transport hierarchy and OTUk, 140 ODUk constituting the digital transport hierarchy) only the OCh 141 (Optical Channel) and the ODUk (Optical Channel Data Unit) layers 142 are defined as switching layers. Both OCh (but not OChr) and ODUk 143 layers include the overhead for supervision and management. The OCh 144 overhead is transported in a non-associated manner (so also referred 145 to as the non-associated overhead � naOH) in the OTM Overhead Signal 146 (OOS), together with the OTS and OMS non-associated overhead. The 147 OOS is transported via a dedicated wavelength referred to as the 148 Optical Supervisory Channel (OSC). It should be noticed that the 149 naOH is only functionally specified and as such open to vendor 150 specific solutions. The ODUk overhead is transported in an 151 associated manner as part of the digital ODUk frame. 153 As described in [ITUT-G709], in addition to the support of ODUk 154 mapping into OTUk (k = 1, 2, 3), [ITUT-G.709] supports ODUk 155 multiplexing. It refers to the multiplexing of ODUj (j = 1, 2) into 156 an ODUk (k > j) signal, in particular: 157 - ODU1 into ODU2 multiplexing 158 - ODU1 into ODU3 multiplexing 159 - ODU2 into ODU3 multiplexing 160 - ODU1 and ODU2 into ODU3 multiplexing 162 D.Papadimitriou et al. - Internet Draft � Expires April 2003 3 163 Therefore, adapting GMPLS to control G.709 OTN, can be achieved by 164 considering that: 165 - a Digital Path layer by extending the previously defined 166 �Digital Wrapper� in [GMPLS-SIG] corresponding to the ODUk 167 (digital) path layer. 168 - an Optical Path layer by extending the �Lambda� concept defined 169 in [GMPLS-SIG] to the OCh (optical) path layer. 170 - a label space structure by considering a tree whose root is an 171 OTUk signal and leaves the ODUj signals (k >= j); enabling to 172 identify the exact position of a particular ODUj signal in an 173 ODUk multiplexing structure. 175 Thus, GMPLS extensions for G.709 need to cover the Generalized Label 176 Request, the Generalized Label as well as the specific technology 177 dependent objects included in the so-called traffic parameters as 178 specified in [GMPLS-SONET-SDH] for SONET/SDH networks. Moreover, 179 since the multiplexing in the digital domain (such as ODUk 180 multiplexing) has been considered in the amended version of the 181 G.709 recommendation (October 2001), this document also proposes a 182 label space definition suitable for that purpose. Notice also that 183 one directly uses the G.709 ODUk (i.e. Digital Path) and OCh (i.e. 184 Optical Path) layers in order to define the corresponding label 185 spaces. 187 3. Generalized Label Request 189 The Generalized Label Request as defined in [GMPLS-SIG], includes a 190 technology independent part and a technology dependent part (i.e. 191 the traffic parameters). In this section, both parts are extended to 192 accommodate the GMPLS Signalling to the G.709 transport plane 193 recommendation (see [ITUT-G709]). 195 3.1 Technology Independent Part 197 As defined in [GMPLS-SIG], the LSP Encoding Type and the Generalized 198 Protocol Identifier (Generalized-PID) constitute the technology 199 independent part of the Generalized Label Request. 201 The information carried in the technology independent part of the 202 Generalized Label Request is defined per [GMPLS-SIG] as follows: 204 0 1 2 3 205 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 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | LSP Enc. Type |Switching Type | G-PID | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 As mentioned here above, this document extends the LSP Encoding 211 Type, Switching Type and G-PID (Generalized-PID) values to 212 accommodate G.709 recommendation [ITUT-G709]. 214 3.1.1 LSP Encoding Type 216 D.Papadimitriou et al. - Internet Draft � Expires April 2003 4 217 Since G.709 defines two networking layers (ODUk layers and OCh 218 layer), the LSP Encoding Type code-points can reflect these two 219 layers currently defined in [GMPLS-SIG] as �Digital Wrapper� and 220 �Lambda� code. 222 The LSP Encoding Type is specified per networking layer or more 223 precisely per group of functional networking layer: the ODUk layers 224 and the OCh layer. 226 Therefore, the current �Digital Wrapper� code-point defined in 227 [GMPLS-SIG] can be replaced by two separated code-points: 228 - code-point for the G.709 Digital Path layer 229 - code-point for the non-standard Digital Wrapper layer 231 In the same way, two separated code-points can replace the current 232 defined �Lambda� code-point: 233 - code-point for the G.709 Optical Channel layer 234 - code-point for the non-standard Lambda layer (also referred to 235 as Lambda layer which includes the pre-OTN Optical Channel 236 layer) 238 Consequently, the following additional code-points for the LSP 239 Encoding Type are defined: 241 Value Type 242 ----- ---- 243 12 G.709 ODUk (Digital Path) 244 13 G.709 Optical Channel 246 Moreover, the code-point for the G.709 Optical Channel (OCh) layer 247 will indicate the capability of an end-system to use the G.709 non- 248 associated overhead (naOH) i.e. the OTM Overhead Signal (OOS) 249 multiplexed into the OTM-n.m interface signal. 251 3.1.2 Switching Type 253 The Switching Type indicates the type of switching that should be 254 performed at the termination of a particular link. This field is 255 only needed for links that advertise more than one type of switching 256 capability (see [GMPLS-RTG]). 258 Here, no additional values are to be considered in order to 259 accommodate G.709 switching types since an ODUk switching (and so 260 LSPs) belongs to the TDM class while an OCh switching (and so LSPs) 261 to the Lambda class (i.e. LSC). 263 Moreover, in a strict layered G.709 network, when a downstream node 264 receives a Generalized Label Request including one of these values 265 for the Switching Type field, this value SHOULD be ignored. 267 3.1.3 Generalized-PID (G-PID) 269 D.Papadimitriou et al. - Internet Draft � Expires April 2003 5 270 The G-PID (16 bits field) as defined in [GMPLS-SIG], identifies the 271 payload carried by an LSP, i.e. an identifier of the client layer of 272 that LSP. This identifier is used by the endpoints of the G.709 LSP. 274 The G-PID can take one of the following values when the client 275 payload is transported over the Digital Path layer, in addition to 276 the payload identifiers already defined in [GMPLS-SIG]: 277 - CBRa: asynchronous Constant Bit Rate i.e. mapping of STM-16/OC-48, 278 STM-64/OC-192 and STM-256/OC-768 279 - CBRb: bit synchronous Constant Bit Rate i.e. mapping of STM-16/OC- 280 48, STM-64/OC-192 and STM-256/OC-768 281 - ATM : mapping at 2.5, 10 and 40 Gbps 282 - BSOT: non-specific client Bit Stream with Octet Timing i.e. 283 Mapping of 2.5, 10 and 40 Gbps Bit Stream 284 - BSNT: non-specific client Bit Stream without Octet Timing i.e. 285 Mapping of 2.5, 10 and 40 Gbps Bit Stream 286 - ODUk: transport of Digital Path at 2.5, 10 and 40 Gbps 288 The G-PID can take one of the following values when the client 289 payload is transported over the Optical Channel layer, in addition 290 to the payload identifiers already defined in [GMPLS-SIG]: 291 - CBR: Constant Bit Rate i.e. mapping of STM-16/OC-48, STM-64/OC-192 292 and STM-256/OC-768 293 - OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps 295 Also, when client payloads such as Ethernet MAC/PHY and IP/PPP are 296 encapsulated through the Generic Framing Procedure (GFP) as 297 described in ITU-T G.7041, dedicated G-PID values are defined. 298 Notice that additional G-PID values such as ESCON, FICON and Fiber 299 Channel could complete this list in future releases. 301 In order to include pre-OTN developments as defined above, the G-PID 302 can take one of the values currently defined in [GMPLS-SIG] when the 303 following client payloads are transported over a so-called lambda: 304 - Gigabit Ethernet: 1 Gbps and 10 Gbps 305 - ESCON and FICON : left for further consideration 306 - Fiber Channel : left for further consideration 308 The following table summarizes the G-PID with respect to the LSP 309 Encoding Type: 311 Value G-PID Type LSP Encoding Type 312 ----- ---------- ----------------- 313 47 G.709 ODUj G.709 ODUk (with k > j) 314 48 G.709 OTUk(v) G.709 OCh 315 ODUk mapped into OTUk(v) 316 49 CBR/CBRa G.709 ODUk, G.709 OCh 317 50 CBRb G.709 ODUk 318 51 BSOT G.709 ODUk 319 52 BSNT G.709 ODUk 320 53 IP/PPP (GFP) G.709 ODUk (and SDH) 321 54 Ethernet MAC (framed GFP) G.709 ODUk (and SDH) 322 55 Ethernet PHY (transparent GFP) G.709 ODUk (and SDH) 324 D.Papadimitriou et al. - Internet Draft � Expires April 2003 6 325 Note: Value 49 and 50 includes mapping of SDH 327 The following table summarizes the update of the G-PID values 328 defined in [GMPLS-SIG]: 330 Value G-PID Type LSP Encoding Type 331 ----- ---------- ----------------- 332 32 ATM Mapping SDH, G.709 ODUk 333 33 Ethernet PHY SDH, G.709 OCh, Lambda, Fiber 334 34 Sonet/SDH G.709 OCh, Lambda, Fiber 335 35 Reserved (SONET Dep.) G.709 OCh, Lambda, Fiber 337 3.2 G.709 Traffic-Parameters 339 When G.709 Digital Path Layer or G.709 Optical Channel Layer is 340 specified in the LSP Encoding Type field, the information referred 341 to as technology dependent information (or simply traffic- 342 parameters) is carried additionally to the one included in the 343 Generalized Label Request and is defined as follows: 345 0 1 2 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | Signal Type | Reserved | NMC | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | NVC | Multiplier (MT) | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | Reserved | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 In this frame, NMC stands for Number of Multiplexed Components, NVC 356 for Number of Virtual Components and MT for Multiplier. Each of 357 these fields is tailored to support G.709 LSP requests. 359 3.2.1 Signal Type (ST) 361 This field (8 bits) indicates the type of G.709 Elementary Signal 362 that comprises the requested LSP. The permitted values are: 364 Value Type 365 ----- ---- 366 0 Irrelevant 367 1 ODU1 (i.e. 2.5 Gbps) 368 2 ODU2 (i.e. 10 Gbps) 369 3 ODU3 (i.e. 40 Gbps) 370 4 Reserved 371 5 Reserved 372 6 OCh at 2.5 Gbps 373 7 OCh at 10 Gbps 374 8 OCh at 40 Gbps 375 9-255 Reserved 377 D.Papadimitriou et al. - Internet Draft � Expires April 2003 7 378 The value of the Signal Type field depends on LSP Encoding Type 379 value defined in Section 3.1.1 and [GMPLS-SIG]: 380 - if the LSP Encoding Type value is the G.709 Digital Path layer 381 then the valid values are the ODUk signals (k = 1, 2 or 3) 382 - if the LSP Encoding Type value is the G.709 Optical Channel layer 383 then the valid values are the OCh at 2.5, 10 or 40 Gbps 384 - if the LSP Encoding Type is �Lambda� (which includes the 385 pre-OTN Optical Channel layer) then the valid value is irrelevant 386 (Signal Type = 0) 387 - if the LSP Encoding Type is �Digital Wrapper�, then the valid 388 value is irrelevant (Signal Type = 0) 390 Several transforms can be sequentially applied on the Elementary 391 Signal to build the Final Signal being actually requested for the 392 LSP. Each transform application is optional and must be ignored if 393 zero, except the Multiplier (MT) that cannot be zero and must be 394 ignored if equal to one. Transforms must be applied strictly in the 395 following order: 396 - First, virtual concatenation (by using the NVC field) can 397 be optionally applied directly on the Elementary Signal to form a 398 Composed Signal 399 - Second, a multiplication (by using the Multiplier field) can be 400 optionally applied either directly on the Elementary Signal, or 401 on the virtually concatenated signal obtained from the first 402 phase. The resulting signal is referred to as Final Signal. 404 3.2.2 Number of Multiplexed Components (NMC) 406 The NMC field (16 bits) indicates the number of ODU tributary slots 407 used by an ODUj when multiplexed into an ODUk (k > j) for the 408 requested LSP. This field is not applicable when an ODUk is mapped 409 into an OTUk and irrelevant at the Optical Channel layer. In both 410 cases, it MUST be set to zero (NMC = 0) when sent and should be 411 ignored when received. 413 When applied at the Digital Path layer, in particular for ODU2 414 connections multiplexed into one ODU3 payload, the NMC field 415 specifies the number of individual tributary slots (NMC = 4) 416 constituting the requested connection. These components are still 417 processed within the context of a single connection entity. For all 418 other currently defined multiplexing cases (see Section 2), the NMC 419 field is set to 1. 421 3.2.3 Number of Virtual Components (NVC) 423 The NVC field (16 bits) is dedicated to ODUk virtual concatenation 424 (i.e. ODUk Inverse Multiplexing) purposes. It indicates the number 425 of ODU1, ODU2 or ODU3 Elementary Signals that are requested to be 426 virtually concatenated to form an ODUk-Xv signal. By definition, 427 these signals MUST be of the same type. 429 This field is set to 0 (default value) to indicate that no virtual 430 concatenation is requested. 432 D.Papadimitriou et al. - Internet Draft � Expires April 2003 8 433 Note that the current usage of this field only applies for G.709 434 ODUk LSP i.e. values greater than zero are only acceptable for ODUk 435 Signal Types. Therefore, it MUST be set to zero (NVC = 0) when 436 requesting a G.709 OCh LSP and should be ignored when received. 438 3.2.4 Multiplier (MT) 440 The Multiplier field (16 bits) indicates the number of identical 441 Elementary Signals or Composed Signals requested for the LSP i.e. 442 that form the Final Signal. A Composed Signal is the resulting 443 signal from the application of the NMC and NVC fields to an 444 elementary Signal Type. GMPLS signalling currently implies that all 445 the Composed Signals must be part of the same LSP. 447 This field is set to one (default value) to indicate that exactly 448 one instance of a signal is being requested. Intermediate and egress 449 nodes MUST verify that the node itself and the interfaces on which 450 the LSP will be established can support the requested multiplier 451 value. If the requested values can not be supported, the receiver 452 node MUST generate a PathErr/NOTIFICATION message (see Section 453 6.1/6.2, respectively). 455 Zero is an invalid value. If received, the node MUST generate a 456 PathErr/NOTIFICATION message (see Section 6.1/6.2, respectively). 458 3.2.5 Reserved Fields 460 The reserved fields (8 bits and 32 bits) are dedicated for future 461 use. Reserved bits should be set to zero when sent and must be 462 ignored when received. 464 4. Generalized Label 466 This section describes the Generalized Label space for the Digital 467 Path and the Optical Channel Layer. The label distribution rules 468 follows the ones defined in [GMPLS-SONET-SDH] and are detailed in 469 Section 4.2. 471 4.1 ODUk Label Space 473 At the Digital Path layer (i.e. ODUk layers), G.709 defines three 474 different client payload bit rates. An Optical Data Unit (ODU) frame 475 has been defined for each of these bit rates. ODUk refers to the 476 frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps) or 477 3 (for 40 Gbps). 479 In addition to the support of ODUk mapping into OTUk, the G.709 480 label space supports the sub-levels of ODUk multiplexing. ODUk 481 multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk 482 (k > j), in particular: 483 - ODU1 into ODU2 multiplexing 484 - ODU1 into ODU3 multiplexing 486 D.Papadimitriou et al. - Internet Draft � Expires April 2003 9 487 - ODU2 into ODU3 multiplexing 488 - ODU1 and ODU2 into ODU3 multiplexing 490 More precisely, ODUj into ODUk multiplexing (k > j) is defined when 491 an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an 492 ODTUG constituted by ODU tributary slots) which is mapped into an 493 OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is 494 mapped into an OTUk. 496 Therefore, the label space structure is a tree whose root is an OTUk 497 signal and leaves the ODUj signals (k >= j) that can be transported 498 via the tributary slots and switched between these slots. A G.709 499 Digital Path layer label identifies the exact position of a 500 particular ODUj signal in an ODUk multiplexing structure. 502 The G.709 Digital Path Layer label or ODUk label has the following 503 format: 505 0 1 2 3 506 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 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Reserved | t3 | t2 |t1| 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 The specification of the three fields t1, t2 and t3 self- 512 consistently characterizes the ODUk label space. The value space of 513 the t1, t2 and t3 fields is defined as follows: 515 1. t1 (1-bit): 516 - t1=1 indicates an ODU1 signal. 517 - t1 is not significant for the other ODUk signal types (t1=0). 519 2. t2 (3-bit): 520 - t2=1 indicates a not further sub-divided ODU2 signal. 521 - t2=2->5 indicates the tributary slot (t2th-2) used by the 522 ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2). 523 - t2 is not significant for an ODU3 (t2=0). 525 3. t3 (6-bit): 526 - t3=1 indicates a not further sub-divided ODU3 signal. 527 - t3=2->17 indicates the tributary slot (t3th-1) used by the 528 ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3). 529 - t3=18->33 indicates the tributary slot (t3th-17) used by the 530 ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3). 532 Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required 533 to identify the 4 tributary slots used by the ODU2; these tributary 534 time slots have to be allocated in ascending order. 536 If the label sub-field value t[i]=1 (i, j = 1, 2 or 3) and t[j]=0 (j 537 > i), the corresponding ODUk signal ODU[i] is directly mapped into 538 the corresponding OTUk signal (k=i). This is referred to as the 539 mapping of an ODUk signal into an OTUk of the same order. Therefore, 541 D.Papadimitriou et al. - Internet Draft � Expires April 2003 10 542 the numbering starts at 1; zero is used to indicate a non- 543 significant field. A label field equal to zero is an invalid value. 545 Examples: 546 - t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1 547 - t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2 548 - t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3 549 - t3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot 550 of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2 551 - t3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot 552 of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3 554 4.2 Label Distribution Rules 556 In case of ODUk in OTUk mapping, only one of label can appear in the 557 Generalized Label. 559 In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered 560 list of the labels in the multiplex is given (this list can be 561 restricted to only one label when NMC = 1). Each label indicates a 562 component (ODUj tributary slot) of the multiplexed signal. The order 563 of the labels must reflect the order of the ODUj into the multiplex 564 (not the physical order of tributary slots). 566 In case of ODUk virtual concatenation, the explicit ordered list of 567 all labels in the concatenation is given. Each label indicates a 568 component of the virtually concatenated signal. The order of the 569 labels must reflect the order of the ODUk to concatenate (not the 570 physical order of time-slots). This representation limits virtual 571 concatenation to remain within a single (component) link. In case of 572 multiplexed virtually concatenated signals, the first set of labels 573 indicates the components (ODUj tributary slots) of the first 574 virtually concatenated signal, the second set of labels indicates 575 the components (ODUj tributary slots) of the second virtually 576 concatenated signal, and so on. 578 In case of multiplication (i.e. when using the MT field), the 579 explicit ordered list of all labels taking part in the composed 580 signal is given. The above representation limits multiplication to 581 remain within a single (component) link. In case of multiplication 582 of multiplexed/virtually concatenated signals, the first set of 583 labels indicates the components of the first multiplexed/virtually 584 concatenated signal, the second set of labels indicates components 585 of the second multiplexed/virtually concatenated signal, and so on. 587 Note: As defined in [GMPLS-SIG], label field values only have 588 significance between two neighbors, and the receiver may need (in 589 some particular cases) to convert the received value into a value 590 that has local significance. 592 4.3 Optical Channel Label Space 594 D.Papadimitriou et al. - Internet Draft � Expires April 2003 11 595 At the Optical Channel layer, the label space must be consistently 596 defined as a flat space whose values reflect the local assignment of 597 OCh identifiers corresponding to the OTM-n.m sub-interface signals 598 (m = 1, 2 or 3). Note that these identifiers do not cover OChr since 599 the corresponding Connection Function (OChr-CF) between OTM- 600 nr.m/OTM-0r.m is not defined in [ITUT-G798]. 602 The OCh label space values are defined by either absolute values 603 (i.e. channel identifiers or Channel ID also referred to as 604 wavelength identifiers) or relative values (channel spacing also 605 referred to as inter-wavelength spacing). The latter is strictly 606 confined to a per-port label space while the former could be defined 607 as a local or a global (per node) label space. Such an OCh label 608 space is applicable to both OTN Optical Channel layer and pre-OTN 609 Optical Channel layer. 611 Optical Channel label encoding (and distribution) rules are defined 612 in [GMPSL-SIG]. They MUST be used for the Upstream Label, the 613 Suggested Label and the Generalized Label. 615 5. Examples 617 The following examples are given in order to illustrate the 618 processing described in the previous sections of this document. 620 1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is 621 directly transported in an OTU1 (OTU2 or OTU3), the upstream node 622 requests results simply in an ODU1 (ODU2 or ODU3) signal request. 624 In such conditions, the downstream node has to return a unique 625 label since the ODU1 (ODU2 or ODU3) is directly mapped into the 626 corresponding OTU1 (OTU2 or OTU3). Since a single ODUk signal is 627 requested (Signal Type = 1, 2 or 3), the downstream node has to 628 return a single ODUk label which can be for instance one of the 629 following when the Signal Type = 1: 631 - t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1 632 - t3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2 633 - t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3 635 2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed 636 into the payload of a structured ODU2 (or ODU3), the upstream 637 node requests results simply in a ODU1 signal request. 639 In such conditions, the downstream node has to return a unique 640 label since the ODU1 is multiplexed into one ODTUG2 (or ODTUG3). 641 The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or 642 OPU3) and then mapped into the corresponding OTU2 (or OTU3). 643 Since a single ODU1 multiplexed signal is requested (Signal Type 644 = 1 and NMC = 1), the downstream node has to return a single ODU1 645 label which can take for instance one of the following values: 647 - t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2 649 D.Papadimitriou et al. - Internet Draft � Expires April 2003 12 650 - t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3 651 - t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3 653 3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is 654 multiplexed into the payload of a structured ODU3, the upstream 655 node requests results simply in a ODU2 signal request. 657 In such conditions, the downstream node has to return four labels 658 since the ODU2 is multiplexed into one ODTUG3. The latter is 659 mapped into an ODU3 (via OPU3) and then mapped into an OTU3. 660 Since an ODU2 multiplexed signal is requested (Signal Type = 2, 661 and NMC = 4), the downstream node has to return four ODU labels 662 which can take for instance the following values: 664 - t3=18, t2=0, t1=0 (first part of ODU2 in first TS of ODTUG3) 665 - t3=22, t2=0, t1=0 (second part of ODU2 in fifth TS of ODTUG3) 666 - t3=23, t2=0, t1=0 (third part of ODU2 in sixth TS of ODTUG3) 667 - t3=26, t2=0, t1=0 (fourth part of ODU2 in ninth TS of ODTUG3) 669 4. When a single OCh signal of 40 Gbps is requested (Signal Type = 670 8), the downstream node must return a single wavelength 671 label as specified in [GMPLS-SIG]. 673 5. When requesting multiple ODUk LSP (i.e. with a multiplier (MT) 674 value > 1), an explicit list of labels is returned to the 675 requestor node. 677 When the downstream node receives a request for a 4 x ODU1 signal 678 (Signal Type = 1, NMC = 1 and MT = 4) multiplexed into a ODU3, it 679 returns an ordered list of four labels to the upstream node: the 680 first ODU1 label corresponding to the first signal of the LSP, 681 the second ODU1 label corresponding to the second signal of the 682 LSP, etc. For instance, the corresponding labels can take the 683 following values: 685 - First ODU1: t3=2, t2=0, t1=0 (in first TS of ODTUG3) 686 - Second ODU1: t3=10, t2=0, t1=0 (in ninth TS of ODTUG3) 687 - Third ODU1: t3=7, t2=0, t1=0 (in sixth TS of ODTUG3) 688 - Fourth ODU1: t3=6, t2=0, t1=0 (in fifth TS of ODTUG3) 690 6. Signalling Protocol Extensions 692 This section specifies the [GMPLS-RSVP] and [GMPLS-LDP] protocol 693 extensions needed to accommodate G.709 traffic parameters. 695 6.1 RSVP-TE Details 697 For RSVP-TE, the G.709 traffic parameters are carried in the G.709 698 SENDER_TSPEC and FLOWSPEC objects. The same format is used both 699 for SENDER_TSPEC object and FLOWSPEC objects. The content of the 700 objects is defined above in Section 3.2. The objects have the 701 following class and type for G.709: 702 - G.709 SENDER_TSPEC Object: Class = 12, C-Type = TBA 704 D.Papadimitriou et al. - Internet Draft � Expires April 2003 13 705 - G.709 FLOWSPEC Object: Class = 9, C-Type = TBA 707 There is no Adspec associated with the SONET/SDH SENDER_TSPEC. 708 Either the Adspec is omitted or an Int-serv Adspec with the 709 Default General Characterization Parameters and Guaranteed Service 710 fragment is used, see [RFC2210]. 712 For a particular sender in a session the contents of the FLOWSPEC 713 object received in a Resv message SHOULD be identical to the 714 contents of the SENDER_TSPEC object received in the corresponding 715 Path message. If the objects do not match, a ResvErr message with 716 a "Traffic Control Error/Bad Flowspec value" error SHOULD be 717 generated. 719 Intermediate and egress nodes MUST verify that the node itself and 720 the interfaces on which the LSP will be established can support 721 the requested Signal Type, NMC and NVC values (as defined in 722 Section 3.2). If the requested value(s) can not be supported, the 723 receiver node MUST generate a PathErr message with a "Traffic 724 Control Error/ Service unsupported" indication (see [RFC2205]). 726 In addition, if the MT field is received with a zero value, the 727 node MUST generate a PathErr message with a "Traffic Control 728 Error/Bad Tspec value" indication (see [RFC2205]). 730 6.2 CR-LDP Details 732 For CR-LDP, the G.709 traffic parameters are carried in the G.709 733 Traffic Parameters TLV. The content of the TLV is defined in 734 Section 3.2. The header of the TLV has the following format: 736 0 1 2 3 737 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 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 |U|F| Type | Length | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 742 The type field indicates G.709 traffic parameters: 0xTBA 744 Intermediate and egress nodes MUST verify that the node itself and 745 the interfaces on which the LSP will be established can support 746 the requested Signal Type, NMC and NVC values (as defined in 747 Section 3.2). If the requested value(s) can not be supported, the 748 receiver node MUST generate a NOTIFICATION message with a 749 "Resource Unavailable" status code (see [RFC3212]). 751 In addition, if the MT field is received with a zero value, the 752 node MUST generate a NOTIFICATION message with a "Resource 753 Unavailable" status code (see [RFC3212]). 755 7. Security Considerations 757 D.Papadimitriou et al. - Internet Draft � Expires April 2003 14 758 This draft introduces no new security considerations to either 759 [GMPLS-RSVP] or [GMPLS-LDP]. GMPLS security is described in 760 section 11 of [GMPLS-SIG], in [RFC-3212] and in [RFC-3209]. 762 8. IANA Considerations 764 IANA assigns values to RSVP-TE objects (see [RFC-3209]) and CR-LDP 765 (see [RFC-3212]). 767 Two C-Type values have to be assigned by IANA for the following 768 RSVP objects: 769 - G.709 SENDER_TSPEC object: Class = 12, C-Type = TBA (see Section 770 6.1). 771 - G.709 FLOWSPEC object: Class = 9, C-Type = TBA (see Section 772 6.1). 774 This draft also uses the LDP [RFC 3031] name spaces, which require 775 assignment of the Type field for the following TLV: 776 - G.709 Traffic Parameters TLV (see section 6.2). 778 9. Acknowledgments 780 The authors would like to thank Jean-Loup Ferrant, Mathieu Garnot, 781 Massimo Canali, Germano Gasparini and Fong Liaw for their 782 constructive comments and inputs as well as James Fu, Siva 783 Sankaranarayanan and Yangguang Xu for their useful feedback. 785 This draft incorporates (upon agreement) material and ideas from 786 draft-lin-ccamp-ipo-common-label-request-00.txt. 788 10. Intellectual Property Notice 790 The IETF takes no position regarding the validity or scope of any 791 intellectual property or other rights that might be claimed to 792 pertain to the implementation or use of the technology described in 793 this document or the extent to which any license under such rights 794 might or might not be available; neither does it represent that it 795 has made any effort to identify any such rights. Information on the 796 IETF's procedures with respect to rights in standards-track and 797 standards-related documentation can be found in BCP-11. Copies of 798 claims of rights made available for publication and any assurances 799 of licenses to be made available, or the result of an attempt made 800 to obtain a general license or permission for the use of such 801 proprietary rights by implementors or users of this specification 802 can be obtained from the IETF Secretariat. 804 The IETF invites any interested party to bring to its attention any 805 copyrights, patents or patent applications, or other proprietary 806 rights which may cover technology that may be required to practice 807 this standard. Please address the information to the IETF Executive 808 Director. 810 D.Papadimitriou et al. - Internet Draft � Expires April 2003 15 811 11. References 813 11.1 Normative References 815 [ITUT-G707] ITU-T G.707 Recommendation, �Network node interface for 816 the synchronous digital hierarchy (SDH)�, ITU-T, 817 October 2000. 819 [ITUT-G709] ITU-T G.709 Recommendation, version 1.0 (and Amendment 820 1), �Interface for the Optical Transport Network 821 (OTN)�, ITU-T, February 2001 (and October 2001). 823 [ITUT-G798] ITU-T G.798 Recommendation, version 1.0, 824 �Characteristics of Optical Transport Network Hierarchy 825 Equipment Functional Blocks�, ITU-T, October 2001. 827 [ITUT-G872] ITU-T G.872 Recommendation, version 2.0, �Architecture 828 of Optical Transport Network�, ITU-T, October 2001. 830 [GMPLS-ARCH] E.Mannie (Editor) et al., �Generalized Multi-Protocol 831 Label Switching (GMPLS) Architecture�, Internet Draft, 832 Work in progress, draft-ietf-ccamp-gmpls-architecture- 833 03.txt, August 2002. 835 [GMPLS-LDP] L.Berger (Editor) et al., �Generalized MPLS Signaling - 836 CR-LDP Extensions�, Internet Draft, Work in progress, 837 draft-ietf-mpls-generalized-cr-ldp-07.txt, August 2002. 839 [GMPLS-RSVP] L.Berger (Editor) et al., �Generalized MPLS Signaling - 840 RSVP-TE Extensions�, Internet Draft, Work in progress, 841 draft-ietf-mpls-generalized-rsvp-te-08.txt, August 842 2002. 844 [GMPLS-RTG] K.Kompella et al., �Routing Extensions in Support of 845 Generalized MPLS�, Internet Draft, Work in Progress, 846 draft-ietf-ccamp-gmpls-routing-05.txt, September 2002. 848 [GMPLS-SIG] L.Berger (Editor) et al., �Generalized MPLS 849 - Signaling Functional Description�, Internet Draft, 850 Work in progress, draft-ietf-mpls-generalized- 851 signaling-09.txt, August 2002. 853 [GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al., 854 �Generalized Multiprotocol Label Switching Extensions 855 for SONET and SDH Control�, Internet Draft, Work in 856 progress, draft-ietf-ccamp-gmpls-sonet-sdh-06.txt, 857 August 2002. 859 [RFC-2119] S.Bradner, "Key words for use in RFCs to Indicate 860 Requirement Levels," RFC 2119. 862 D.Papadimitriou et al. - Internet Draft � Expires April 2003 16 864 [RFC-2205] R.Braden et al., "Resource ReSerVation Protocol (RSVP) 865 -- Version 1 Functional Specification", RFC 2205, 866 September 1997. 868 [RFC-2210] J.Wroclawski, �The Use of RSVP with IETF Integrated 869 Services�, Internet RFC 2210, IETF Standard Track, 870 September 1997. 872 [RFC-3036] L.Andersson et al., �LDP Specification�, Internet RFC 873 3036, IETF Proposed Standard, January 2001. 875 [RFC-3209] D.Awduche et al., �RSVP-TE: Extensions to RSVP for LSP 876 Tunnels�, Internet RFC 3209, IETF Proposed Standard, 877 December 2001. 879 [RFC-3212] B.Jamoussi (Editor) et al. �Constraint-Based LSP Setup 880 using LDP�, Internet RFC 3212, IETF Proposed Standard, 881 January 2002. 883 12. Contributors 885 Alberto Bellato (Alcatel) 886 Via Trento 30, 887 I-20059 Vimercate, Italy 888 Phone: +39 039 686-7215 889 Email: alberto.bellato@netit.alcatel.it 891 Sudheer Dharanikota (Nayna Networks) 892 157 Topaz Street, 893 Milpitas, CA 95035, USA 894 Phone: +1 408 956-8000X357 895 Email: sudheer@nayna.com 897 Michele Fontana (Alcatel) 898 Via Trento 30, 899 I-20059 Vimercate, Italy 900 Phone: +39 039 686-7053 901 Email: michele.fontana@netit.alcatel.it 903 Nasir Ghani (Sorrento Networks) 904 9990 Mesa Rim Road, 905 San Diego, CA 92121, USA 906 Phone: +1 858 646-7192 907 Email: nghani@sorrentonet.com 909 Gert Grammel (Alcatel) 910 Via Trento 30, 911 I-20059 Vimercate, Italy 912 Phone: +39 039 686-4453 913 Email: gert.grammel@netit.alcatel.it 915 Dan Guo (Turin Networks) 916 1415 N. McDowell Blvd, 918 D.Papadimitriou et al. - Internet Draft � Expires April 2003 17 919 Petaluma, CA 94954, USA 920 Phone: +1 707 665-4357 921 Email: dguo@turinnetworks.com 923 Juergen Heiles (Siemens AG) 924 Hofmannstr. 51, 925 D-81379 Munich, Germany 926 Phone: +49 897 224-8664 927 Email: juergen.heiles@icn.siemens.de 929 Jim Jones (Alcatel) 930 3400 W. Plano Parkway, Plano, TX 75075, USA 931 Phone: +1 972 519-2744 932 Email: Jim.D.Jones1@usa.alcatel.com 934 Zhi-Wei Lin (Lucent) 935 101 Crawfords Corner Rd, Rm 3C-512 936 Holmdel, New Jersey 07733-3030, USA 937 Tel: +1 732 949-5141 938 Email: zwlin@lucent.com 940 Eric Mannie (KPNQwest) 941 Terhulpsesteenweg, 6A, 942 1560 Hoeilaart, Belgium 943 Phone: +32 2 658-5652 944 Email: eric.mannie@ebone.com 946 Maarten Vissers (Lucent) 947 Boterstraat 45, Postbus 18, 948 1270 AA Huizen, Netherlands 949 Email: mvissers@lucent.com 951 Yong Xue (WorldCom) 952 22001 Loudoun County Parkway, 953 Ashburn, VA 20147, USA 954 Tel: +1 703 886-5358 955 Email: yong.xue@wcom.com 957 13. Author�s Address 959 Dimitri Papadimitriou (Alcatel) 960 Francis Wellesplein 1, 961 B-2018 Antwerpen, Belgium 962 Phone: +32 3 240-8491 963 Email: dimitri.papadimitriou@alcatel.be 965 D.Papadimitriou et al. - Internet Draft � Expires April 2003 18 966 Appendix 1 � Abbreviations 968 BSNT Bit Stream without Octet Timing 969 BSOT Bit Stream with Octet Timing 970 CBR Constant Bit Rate 971 ESCON Enterprise Systems Connection 972 FC Fiber Channel 973 FEC Forward Error Correction 974 FICON Fiber Connector 975 FSC Fiber Switch Capable 976 GCC General Communication Channel 977 GFP Generic Framing Procedure 978 LSC Lambda Switch Capable 979 LSP Label Switched Path 980 MS Multiplex Section 981 naOH non-associated Overhead 982 NMC Number of Multiplexed Components 983 NVC Number of Virtual Components 984 OCC Optical Channel Carrier 985 OCG Optical Carrier Group 986 OCh Optical Channel (with full functionality) 987 OChr Optical Channel (with reduced functionality) 988 ODTUG Optical Date Tributary Unit Group 989 ODU Optical Channel Data Unit 990 OH Overhead 991 OMS Optical Multiplex Section 992 OMU Optical Multiplex Unit 993 OOS OTM Overhead Signal 994 OPS Optical Physical Section 995 OPU Optical Channel Payload Unit 996 OSC Optical Supervisory Channel 997 OTH Optical Transport Hierarchy 998 OTM Optical Transport Module 999 OTN Optical Transport Network 1000 OTS Optical Transmission Section 1001 OTU Optical Channel Transport Unit 1002 OTUkV Functionally Standardized OTUk 1003 PPP Point to Point Protocol 1004 PSC Packet Switch Capable 1005 RES Reserved 1006 RS Regenerator Section 1007 TTI Trail Trace Identifier 1008 TDM Time Division Multiplex 1010 Appendix 2 � G.709 Indexes 1012 - Index k: The index "k" is used to represent a supported bit rate 1013 and the different versions of OPUk, ODUk and OTUk. k=1 represents an 1014 approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate 1015 bit rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s 1016 and k = 4 an approximate bit rate of 160 Gbit/s (under definition). 1017 The exact bit-rate values are in kbits/s: 1018 . OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322 1020 D.Papadimitriou et al. - Internet Draft � Expires April 2003 19 1021 . ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983 1022 . OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559 1024 - Index m: The index "m" is used to represent the bit rate or set of 1025 bit rates supported on the interface. This is a one or more digit 1026 �k�, where each �k� represents a particular bit rate. The valid 1027 values for m are (1, 2, 3, 12, 23, 123). 1029 - Index n: The index "n" is used to represent the order of the OTM, 1030 OTS, OMS, OPS, OCG and OMU. This index represents the maximum number 1031 of wavelengths that can be supported at the lowest bit rate 1032 supported on the wavelength. It is possible that a reduced number of 1033 higher bit rate wavelengths are supported. The case n=0 represents a 1034 single channel without a specific wavelength assigned to the 1035 channel. 1037 - Index r: The index "r", if present, is used to indicate a reduced 1038 functionality OTM, OCG, OCC and OCh (non-associated overhead is not 1039 supported). Note that for n=0 the index r is not required as it 1040 implies always reduced functionality. 1042 D.Papadimitriou et al. - Internet Draft � Expires April 2003 20 1043 Full Copyright Statement 1045 "Copyright (C) The Internet Society (date). All Rights Reserved. 1046 This document and translations of it may be copied and furnished to 1047 others, and derivative works that comment on or otherwise explain it 1048 or assist in its implementation may be prepared, copied, published 1049 and distributed, in whole or in part, without restriction of any 1050 kind, provided that the above copyright notice and this paragraph 1051 are included on all such copies and derivative works. However, this 1052 document itself may not be modified in any way, such as by removing 1053 the copyright notice or references to the Internet Society or other 1054 Internet organizations, except as needed for the purpose of 1055 developing Internet standards in which case the procedures for 1056 copyrights defined in the Internet Standards process must be 1057 followed, or as required to translate it into languages other than 1058 English. 1060 The limited permissions granted above are perpetual and will not be 1061 revoked by the Internet Society or its successors or assigns. 1063 This document and the information contained herein is provided on an 1064 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1065 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1066 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1067 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1068 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1070 D.Papadimitriou et al. - Internet Draft � Expires April 2003 21