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