idnits 2.17.1 draft-ietf-ccamp-gmpls-g709-05.txt: -(145): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1025): 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: ---------------------------------------------------------------------------- ** 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? == There are 2 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 673 has weird spacing: '... (first part ...' == Line 675 has weird spacing: '... (third part ...' -- 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 (January 2004) is 7405 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: 'GMPLS-SIG' is mentioned on line 170, but not defined == Unused Reference: 'ITUT-G707' is defined on line 830, but no explicit reference was found in the text == Unused Reference: 'ITUT-G872' is defined on line 842, but no explicit reference was found in the text == Unused Reference: 'GMPLS-ARCH' is defined on line 845, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 863, but no explicit reference was found in the text == Unused Reference: 'RFC3036' is defined on line 873, 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' -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-SONET-SDH' ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group D. Papadimitriou - Editor 2 Internet Draft (Alcatel) 3 Category: Standard Track 5 Expiration Date: June 2004 January 2004 7 Generalized MPLS Signalling Extensions 8 for G.709 Optical Transport Networks Control 10 draft-ietf-ccamp-gmpls-g709-05.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 (Editor) et al. - Expires June 2004 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 ........................................ 5 63 3.1.2. Switching-Type ........................................... 5 64 3.1.3. Generalized-PID (G-PID) .................................. 6 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) ....................... 9 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 .......................................... 10 73 4.2. Label Distribution Rules .................................. 11 74 4.3. OCh Label Space ........................................... 12 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 ..................................... 15 80 8. IANA Considerations ......................................... 15 81 9. Acknowledgments ............................................. 15 82 10. Intellectual Property Notice ............................... 16 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 [RFC3471], 99 [RFC3473] and [RFC3472]. Abbreviations used in this document are 100 detailed in Appendix 1. 102 D.Papadimitriou (Editor) et al. - Expires June 2004 2 103 1. Introduction 105 Generalized MPLS (GMPLS) extends MPLS from supporting Packet 106 Switching Capable (PSC) interfaces and switching to include 107 support of three new classes of interfaces and switching: Time- 108 Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch 109 (FSC) Capable. A functional description of the extensions to MPLS 110 signaling needed to support these new classes of interfaces and 111 switching is provided in [RFC3471]. [RFC3473] describes RSVP-TE 112 specific formats and mechanisms needed to support all four classes 113 of interfaces, and CR-LDP extensions can be found in [RFC3472]. 115 This document presents the technology details that are specific to 116 G.709 Optical Transport Networks (OTN) as specified in the ITU-T 117 G.709 recommendation [ITUT-G709] (and referenced documents), 118 including pre-OTN developments. Per [RFC3471], G.709 technology 119 specific parameters are carried through the signaling protocol in 120 dedicated traffic parameter objects. 122 The G.709 traffic parameters defined hereafter (see Section 3.2) 123 MUST be used when the label is encoded as defined in this 124 document. Moreover, the label MUST be encoded as defined in 125 Section 4 when these G.709 traffic parameters are used. 127 Note: in the context of this memo, by pre-OTN developments, one 128 refers to Optical Channel, Digital Wrapper and Forward Error 129 Correction (FEC) solutions that are not fully G.709 compliant. 130 Details concerning pre-OTN Synchronous Optical Network (SONET)/ 131 Synchronous Digital Hierarchy (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 156 D.Papadimitriou (Editor) et al. - Expires June 2004 3 157 multiplexing. It refers to the multiplexing of ODUj (j = 1, 2) into 158 an ODUk (k > j) signal, in particular: 159 - ODU1 into ODU2 multiplexing 160 - ODU1 into ODU3 multiplexing 161 - ODU2 into ODU3 multiplexing 162 - ODU1 and ODU2 into ODU3 multiplexing 164 Therefore, adapting GMPLS to control G.709 OTN, can be achieved by 165 considering that: 166 - a Digital Path layer by extending the previously defined 167 "Digital Wrapper" in [GMPLS-SIG] corresponding to the ODUk 168 (digital) path layer. 169 - an Optical Path layer by extending the "Lambda" concept defined 170 in [GMPLS-SIG] to the OCh (optical) path layer. 171 - a label space structure by considering a tree whose root is an 172 OTUk signal and leaves the ODUj signals (k >= j); enabling to 173 identify the exact position of a particular ODUj signal in an 174 ODUk multiplexing structure. 176 Thus, the GMPLS signalling extensions for G.709 need to cover the 177 Generalized Label Request, the Generalized Label as well as the 178 specific technology dependent objects included in the so-called 179 traffic parameters as specified in [GMPLS-SONET-SDH] for SONET/SDH 180 networks. Moreover, since the multiplexing in the digital domain 181 (such as ODUk multiplexing) has been specified in the amended 182 version of the G.709 ITU-T recommendation (October 2001), this 183 document also proposes a label space definition suitable for that 184 purpose. Notice also that one directly uses the G.709 ODUk (i.e. 185 Digital Path) and OCh (i.e. Optical Path) layers in order to define 186 the corresponding label spaces. 188 3. Generalized Label Request 190 The Generalized Label Request as defined in [RFC3471], includes a 191 technology independent part and a technology dependent part (i.e. 192 the traffic parameters). In this section, both parts are extended to 193 accommodate the GMPLS Signalling to the G.709 transport plane 194 recommendation (see [ITUT-G709]). 196 3.1 Technology Independent Part 198 As defined in [RFC3471], the LSP Encoding Type, the Switching Type 199 and the Generalized Protocol Identifier (Generalized-PID) constitute 200 the technology independent part of the Generalized Label Request. 201 The encoding of the corresponding RSVP-TE object and CR-LDP TLV is 202 specified in [RFC3473] Section 2.1 and [RFC3472] Section 2.1, 203 respectively. 205 As mentioned here above, this document extends the LSP Encoding 206 Type, Switching Type and G-PID (Generalized-PID) values to 207 accommodate G.709 recommendation [ITUT-G709]. 209 D.Papadimitriou (Editor) et al. - Expires June 2004 4 210 3.1.1 LSP Encoding Type 212 Since G.709 defines two networking layers (ODUk layers and OCh 213 layer), the LSP Encoding Type code-points can reflect these two 214 layers currently defined in [RFC3471] as "Digital Wrapper" and 215 "Lambda" code. 217 The LSP Encoding Type is specified per networking layer or more 218 precisely per group of functional networking layer: the ODUk layers 219 and the OCh layer. 221 Therefore, the current "Digital Wrapper" code-point defined in 222 [RFC3471] can be replaced by two separated code-points: 223 - code-point for the G.709 Digital Path layer 224 - code-point for the non-standard Digital Wrapper layer 226 In the same way, two separated code-points can replace the current 227 defined "Lambda" code-point: 228 - code-point for the G.709 Optical Channel layer 229 - code-point for the non-standard Lambda layer (also referred to 230 as Lambda layer which includes the pre-OTN Optical Channel 231 layer) 233 Consequently, the following additional code-points for the LSP 234 Encoding Type are defined: 236 Value Type 237 ----- ---- 238 12 G.709 ODUk (Digital Path) 239 13 G.709 Optical Channel 241 Moreover, the code-point for the G.709 Optical Channel (OCh) layer 242 will indicate the capability of an end-system to use the G.709 non- 243 associated overhead (naOH) i.e. the OTM Overhead Signal (OOS) 244 multiplexed into the OTM-n.m interface signal. 246 3.1.2 Switching Type 248 The Switching Type indicates the type of switching that should be 249 performed at the termination of a particular link. This field is 250 only needed for links that advertise more than one type of switching 251 capability (see [GMPLS-RTG]). 253 Here, no additional values are to be considered in order to 254 accommodate G.709 switching types since an ODUk switching (and so 255 LSPs) belongs to the TDM class while an OCh switching (and so LSPs) 256 to the Lambda class (i.e. LSC). 258 Moreover, in a strict layered G.709 network, when a downstream node 259 receives a Generalized Label Request including one of these values 260 for the Switching Type field, this value SHOULD be ignored. 262 D.Papadimitriou (Editor) et al. - Expires June 2004 5 263 3.1.3 Generalized-PID (G-PID) 265 The G-PID (16 bits field) as defined in [RFC3471], identifies the 266 payload carried by an LSP, i.e. an identifier of the client layer of 267 that LSP. This identifier is used by the endpoints of the G.709 LSP. 269 The G-PID can take one of the following values when the client 270 payload is transported over the Digital Path layer, in addition to 271 the payload identifiers defined in [RFC3471]: 273 - CBRa: asynchronous Constant Bit Rate i.e. mapping of STM-16/OC- 274 48, STM-64/OC-192 and STM-256/OC-768 275 - CBRb: bit synchronous Constant Bit Rate i.e. mapping of STM- 276 16/OC-48, STM-64/OC-192 and STM-256/OC-768 277 - ATM: mapping at 2.5, 10 and 40 Gbps 278 - BSOT: non-specific client Bit Stream with Octet Timing i.e. 279 Mapping of 2.5, 10 and 40 Gbps Bit Stream 280 - BSNT: non-specific client Bit Stream without Octet Timing i.e. 281 Mapping of 2.5, 10 and 40 Gbps Bit Stream 282 - ODUk: transport of Digital Paths at 2.5, 10 and 40 Gbps 283 - ESCON: Enterprise Systems Connection 284 - FICON: Fiber Connection 286 The G-PID can take one of the following values when the client 287 payload is transported over the Optical Channel layer, in addition 288 to the payload identifiers defined in [RFC3471]: 290 - CBR: Constant Bit Rate i.e. mapping of STM-16/OC-48, STM-64/OC-192 291 and STM-256/OC-768 292 - OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps 294 Also, when client payloads such as Ethernet MAC/PHY and IP/PPP are 295 encapsulated through the Generic Framing Procedure (GFP) as 296 described in ITU-T G.7041, dedicated G-PID values are defined. 298 In order to include pre-OTN developments, the G-PID field can take 299 one of the values (currently defined in [RFC3471]) when the 300 following client payloads are transported over a so-called lambda 301 LSP: 303 - Ethernet PHY (1 Gbps and 10 Gbps) 304 - Fiber Channel 306 The following table summarizes the G-PID with respect to the LSP 307 Encoding Type: 309 Value G-PID Type LSP Encoding Type 310 ----- ---------- ----------------- 311 47 G.709 ODUj G.709 ODUk (with k > j) 312 48 G.709 OTUk(v) G.709 OCh 313 ODUk mapped into OTUk(v) 314 49 CBR/CBRa G.709 ODUk, G.709 OCh 315 50 CBRb G.709 ODUk 317 D.Papadimitriou (Editor) et al. - Expires June 2004 6 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) 323 56 ESCON G.709 ODUk, Lambda, Fiber 324 57 FICON G.709 ODUk, Lambda, Fiber 325 58 Fiber Channel G.709 ODUk, Lambda, Fiber 327 Note: Value 49 and 50 includes mapping of SDH 329 The following table summarizes the update of the G-PID values 330 defined in [RFC3471]: 332 Value G-PID Type LSP Encoding Type 333 ----- ---------- ----------------- 334 32 ATM Mapping SDH, G.709 ODUk 335 33 Ethernet PHY SDH, G.709 OCh, Lambda, Fiber 336 34 Sonet/SDH G.709 OCh, Lambda, Fiber 337 35 Reserved (SONET Dep.) G.709 OCh, Lambda, Fiber 339 3.2 G.709 Traffic-Parameters 341 When G.709 Digital Path Layer or G.709 Optical Channel Layer is 342 specified in the LSP Encoding Type field, the information referred 343 to as technology dependent information (or simply traffic- 344 parameters) is carried additionally to the one included in the 345 Generalized Label Request and is defined as follows: 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | Signal Type | Reserved | NMC | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | NVC | Multiplier (MT) | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Reserved | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 In this frame, NMC stands for Number of Multiplexed Components, NVC 358 for Number of Virtual Components and MT for Multiplier. Each of 359 these fields is tailored to support G.709 LSP requests. 361 3.2.1 Signal Type (ST) 363 This field (8 bits) indicates the type of G.709 Elementary Signal 364 that comprises the requested LSP. The permitted values are: 366 Value Type 367 ----- ---- 368 0 Irrelevant 369 1 ODU1 (i.e. 2.5 Gbps) 370 2 ODU2 (i.e. 10 Gbps) 372 D.Papadimitriou (Editor) et al. - Expires June 2004 7 373 3 ODU3 (i.e. 40 Gbps) 374 4 Reserved 375 5 Reserved 376 6 OCh at 2.5 Gbps 377 7 OCh at 10 Gbps 378 8 OCh at 40 Gbps 379 9-255 Reserved 381 The value of the Signal Type field depends on LSP Encoding Type 382 value defined in Section 3.1.1 and [RFC3471]: 383 - if the LSP Encoding Type value is the G.709 Digital Path layer 384 then the valid values are the ODUk signals (k = 1, 2 or 3) 385 - if the LSP Encoding Type value is the G.709 Optical Channel layer 386 then the valid values are the OCh at 2.5, 10 or 40 Gbps 387 - if the LSP Encoding Type is "Lambda" (which includes the 388 pre-OTN Optical Channel layer) then the valid value is irrelevant 389 (Signal Type = 0) 390 - if the LSP Encoding Type is "Digital Wrapper", then the valid 391 value is irrelevant (Signal Type = 0) 393 Several transforms can be sequentially applied on the Elementary 394 Signal to build the Final Signal being actually requested for the 395 LSP. Each transform application is optional and must be ignored if 396 zero, except the Multiplier (MT) that cannot be zero and must be 397 ignored if equal to one. Transforms must be applied strictly in the 398 following order: 399 - First, virtual concatenation (by using the NVC field) can 400 be optionally applied directly on the Elementary Signal to form a 401 Composed Signal 402 - Second, a multiplication (by using the Multiplier field) can be 403 optionally applied either directly on the Elementary Signal, or 404 on the virtually concatenated signal obtained from the first 405 phase. The resulting signal is referred to as Final Signal. 407 3.2.2 Number of Multiplexed Components (NMC) 409 The NMC field (16 bits) indicates the number of ODU tributary slots 410 used by an ODUj when multiplexed into an ODUk (k > j) for the 411 requested LSP. This field is not applicable when an ODUk is mapped 412 into an OTUk and irrelevant at the Optical Channel layer. In both 413 cases, it MUST be set to zero (NMC = 0) when sent and should be 414 ignored when received. 416 When applied at the Digital Path layer, in particular for ODU2 417 connections multiplexed into one ODU3 payload, the NMC field 418 specifies the number of individual tributary slots (NMC = 4) 419 constituting the requested connection. These components are still 420 processed within the context of a single connection entity. For all 421 other currently defined multiplexing cases (see Section 2), the NMC 422 field is set to 1. 424 D.Papadimitriou (Editor) et al. - Expires June 2004 8 425 3.2.3 Number of Virtual Components (NVC) 427 The NVC field (16 bits) is dedicated to ODUk virtual concatenation 428 (i.e. ODUk Inverse Multiplexing) purposes. It indicates the number 429 of ODU1, ODU2 or ODU3 Elementary Signals that are requested to be 430 virtually concatenated to form an ODUk-Xv signal. By definition, 431 these signals MUST be of the same type. 433 This field is set to 0 (default value) to indicate that no virtual 434 concatenation is requested. 436 Note that the current usage of this field only applies for G.709 437 ODUk LSP i.e. values greater than zero, are only acceptable for ODUk 438 Signal Types. Therefore, it MUST be set to zero (NVC = 0) when 439 requesting a G.709 OCh LSP and should be ignored when received. 441 3.2.4 Multiplier (MT) 443 The Multiplier field (16 bits) indicates the number of identical 444 Elementary Signals or Composed Signals requested for the LSP i.e. 445 that form the Final Signal. A Composed Signal is the resulting 446 signal from the application of the NMC and NVC fields to an 447 elementary Signal Type. GMPLS signalling currently implies that all 448 the Composed Signals must be part of the same LSP. 450 This field is set to one (default value) to indicate that exactly 451 one instance of a signal is being requested. Intermediate and egress 452 nodes MUST verify that the node itself and the interfaces on which 453 the LSP will be established can support the requested multiplier 454 value. If the requested values can not be supported, the receiver 455 node MUST generate a PathErr/NOTIFICATION message (see Section 456 6.1/6.2, respectively). 458 Zero is an invalid value. If received, the node MUST generate a 459 PathErr/NOTIFICATION message (see Section 6.1/6.2, respectively). 461 3.2.5 Reserved Fields 463 The reserved fields (8 bits in row 1 and 32 bits fields in row 3) 464 are dedicated for future use. Reserved bits SHOULD be set to zero 465 when sent and MUST be ignored when received. 467 4. Generalized Label 469 This section describes the Generalized Label value space for Digital 470 Paths and Optical Channels. The Generalized Label is defined in 471 [RFC3471]. The format of the corresponding RSVP-TE object and CR-LDP 472 TLV is specified in [RFC3473] Section 2.2 and [RFC3472] Section 2.2, 473 respectively. 475 The label distribution rules detailed in Section 4.2 follow (when 476 applicable) the ones defined in [GMPLS-SONET-SDH]. 478 D.Papadimitriou (Editor) et al. - Expires June 2004 9 479 4.1 ODUk Label Space 481 At the Digital Path layer (i.e. ODUk layers), G.709 defines three 482 different client payload bit rates. An Optical Data Unit (ODU) frame 483 has been defined for each of these bit rates. ODUk refers to the 484 frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps) or 485 3 (for 40 Gbps). 487 In addition to the support of ODUk mapping into OTUk, the G.709 488 label space supports the sub-levels of ODUk multiplexing. ODUk 489 multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk 490 (k > j), in particular: 491 - ODU1 into ODU2 multiplexing 492 - ODU1 into ODU3 multiplexing 493 - ODU2 into ODU3 multiplexing 494 - ODU1 and ODU2 into ODU3 multiplexing 496 More precisely, ODUj into ODUk multiplexing (k > j) is defined when 497 an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an 498 ODTUG constituted by ODU tributary slots) which is mapped into an 499 OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is 500 mapped into an OTUk. 502 Therefore, the label space structure is a tree whose root is an OTUk 503 signal and leaves the ODUj signals (k >= j) that can be transported 504 via the tributary slots and switched between these slots. A G.709 505 Digital Path layer label identifies the exact position of a 506 particular ODUj signal in an ODUk multiplexing structure. 508 The G.709 Digital Path Layer label or ODUk label has the following 509 format: 511 0 1 2 3 512 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 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Reserved | t3 | t2 |t1| 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 Reserved bits MUST be set to zero when sent and SHOULD be ignored 518 when received. 520 The specification of the fields t1, t2 and t3 self-consistently 521 characterizes the ODUk label space. The value space for the t1, t2 522 and t3 fields is defined as follows: 524 1. t1 (1-bit): 525 - t1=1 indicates an ODU1 signal. 526 - t1 is not significant for the other ODUk signal types (t1=0). 528 2. t2 (3-bit): 529 - t2=1 indicates a not further sub-divided ODU2 signal. 530 - t2=2->5 indicates the tributary slot (t2th-2) used by the 531 ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2). 533 D.Papadimitriou (Editor) et al. - Expires June 2004 10 534 - t2 is not significant for an ODU3 (t2=0). 536 3. t3 (6-bit): 537 - t3=1 indicates a not further sub-divided ODU3 signal. 538 - t3=2->17 indicates the tributary slot (t3th-1) used by the 539 ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3). 540 - t3=18->33 indicates the tributary slot (t3th-17) used by the 541 ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3). 543 Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required 544 to identify the 4 tributary slots used by the ODU2; these tributary 545 time slots have to be allocated in ascending order. 547 If the label sub-field value t[i]=1 (i, j = 1, 2 or 3) and t[j]=0 (j 548 > i), the corresponding ODUk signal ODU[i] is directly mapped into 549 the corresponding OTUk signal (k=i). This is referred to as the 550 mapping of an ODUk signal into an OTUk of the same order. Therefore, 551 the numbering starts at 1; zero is used to indicate a non- 552 significant field. A label field equal to zero is an invalid value. 554 Examples: 556 - t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1 557 - t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2 558 - t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3 559 - t3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot 560 of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2 561 - t3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot 562 of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3 564 4.2 Label Distribution Rules 566 In case of ODUk in OTUk mapping, only one of label can appear in the 567 Generalized Label. 569 In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered 570 list of the labels in the multiplex is given (this list can be 571 restricted to only one label when NMC = 1). Each label indicates a 572 component (ODUj tributary slot) of the multiplexed signal. The order 573 of the labels must reflect the order of the ODUj into the multiplex 574 (not the physical order of tributary slots). 576 In case of ODUk virtual concatenation, the explicit ordered list of 577 all labels in the concatenation is given. Each label indicates a 578 component of the virtually concatenated signal. The order of the 579 labels must reflect the order of the ODUk to concatenate (not the 580 physical order of time-slots). This representation limits virtual 581 concatenation to remain within a single (component) link. In case of 582 multiplexed virtually concatenated signals, the first set of labels 583 indicates the components (ODUj tributary slots) of the first 584 virtually concatenated signal, the second set of labels indicates 585 the components (ODUj tributary slots) of the second virtually 586 concatenated signal, and so on. 588 D.Papadimitriou (Editor) et al. - Expires June 2004 11 589 In case of multiplication (i.e. when using the MT field), the 590 explicit ordered list of all labels taking part in the composed 591 signal is given. The above representation limits multiplication to 592 remain within a single (component) link. In case of multiplication 593 of multiplexed/virtually concatenated signals, the first set of 594 labels indicates the components of the first multiplexed/virtually 595 concatenated signal, the second set of labels indicates components 596 of the second multiplexed/virtually concatenated signal, and so on. 598 Note: as defined in [RFC3471], label field values only have 599 significance between two neighbors, and the receiver may need (in 600 some particular cases) to convert the received value into a value 601 that has local significance. 603 4.3 Optical Channel Label Space 605 At the Optical Channel layer, the label space must be consistently 606 defined as a flat space whose values reflect the local assignment of 607 OCh identifiers corresponding to the OTM-n.m sub-interface signals 608 (m = 1, 2 or 3). Note that these identifiers do not cover OChr since 609 the corresponding Connection Function (OChr-CF) between OTM- 610 nr.m/OTM-0r.m is not defined in [ITUT-G798]. 612 The OCh label space values are defined by either absolute values 613 (i.e. channel identifiers or Channel ID also referred to as 614 wavelength identifiers) or relative values (channel spacing also 615 referred to as inter-wavelength spacing). The latter is strictly 616 confined to a per-port label space while the former could be defined 617 as a local or a global (per node) label space. Such an OCh label 618 space is applicable to both OTN Optical Channel layer and pre-OTN 619 Optical Channel layer. 621 Optical Channel label encoding (and distribution) rules are defined 622 in [RFC3471]. They MUST be used for the Upstream Label, the 623 Suggested Label and the Generalized Label. 625 5. Examples 627 The following examples are given in order to illustrate the 628 processing described in the previous sections of this document. 630 1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is 631 directly transported in an OTU1 (OTU2 or OTU3), the upstream node 632 requests results simply in an ODU1 (ODU2 or ODU3) signal request. 634 In such conditions, the downstream node has to return a unique 635 label since the ODU1 (ODU2 or ODU3) is directly mapped into the 636 corresponding OTU1 (OTU2 or OTU3). Since a single ODUk signal is 637 requested (Signal Type = 1, 2 or 3), the downstream node has to 638 return a single ODUk label which can be for instance one of the 639 following when the Signal Type = 1: 641 D.Papadimitriou (Editor) et al. - Expires June 2004 12 642 - t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1 643 - t3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2 644 - t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3 646 2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed 647 into the payload of a structured ODU2 (or ODU3), the upstream 648 node requests results simply in a ODU1 signal request. 650 In such conditions, the downstream node has to return a unique 651 label since the ODU1 is multiplexed into one ODTUG2 (or ODTUG3). 652 The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or 653 OPU3) and then mapped into the corresponding OTU2 (or OTU3). 654 Since a single ODU1 multiplexed signal is requested (Signal Type 655 = 1 and NMC = 1), the downstream node has to return a single ODU1 656 label which can take for instance one of the following values: 658 - t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2 659 - t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3 660 - t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3 662 3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is 663 multiplexed into the payload of a structured ODU3, the upstream 664 node requests results simply in a ODU2 signal request. 666 In such conditions, the downstream node has to return four labels 667 since the ODU2 is multiplexed into one ODTUG3. The latter is 668 mapped into an ODU3 (via OPU3) and then mapped into an OTU3. 669 Since an ODU2 multiplexed signal is requested (Signal Type = 2, 670 and NMC = 4), the downstream node has to return four ODU labels 671 which can take for instance the following values: 673 - t3=18, t2=0, t1=0 (first part of ODU2 in first TS of ODTUG3) 674 - t3=22, t2=0, t1=0 (second part of ODU2 in fifth TS of ODTUG3) 675 - t3=23, t2=0, t1=0 (third part of ODU2 in sixth TS of ODTUG3) 676 - t3=26, t2=0, t1=0 (fourth part of ODU2 in ninth TS of ODTUG3) 678 4. When a single OCh signal of 40 Gbps is requested (Signal Type = 679 8), the downstream node must return a single wavelength 680 label as specified in [RFC3471]. 682 5. When requesting multiple ODUk LSP (i.e. with a multiplier (MT) 683 value > 1), an explicit list of labels is returned to the 684 requestor node. 686 When the downstream node receives a request for a 4 x ODU1 signal 687 (Signal Type = 1, NMC = 1 and MT = 4) multiplexed into a ODU3, it 688 returns an ordered list of four labels to the upstream node: the 689 first ODU1 label corresponding to the first signal of the LSP, 690 the second ODU1 label corresponding to the second signal of the 691 LSP, etc. For instance, the corresponding labels can take the 692 following values: 694 - First ODU1: t3=2, t2=0, t1=0 (in first TS of ODTUG3) 696 D.Papadimitriou (Editor) et al. - Expires June 2004 13 697 - Second ODU1: t3=10, t2=0, t1=0 (in ninth TS of ODTUG3) 698 - Third ODU1: t3=7, t2=0, t1=0 (in sixth TS of ODTUG3) 699 - Fourth ODU1: t3=6, t2=0, t1=0 (in fifth TS of ODTUG3) 701 6. Signalling Protocol Extensions 703 This section specifies the [RFC3473] and [RFC3472] protocol 704 extensions needed to accommodate G.709 traffic parameters. 706 6.1 RSVP-TE Details 708 For RSVP-TE, the G.709 traffic parameters are carried in the G.709 709 SENDER_TSPEC and FLOWSPEC objects. The same format is used both 710 for SENDER_TSPEC object and FLOWSPEC objects. The content of the 711 objects is defined above in Section 3.2. The objects have the 712 following class and type for G.709: 713 - G.709 SENDER_TSPEC Object: Class = 12, C-Type = TBA 714 - G.709 FLOWSPEC Object: Class = 9, C-Type = TBA 716 There is no Adspec associated with the SONET/SDH SENDER_TSPEC. 717 Either the Adspec is omitted or an Int-serv Adspec with the 718 Default General Characterization Parameters and Guaranteed Service 719 fragment is used, see [RFC2210]. 721 For a particular sender in a session the contents of the FLOWSPEC 722 object received in a Resv message SHOULD be identical to the 723 contents of the SENDER_TSPEC object received in the corresponding 724 Path message. If the objects do not match, a ResvErr message with 725 a "Traffic Control Error/Bad Flowspec value" error SHOULD be 726 generated. 728 Intermediate and egress nodes MUST verify that the node itself and 729 the interfaces on which the LSP will be established can support 730 the requested Signal Type, NMC and NVC values (as defined in 731 Section 3.2). If the requested value(s) can not be supported, the 732 receiver node MUST generate a PathErr message with a "Traffic 733 Control Error/Service unsupported" indication (see [RFC2205]). 735 In addition, if the MT field is received with a zero value, the 736 node MUST generate a PathErr message with a "Traffic Control 737 Error/Bad Tspec value" indication (see [RFC2205]). 739 6.2 CR-LDP Details 741 For CR-LDP, the G.709 traffic parameters are carried in the G.709 742 Traffic Parameters TLV. The content of the TLV is defined in 743 Section 3.2. The header of the TLV has the following format: 745 0 1 2 3 746 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 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 |U|F| Type | Length | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 D.Papadimitriou (Editor) et al. - Expires June 2004 14 752 The type field indicates G.709 traffic parameters: 0xTBA 754 Intermediate and egress nodes MUST verify that the node itself and 755 the interfaces on which the LSP will be established can support 756 the requested Signal Type, NMC and NVC values (as defined in 757 Section 3.2). If the requested value(s) can not be supported, the 758 receiver node MUST generate a NOTIFICATION message with a 759 "Resource Unavailable" status code (see [RFC3212]). 761 In addition, if the MT field is received with a zero value, the 762 node MUST generate a NOTIFICATION message with a "Resource 763 Unavailable" status code (see [RFC3212]). 765 7. Security Considerations 767 This draft introduces no new security considerations to either 768 [RFC3473] or [RFC3472]. GMPLS security is described in section 11 769 of [RFC3471] and refers to [RFC3209] for RSVP-TE and to [RFC3212] 770 for CR-LDP. 772 8. IANA Considerations 774 Three values have to be defined by IANA for this document: 776 Two RSVP C-Types in registry: 778 http://www.iana.org/assignments/rsvp-parameters 780 - A G.709 SENDER_TSPEC object: Class = 12, C-Type = TBA 781 (see section 6.1). 783 - A G.709 FLOWSPEC object: Class = 9, C-Type = TBA (see 784 section 6.1). 786 One LDP TLV Type in registry: 788 http://www.iana.org/assignments/ldp-namespaces 790 - A Type field value for the G.709 Traffic Parameters 791 TLV (see section 6.2). 793 9. Acknowledgments 795 The authors would like to thank Jean-Loup Ferrant, Mathieu Garnot, 796 Massimo Canali, Germano Gasparini and Fong Liaw for their 797 constructive comments and inputs as well as James Fu, Siva 798 Sankaranarayanan and Yangguang Xu for their useful feedback. 800 This draft incorporates (upon agreement) material and ideas from 801 draft-lin-ccamp-ipo-common-label-request-00.txt. 803 D.Papadimitriou (Editor) et al. - Expires June 2004 15 804 10. Intellectual Property Notice 806 The IETF takes no position regarding the validity or scope of any 807 intellectual property or other rights that might be claimed to 808 pertain to the implementation or use of the technology described in 809 this document or the extent to which any license under such rights 810 might or might not be available; neither does it represent that it 811 has made any effort to identify any such rights. Information on the 812 IETF's procedures with respect to rights in standards-track and 813 standards-related documentation can be found in BCP-11. Copies of 814 claims of rights made available for publication and any assurances 815 of licenses to be made available, or the result of an attempt made 816 to obtain a general license or permission for the use of such 817 proprietary rights by implementors or users of this specification 818 can be obtained from the IETF Secretariat. 820 The IETF invites any interested party to bring to its attention any 821 copyrights, patents or patent applications, or other proprietary 822 rights which may cover technology that may be required to practice 823 this standard. Please address the information to the IETF Executive 824 Director. 826 11. References 828 11.1 Normative References 830 [ITUT-G707] ITU-T, "Network node interface for the synchronous 831 digital hierarchy (SDH)," G.707 Recommendation, October 832 2000. 834 [ITUT-G709] ITU-T, "Interface for the Optical Transport Network 835 (OTN)," G.709 Recommendation (and Amendment 1), 836 February 2001 (October 2001). 838 [ITUT-G798] ITU-T, "Characteristics of Optical Transport Network 839 Hierarchy Equipment Functional Blocks," G.798 840 Recommendation, October 2001. 842 [ITUT-G872] ITU-T, version 2.0, "Architecture of Optical Transport 843 Network," G.872 Recommendation, October 2001. 845 [GMPLS-ARCH] Mannie, E. (Editor) et al., "Generalized Multi-Protocol 846 Label Switching (GMPLS) Architecture," Internet Draft 847 (work in progress), draft-ietf-ccamp-gmpls- 848 architecture-07.txt, May 2003. 850 [GMPLS-RTG] Kompella, K. (Editor) et al., "Routing Extensions in 851 Support of Generalized MPLS," Internet Draft (work in 852 progress), draft-ietf-ccamp-gmpls-routing-09.txt, 853 October 2003. 855 [GMPLS-SONET-SDH] Mannie, E. and Papadimitriou, D. (Editors) et al., 856 "Generalized Multiprotocol Label Switching Extensions 858 D.Papadimitriou (Editor) et al. - Expires June 2004 16 859 for SONET and SDH Control," Internet Draft (work in 860 progress), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, 861 February 2003. 863 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 864 Requirement Levels," BCP 14, RFC 2119, March 1997. 866 [RFC2205] Braden, R., et al., "Resource ReSerVation Protocol 867 (RSVP) -- Version 1 Functional Specification," RFC 868 2205, September 1997. 870 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 871 Services," RFC 2210, September 1997 873 [RFC3036] Andersson, L. et al., "LDP Specification," RFC 3036, 874 January 2001. 876 [RFC3209] Awduche, D. et al., "RSVP-TE: Extensions to RSVP for 877 LSP Tunnels," RFC 3209, December 2001. 879 [RFC3212] Jamoussi, B. (Editor) et al., "Constraint-Based LSP 880 Setup using LDP," RFC 3212, January 2002. 882 [RFC3471] Berger, L. (Editor) et al., "Generalized Multi- 883 Protocol Label Switching (GMPLS) Signaling - 884 Functional Description," RFC 3471, January 2003. 886 [RFC3472] Berger, L. (Editor) et al., "Generalized Multi- 887 Protocol Label Switching (GMPLS) Signaling - 888 Constraint-based Routed Label Distribution Protocol 889 (CR-LDP) Extensions," RFC 3472, January 2003. 891 [RFC3473] Berger, L. (Editor) et al., "Generalized Multi- 892 Protocol Label Switching (GMPLS) Signaling Resource 893 ReserVation Protocol-Traffic Engineering (RSVP-TE) 894 Extensions," RFC 3473, January 2003. 896 12. Contributors 898 Alberto Bellato (Alcatel) 899 Via Trento 30, 900 I-20059 Vimercate, Italy 901 Email: alberto.bellato@alcatel.it 903 Sudheer Dharanikota (Consult) 904 Email: sudheer@ieee.org 906 Michele Fontana (Alcatel) 907 Via Trento 30, 908 I-20059 Vimercate, Italy 909 Email: michele.fontana@alcatel.it 911 Nasir Ghani (Sorrento Networks) 913 D.Papadimitriou (Editor) et al. - Expires June 2004 17 914 9990 Mesa Rim Road, 915 San Diego, CA 92121, USA 916 Email: nghani@sorrentonet.com 918 Gert Grammel (Alcatel) 919 Lorenzstrasse, 10, 920 70435 Stuttgart, Germany 921 Email: gert.grammel@alcatel.de 923 Dan Guo (Turin Networks) 924 1415 N. McDowell Blvd, 925 Petaluma, CA 94954, USA 926 Email: dguo@turinnetworks.com 928 Juergen Heiles (Siemens) 929 Hofmannstr. 51, 930 D-81379 Munich, Germany 931 Email: juergen.heiles@siemens.com 933 Jim Jones (Alcatel) 934 3400 W. Plano Parkway, 935 Plano, TX 75075, USA 936 Email: jim.d.jones@alcatel.com 938 Zhi-Wei Lin (Lucent) 939 101 Crawfords Corner Rd, Rm 3C-512 940 Holmdel, New Jersey 07733-3030, USA 941 Email: zwlin@lucent.com 943 Eric Mannie (Consult) 944 Email: eric_mannie@hotmail.com 946 Maarten Vissers (Alcatel) 947 Lorenzstrasse, 10, 948 70435 Stuttgart, Germany 949 Email: maarten.vissers@alcalel.de 951 Yong Xue (WorldCom) 952 22001 Loudoun County Parkway, 953 Ashburn, VA 20147, USA 954 Email: yong.xue@wcom.com 956 13. Author's Address 958 Dimitri Papadimitriou (Alcatel) 959 Francis Wellesplein 1, 960 B-2018 Antwerpen, Belgium 961 Phone: +32 3 240-8491 962 Email: dimitri.papadimitriou@alcatel.be 964 D.Papadimitriou (Editor) et al. - Expires June 2004 18 965 Appendix 1 - Abbreviations 967 BSNT Bit Stream without Octet Timing 968 BSOT Bit Stream with Octet Timing 969 CBR Constant Bit Rate 970 ESCON Enterprise Systems Connection 971 FC Fiber Channel 972 FEC Forward Error Correction 973 FICON Fiber Connection 974 FSC Fiber Switch Capable 975 GCC General Communication Channel 976 GFP Generic Framing Procedure 977 LSC Lambda Switch Capable 978 LSP Label Switched Path 979 MS Multiplex Section 980 naOH non-associated Overhead 981 NMC Number of Multiplexed Components 982 NVC Number of Virtual Components 983 OCC Optical Channel Carrier 984 OCG Optical Carrier Group 985 OCh Optical Channel (with full functionality) 986 OChr Optical Channel (with reduced functionality) 987 ODTUG Optical Date Tributary Unit Group 988 ODU Optical Channel Data Unit 989 OH Overhead 990 OMS Optical Multiplex Section 991 OMU Optical Multiplex Unit 992 OOS OTM Overhead Signal 993 OPS Optical Physical Section 994 OPU Optical Channel Payload Unit 995 OSC Optical Supervisory Channel 996 OTH Optical Transport Hierarchy 997 OTM Optical Transport Module 998 OTN Optical Transport Network 999 OTS Optical Transmission Section 1000 OTU Optical Channel Transport Unit 1001 OTUkV Functionally Standardized OTUk 1002 PPP Point to Point Protocol 1003 PSC Packet Switch Capable 1004 RES Reserved 1005 RS Regenerator Section 1006 TTI Trail Trace Identifier 1007 TDM Time Division Multiplex 1009 Appendix 2 - G.709 Indexes 1011 - Index k: The index "k" is used to represent a supported bit rate 1012 and the different versions of OPUk, ODUk and OTUk. k=1 represents an 1013 approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate 1014 bit rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s 1015 and k = 4 an approximate bit rate of 160 Gbit/s (under definition). 1016 The exact bit-rate values are in kbits/s: 1017 . OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322 1019 D.Papadimitriou (Editor) et al. - Expires June 2004 19 1020 . ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983 1021 . OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559 1023 - Index m: The index "m" is used to represent the bit rate or set of 1024 bit rates supported on the interface. This is a one or more digit 1025 �k�, where each �k� represents a particular bit rate. The valid 1026 values for m are (1, 2, 3, 12, 23, 123). 1028 - Index n: The index "n" is used to represent the order of the OTM, 1029 OTS, OMS, OPS, OCG and OMU. This index represents the maximum number 1030 of wavelengths that can be supported at the lowest bit rate 1031 supported on the wavelength. It is possible that a reduced number of 1032 higher bit rate wavelengths are supported. The case n=0 represents a 1033 single channel without a specific wavelength assigned to the 1034 channel. 1036 - Index r: The index "r", if present, is used to indicate a reduced 1037 functionality OTM, OCG, OCC and OCh (non-associated overhead is not 1038 supported). Note that for n=0 the index r is not required as it 1039 implies always reduced functionality. 1041 D.Papadimitriou (Editor) et al. - Expires June 2004 20 1042 Full Copyright Statement 1044 "Copyright (C) The Internet Society (date). All Rights Reserved. 1045 This document and translations of it may be copied and furnished to 1046 others, and derivative works that comment on or otherwise explain it 1047 or assist in its implementation may be prepared, copied, published 1048 and distributed, in whole or in part, without restriction of any 1049 kind, provided that the above copyright notice and this paragraph 1050 are included on all such copies and derivative works. However, this 1051 document itself may not be modified in any way, such as by removing 1052 the copyright notice or references to the Internet Society or other 1053 Internet organizations, except as needed for the purpose of 1054 developing Internet standards in which case the procedures for 1055 copyrights defined in the Internet Standards process must be 1056 followed, or as required to translate it into languages other than 1057 English. 1059 The limited permissions granted above are perpetual and will not be 1060 revoked by the Internet Society or its successors or assigns. 1062 This document and the information contained herein is provided on an 1063 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1064 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1065 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1066 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1067 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1069 D.Papadimitriou (Editor) et al. - Expires June 2004 21