idnits 2.17.1 draft-ietf-ccamp-gmpls-g709-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1105. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1082. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1089. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1095. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1111), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == The page length should not exceed 58 lines per page, but there was 21 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 718 has weird spacing: '... (first part ...' == Line 720 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 2005) is 7040 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) == Missing Reference: 'ITUT-G.709' is mentioned on line 144, but not defined == Unused Reference: 'RFC2026' is defined on line 870, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 873, but no explicit reference was found in the text == Unused Reference: 'RFC3209' is defined on line 883, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 895, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 898, but no explicit reference was found in the text == Unused Reference: 'RFC3945' is defined on line 909, but no explicit reference was found in the text == Unused Reference: 'ITUT-G707' is defined on line 916, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) ** Obsolete normative reference: RFC 3946 (Obsoleted by RFC 4606) Summary: 10 errors (**), 0 flaws (~~), 12 warnings (==), 7 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 Updates RFC 3471 4 Category: Standard Track 5 Expiration Date: June 2005 January 2005 7 Generalized MPLS (GMPLS) Signaling Extensions 8 for G.709 Optical Transport Networks Control 10 draft-ietf-ccamp-gmpls-g709-09.txt 12 Status of this Memo 14 By submitting this Internet-Draft, I certify that any applicable 15 patent or other IPR claims of which I am aware have been disclosed, 16 and any of which I become aware will be disclosed, in accordance 17 with RFC 3668. 19 Working documents of the Internet Engineering Task Force (IETF), its 20 areas, and its working groups. Note that other groups may also 21 distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document is a companion to the Generalized MPLS (GMPLS) 41 signaling documents. It describes the technology specific 42 information needed to extend GMPLS signaling to control Optical 43 Transport Networks (OTN); it also includes the so-called pre-OTN 44 developments. 46 D.Papadimitriou (Editor) et al. - Expires June 2005 1 47 Table of Contents 49 Status of this Memo ............................................. 1 50 Abstract ........................................................ 1 51 Table of Contents ............................................... 2 52 Conventions used in this Document ............................... 2 53 1. Introduction ................................................. 3 54 2. GMPLS Extensions for G.709 - Overview ........................ 3 55 3. Generalized Label Request .................................... 5 56 3.1 Common Part ................................................. 5 57 3.1.1. LSP Encoding Type ........................................ 5 58 3.1.2. Switching-Type ........................................... 6 59 3.1.3. Generalized-PID (G-PID) .................................. 6 60 3.2. G.709 Traffic-Parameters ................................... 7 61 3.2.1. Signal Type (ST).......................................... 8 62 3.2.2. Number of Multiplexed Components (NMC) ................... 9 63 3.2.3. Number of Virtual Components (NVC) ....................... 9 64 3.2.4. Multiplier (MT) .......................................... 9 65 3.2.5. Reserved Fields ......................................... 10 66 4. Generalized Label ........................................... 10 67 4.1. ODUk Label Space .......................................... 10 68 4.2. Label Distribution Rules .................................. 12 69 4.3. OCh Label Space ........................................... 13 70 5. Examples .................................................... 13 71 6. RSVP-TE Signaling Protocol Extensions ....................... 15 72 7. Security Considerations ..................................... 15 73 8. IANA Considerations ......................................... 15 74 9. Acknowledgments ............................................. 16 75 10. References ................................................. 17 76 10.1 Normative References ...................................... 17 77 10.2 Informative References .................................... 17 78 11. Contributors ............................................... 18 79 12. Editor's Address ........................................... 19 80 Appendix 1 - Abbreviations ..................................... 20 81 Appendix 2 - G.709 Indexes ..................................... 20 82 Intellectual Property Statement ................................ 22 83 Disclaimer of Validity ......................................... 22 84 Copyright Statement ............................................ 22 86 Conventions used in this Document 88 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 89 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 90 this document are to be interpreted as described in RFC-2119. 92 In addition, the reader is assumed to be familiar with the 93 terminology used in ITU-T [ITUT-G709] as well as [RFC3471], and 94 [RFC3473]. Abbreviations used in this document are detailed in 95 Appendix 1. 97 D.Papadimitriou (Editor) et al. - Expires June 2005 2 98 1. Introduction 100 Generalized MPLS (GMPLS) extends MPLS from supporting Packet 101 Switching Capable (PSC) interfaces and switching to include 102 support of four new classes of interfaces and switching: Layer-2 103 Switching (L2SC), Time-Division Multiplex (TDM), Lambda Switch 104 (LSC) and Fiber-Switch (FSC) Capable. A functional description of 105 the extensions to MPLS signaling needed to support these new 106 classes of interfaces and switching is provided in [RFC3471]. 107 [RFC3473] describes the RSVP-TE specific formats and mechanisms 108 needed to support all four classes of interfaces. 110 This document presents the technology details that are specific to 111 G.709 Optical Transport Networks (OTN) as specified in the ITU-T 112 G.709 recommendation [ITUT-G709] (and referenced documents), 113 including pre-OTN developments. Per [RFC3471], G.709 technology 114 specific parameters are carried through the signaling protocol in 115 dedicated traffic parameter objects. 117 The G.709 traffic parameters defined hereafter (see Section 3.2) 118 MUST be used when the label is encoded as defined in this 119 document. Moreover, the label MUST be encoded as defined in 120 Section 4 when these G.709 traffic parameters are used. 122 In the context of this memo, by pre-OTN developments, one refers 123 to Optical Channel, Digital Wrapper and Forward Error Correction 124 (FEC) solutions that are not fully G.709 compliant. Details 125 concerning pre-OTN Synchronous Optical Network (SONET)/ 126 Synchronous Digital Hierarchy (SDH) based solutions including 127 Optical Sections (OS), Regenerator Section (RS)/Section and 128 Multiplex Section (MS)/ Line overhead transparency are covered in 129 [RFC3946]. 131 *** Note on ITU-T G.709 Recommendation *** 133 The views on the ITU-T G.709 OTN Recommendation presented in this 134 document are intentionally restricted to the GMPLS perspective 135 within the IETF CCAMP WG context. Hence, the objective of this 136 document is not to replicate the content of the ITU-T OTN 137 recommendations. Therefore, the reader interested in more details 138 concerning the corresponding technologies is strongly invited to 139 consult the corresponding ITU-T documents (also referenced in this 140 memo). 142 2. GMPLS Extensions for G.709 - Overview 144 [ITUT-G.709] defines several networking layers constituting the 145 optical transport hierarchy: 146 - with full functionality: 147 . Optical Transmission Section (OTS) 148 . Optical Multiplex Section (OMS) 149 . Optical Channel (OCh) 150 - with reduced functionality: 152 D.Papadimitriou (Editor) et al. - Expires June 2005 3 153 . Optical Physical Section (OPS) 154 . Optical Channel with reduced functionality (OChr) 156 It also defines two layers constituting the digital transport 157 hierarchy: 158 - Optical Channel Data Unit (OTUk) 159 - Optical Channel Data Unit (ODUk) 161 However, only the OCh and the ODUk layers are defined as switching 162 layers. Both OCh (but not OChr) and ODUk layers include the overhead 163 for supervision and management. The OCh overhead is transported in a 164 non-associated manner (also referred to as the non-associated 165 overhead naOH) in the Optical Transport Module (OTM) Overhead Signal 166 (OOS), together with the OTS and OMS non-associated overhead. The 167 OOS is transported via a dedicated wavelength referred to as the 168 Optical Supervisory Channel (OSC). It should be noticed that the 169 naOH is only functionally specified and as such open to vendor 170 specific solutions. The ODUk overhead is transported in an 171 associated manner as part of the digital ODUk frame. 173 As described in [ITUT-G709], in addition to the support of ODUk 174 mapping into OTUk (k = 1, 2, 3), G.709 supports ODUk multiplexing. 175 It refers to the multiplexing of ODUj (j = 1, 2) into an ODUk (k > 176 j) signal, in particular: 177 - ODU1 into ODU2 multiplexing 178 - ODU1 into ODU3 multiplexing 179 - ODU2 into ODU3 multiplexing 180 - ODU1 and ODU2 into ODU3 multiplexing 182 Adapting GMPLS to control G.709 OTN, can be achieved by creating: 183 - a Digital Path layer by extending the previously defined 184 "Digital Wrapper" in [RFC3471] corresponding to the ODUk 185 (digital) path layer. 186 - an Optical Path layer by extending the "Lambda" concept defined 187 in [RFC3471] to the OCh (optical) path layer. 188 - a label space structure by considering a tree whose root is an 189 OTUk signal and leaves the ODUj signals (k >= j); enabling to 190 identify the exact position of a particular ODUj signal in an 191 ODUk multiplexing structure. 193 Thus, the GMPLS signaling extensions for G.709 need to cover the 194 Generalized Label Request, the Generalized Label as well as the 195 specific technology dependent objects included in the so-called 196 traffic parameters as specified in [RFC3946] for SONET/SDH networks. 197 Moreover, since multiplexing in the digital domain (such as ODUk 198 multiplexing) has been specified in the amended version of the G.709 199 ITU-T recommendation (October 2001), this document also proposes a 200 label space definition suitable for that purpose. Notice also that 201 one uses the G.709 ODUk (i.e. Digital Path) and OCh (i.e. Optical 202 Path) layers directly in order to define the corresponding label 203 spaces. 205 D.Papadimitriou (Editor) et al. - Expires June 2005 4 206 3. Generalized Label Request 208 The Generalized Label Request as defined in [RFC3471], includes a 209 common part (i.e. used for any switching technology) and a 210 technology dependent part (i.e. the traffic parameters). In this 211 section, both parts are extended to accommodate GMPLS Signaling to 212 the G.709 transport plane recommendation (see [ITUT-G709]). 214 3.1 Common Part 216 As defined in [RFC3471], the LSP Encoding Type, the Switching Type 217 and the Generalized Protocol Identifier (Generalized-PID) constitute 218 the common part of the Generalized Label Request. The encoding of 219 the RSVP-TE GENERALIZED_LABEL_REQUEST object is specified in 220 [RFC3473] Section 2.1. 222 As mentioned above, this document extends the LSP Encoding Type, the 223 Switching Type and G-PID (Generalized-PID) values to accommodate 224 G.709 Recommendation [ITUT-G709]. 226 3.1.1 LSP Encoding Type 228 Since G.709 Recommendation defines two networking layers (ODUk 229 layers and OCh layer), the LSP Encoding Type code-points can reflect 230 these two layers defined in [RFC3471] Section 3.1 as "Digital 231 Wrapper" and "Lambda" code. The LSP Encoding Type is specified per 232 networking layer or more precisely per group of functional 233 networking layer: the ODUk layers and the OCh layer. 235 Therefore, an additional LSP Encoding Type code-point for the G.709 236 Digital Path layer is defined that enlarges the existing "Digital 237 Wrapper" code-point defined in [RFC3471]. The former MUST be 238 generated when the interface or tunnel on which the traffic will be 239 transmitted supports G.709 compliant Digital Path layer encoding. 240 The latter MUST only be used for non-G.709 compliant Digital Wrapper 241 layer(s) encoding. A transit or an egress node (receiving a Path 242 message containing a GENERALIZED_LABEL_REQUEST object) MUST generate 243 a PathErr message, with a "Routing problem/Unsupported Encoding" 244 indication, if the requested LSP Encoding Type cannot be supported 245 on the corresponding incoming interface. 247 In the same way, an additional LSP Encoding Type code-point for the 248 G.709 Optical Channel layer is defined that enlarges the existing 249 "Lambda" code-point defined in [RFC3471]. The former MUST be 250 generated when the interface or tunnel on which the traffic will be 251 transmitted supports G.709 compliant Optical Channel layer encoding. 252 The latter MUST only be used for non-G.709 compliant Lambda layer(s) 253 encoding. A transit or an egress node (receiving a Path message 254 containing a GENERALIZED_LABEL_REQUEST object) MUST generate a 255 PathErr message, with a "Routing problem/Unsupported Encoding" 256 indication, if the requested LSP Encoding Type cannot be supported 257 on the corresponding incoming interface. 259 D.Papadimitriou (Editor) et al. - Expires June 2005 5 260 Consequently, the following additional code-points for the LSP 261 Encoding Type are defined: 263 Value Type 264 ----- ---- 265 12 G.709 ODUk (Digital Path) 266 13 G.709 Optical Channel 268 Moreover, the code-point for the G.709 Optical Channel (OCh) layer 269 will indicate the requested capability of an end-system to use the 270 G.709 non-associated overhead (naOH) i.e. the OTM Overhead Signal 271 (OOS) multiplexed into the OTM-n.m interface signal. 273 3.1.2 Switching Type 275 The Switching Type indicates the type of switching that should be 276 performed at the termination of a particular link (see [GMPLS-RTG]). 278 No additional Switching Type values are to be considered in order to 279 accommodate G.709 switching types since an ODUk switching (and so 280 LSPs) belongs to the TDM class while an OCh switching (and so LSPs) 281 to the Lambda class (i.e. LSC). 283 Intermediate and egress nodes MUST verify that the value indicated 284 in the Switching Type field is supported on the corresponding 285 incoming interface. If the requested value can not be supported, the 286 node MUST generate a PathErr message with a "Routing problem/ 287 Switching Type" indication. 289 3.1.3 Generalized-PID (G-PID) 291 The G-PID (16 bits field) as defined in [RFC3471], identifies the 292 payload carried by an LSP, i.e. an identifier of the client layer of 293 that LSP. This identifier is used by the endpoints of the G.709 LSP. 295 The G-PID can take one of the following values when the client 296 payload is transported over the Digital Path layer, in addition to 297 the payload identifiers defined in [RFC3471]: 299 - CBRa: asynchronous Constant Bit Rate i.e. mapping of STM-16/OC- 300 48, STM-64/OC-192 and STM-256/OC-768 301 - CBRb: bit synchronous Constant Bit Rate i.e. mapping of STM- 302 16/OC-48, STM-64/OC-192 and STM-256/OC-768 303 - ATM: mapping at 2.5, 10 and 40 Gbps 304 - BSOT: non-specific client Bit Stream with Octet Timing i.e. 305 Mapping of 2.5, 10 and 40 Gbps Bit Stream 306 - BSNT: non-specific client Bit Stream without Octet Timing i.e. 307 Mapping of 2.5, 10 and 40 Gbps Bit Stream 308 - ODUk: transport of Digital Paths at 2.5, 10 and 40 Gbps 309 - ESCON: Enterprise Systems Connection 310 - FICON: Fiber Connection 312 D.Papadimitriou (Editor) et al. - Expires June 2005 6 313 The G-PID can take one of the following values when the client 314 payload is transported over the Optical Channel layer, in addition 315 to the payload identifiers defined in [RFC3471]: 316 - CBR: Constant Bit Rate i.e. mapping of STM-16/OC-48, STM-64/OC-192 317 and STM-256/OC-768 318 - OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps 320 Also, when client payloads such as Ethernet MAC/PHY and IP/PPP are 321 encapsulated through the Generic Framing Procedure (GFP) as 322 described in ITU-T G.7041, dedicated G-PID values are defined. 324 In order to include pre-OTN developments, the G-PID field can take 325 one of the values (currently defined in [RFC3471]) when the 326 following client payloads are transported over a so-called lambda 327 LSP: 328 - Ethernet PHY (1 Gbps and 10 Gbps) 329 - Fiber Channel 331 The following table summarizes the G-PID with respect to the LSP 332 Encoding Type: 334 Value G-PID Type LSP Encoding Type 335 ----- ---------- ----------------- 336 47 G.709 ODUj G.709 ODUk (with k > j) 337 48 G.709 OTUk(v) G.709 OCh 338 ODUk mapped into OTUk(v) 339 49 CBR/CBRa G.709 ODUk, G.709 OCh 340 50 CBRb G.709 ODUk 341 51 BSOT G.709 ODUk 342 52 BSNT G.709 ODUk 343 53 IP/PPP (GFP) G.709 ODUk (and SDH) 344 54 Ethernet MAC (framed GFP) G.709 ODUk (and SDH) 345 55 Ethernet PHY (transparent GFP) G.709 ODUk (and SDH) 346 56 ESCON G.709 ODUk, Lambda, Fiber 347 57 FICON G.709 ODUk, Lambda, Fiber 348 58 Fiber Channel G.709 ODUk, Lambda, Fiber 350 Note: Values 49 and 50 include mapping of SDH. 352 The following table summarizes the update of the G-PID values 353 defined in [RFC3471]: 355 Value G-PID Type LSP Encoding Type 356 ----- ---------- ----------------- 357 32 ATM Mapping SDH, G.709 ODUk 358 33 Ethernet PHY SDH, G.709 OCh, Lambda, Fiber 359 34 Sonet/SDH G.709 OCh, Lambda, Fiber 360 35 Reserved (SONET Dep.) G.709 OCh, Lambda, Fiber 362 3.2 G.709 Traffic Parameters 364 When G.709 Digital Path Layer or G.709 Optical Channel Layer is 365 specified in the LSP Encoding Type field, the information referred 367 D.Papadimitriou (Editor) et al. - Expires June 2005 7 368 to as technology dependent (or simply traffic parameters) is carried 369 additionally to the one included in the Generalized Label Request. 371 The G.709 traffic parameters are defined as follows: 373 0 1 2 3 374 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 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | Signal Type | Reserved | NMC | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | NVC | Multiplier (MT) | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Reserved | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 In this frame, NMC stands for Number of Multiplexed Components, NVC 384 for Number of Virtual Components and MT for Multiplier. Each of 385 these fields is tailored to support G.709 LSP requests. 387 The RSVP-TE encoding of the G.709 traffic-parameters is detailed in 388 Section 6. 390 3.2.1 Signal Type (ST) 392 This field (8 bits) indicates the type of G.709 Elementary Signal 393 that comprises the requested LSP. The permitted values are: 395 Value Type 396 ----- ---- 397 0 Not significant 398 1 ODU1 (i.e. 2.5 Gbps) 399 2 ODU2 (i.e. 10 Gbps) 400 3 ODU3 (i.e. 40 Gbps) 401 4 Reserved (for future use) 402 5 Reserved (for future use) 403 6 OCh at 2.5 Gbps 404 7 OCh at 10 Gbps 405 8 OCh at 40 Gbps 406 9-255 Reserved (for future use) 408 The value of the Signal Type field depends on LSP Encoding Type 409 value defined in Section 3.1.1 and [RFC3471]: 410 - if the LSP Encoding Type value is the G.709 Digital Path layer 411 then the valid values are the ODUk signals (k = 1, 2 or 3) 412 - if the LSP Encoding Type value is the G.709 Optical Channel layer 413 then the valid values are the OCh at 2.5, 10 or 40 Gbps 414 - if the LSP Encoding Type is "Lambda" (which includes the 415 pre-OTN Optical Channel layer) then the valid value is irrelevant 416 (Signal Type = 0) 417 - if the LSP Encoding Type is "Digital Wrapper", then the valid 418 value is irrelevant (Signal Type = 0) 420 D.Papadimitriou (Editor) et al. - Expires June 2005 8 421 Several transforms can be sequentially applied on the Elementary 422 Signal to build the Final Signal being actually requested for the 423 LSP. Each transform application is optional and must be ignored if 424 zero, except the Multiplier (MT) that cannot be zero and must be 425 ignored if equal to one. Transforms must be applied strictly in the 426 following order: 427 - First, virtual concatenation (by using the NVC field) can 428 be optionally applied directly on the Elementary Signal to form a 429 Composed Signal 430 - Second, a multiplication (by using the Multiplier field) can be 431 optionally applied either directly on the Elementary Signal, or 432 on the virtually concatenated signal obtained from the first 433 phase. The resulting signal is referred to as Final Signal. 435 3.2.2 Number of Multiplexed Components (NMC) 437 The NMC field (16 bits) indicates the number of ODU tributary slots 438 used by an ODUj when multiplexed into an ODUk (k > j) for the 439 requested LSP. This field is not applicable when an ODUk is mapped 440 into an OTUk and irrelevant at the Optical Channel layer. In both 441 cases, it MUST be set to zero (NMC = 0) when sent and should be 442 ignored when received. 444 When applied at the Digital Path layer, in particular for ODU2 445 connections multiplexed into one ODU3 payload, the NMC field 446 specifies the number of individual tributary slots (NMC = 4) 447 constituting the requested connection. These components are still 448 processed within the context of a single connection entity. For all 449 other currently defined multiplexing cases (see Section 2), the NMC 450 field is set to 1. 452 3.2.3 Number of Virtual Components (NVC) 454 The NVC field (16 bits) is dedicated to ODUk virtual concatenation 455 (i.e. ODUk Inverse Multiplexing) purposes. It indicates the number 456 of ODU1, ODU2 or ODU3 Elementary Signals that are requested to be 457 virtually concatenated to form an ODUk-Xv signal. By definition, 458 these signals MUST be of the same type. 460 This field is set to 0 (default value) to indicate that no virtual 461 concatenation is requested. 463 Note that the current usage of this field only applies for G.709 464 ODUk LSPs i.e. values greater than zero, are only acceptable for 465 ODUk Signal Types. Therefore, it MUST be set to zero (NVC = 0), and 466 should be ignored when received, when a G.709 OCh LSP is requested. 468 3.2.4 Multiplier (MT) 470 The Multiplier field (16 bits) indicates the number of identical 471 Elementary Signals or Composed Signals requested for the LSP i.e. 472 that form the Final Signal. A Composed Signal is the resulting 473 signal from the application of the NMC and NVC fields to an 475 D.Papadimitriou (Editor) et al. - Expires June 2005 9 476 elementary Signal Type. GMPLS signaling currently implies that all 477 the Composed Signals must be part of the same LSP. 479 This field is set to one (default value) to indicate that exactly 480 one instance of a signal is being requested. Intermediate and egress 481 nodes MUST verify that the node itself and the interfaces on which 482 the LSP will be established can support the requested multiplier 483 value. If the requested values can not be supported, the receiver 484 node MUST generate a PathErr message (see Section 6). 486 Zero is an invalid value for the MT field. If received, the node 487 MUST generate a PathErr message (see Section 6). 489 3.2.5 Reserved Fields 491 The reserved fields (8 bits in row 1 and 32 bits in row 3) are 492 dedicated for future use. Reserved bits SHOULD be set to zero when 493 sent and MUST be ignored when received. 495 4. Generalized Label 497 This section describes the Generalized Label value space for Digital 498 Paths and Optical Channels. The Generalized Label is defined in 499 [RFC3471]. The format of the corresponding RSVP-TE GENERALIZED_LABEL 500 object is specified in [RFC3473] Section 2.2. 502 The label distribution rules detailed in Section 4.2 follow (when 503 applicable) the ones defined in [RFC3946]. 505 4.1 ODUk Label Space 507 At the Digital Path layer (i.e. ODUk layers), G.709 defines three 508 different client payload bit rates. An Optical Data Unit (ODU) frame 509 has been defined for each of these bit rates. ODUk refers to the 510 frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps) or 511 3 (for 40 Gbps). 513 In addition to the support of ODUk mapping into OTUk, the G.709 514 label space supports the sub-levels of ODUk multiplexing. ODUk 515 multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk 516 (k > j), in particular: 517 - ODU1 into ODU2 multiplexing 518 - ODU1 into ODU3 multiplexing 519 - ODU2 into ODU3 multiplexing 520 - ODU1 and ODU2 into ODU3 multiplexing 522 More precisely, ODUj into ODUk multiplexing (k > j) is defined when 523 an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an 524 ODTUG constituted by ODU tributary slots) which is mapped into an 525 OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is 526 mapped into an OTUk. 528 D.Papadimitriou (Editor) et al. - Expires June 2005 10 529 Therefore, the label space structure is a tree whose root is an OTUk 530 signal and leaves the ODUj signals (k >= j) that can be transported 531 via the tributary slots and switched between these slots. A G.709 532 Digital Path layer label identifies the exact position of a 533 particular ODUj signal in an ODUk multiplexing structure. 535 The G.709 Digital Path Layer label or ODUk label has the following 536 format: 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 | Reserved | t3 | t2 |t1| 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 Reserved bits MUST be set to zero when sent and SHOULD be ignored 545 when received. 547 The specification of the fields t1, t2 and t3 self-consistently 548 characterizes the ODUk label space. The value space for the t1, t2 549 and t3 fields is defined as follows: 551 1. t1 (1-bit): 552 - t1=1 indicates an ODU1 signal. 553 - t1 is not significant for the other ODUk signal types (i.e. 554 t1 value MUST be set to 0 and ignored). 556 2. t2 (3-bit): 557 - t2=1 indicates an ODU2 signal that is not further sub- 558 divided. 559 - t2=[2..5] indicates the tributary slot (t2th-2) used by the 560 ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2). 561 - t2 is not significant for an ODU3 (i.e. t2 value MUST be 562 set to 0 and ignored). 564 3. t3 (6-bit): 565 - t3=1 indicates an ODU3 signal that is not further sub- 566 divided. 567 - t3=[2..17] indicates the tributary slot (t3th-1) used by the 568 ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3). 569 - t3=[18..33] indicates the tributary slot (t3th-17) used by 570 the ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3). 572 Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required 573 to identify the 4 tributary slots used by the ODU2; these tributary 574 time slots have to be allocated in ascending order. 576 If the label sub-field value t[i]=1 (i, j = 1, 2 or 3) and t[j]=0 (j 577 > i), the corresponding ODUk signal ODU[i] is directly mapped into 578 the corresponding OTUk signal (k=i). This is referred to as the 579 mapping of an ODUk signal into an OTUk of the same order. Therefore, 580 the numbering starts at 1; zero is used to indicate a non- 581 significant field. A label field equal to zero is an invalid value. 583 D.Papadimitriou (Editor) et al. - Expires June 2005 11 584 Examples: 586 - t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1 587 - t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2 588 - t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3 589 - t3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot 590 of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2 591 - t3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot 592 of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3 594 4.2 Label Distribution Rules 596 In case of ODUk in OTUk mapping, only one label can appear in the 597 Generalized Label. The unique label is encoded as a single 32 bit 598 label value (as defined in Section 4.1) of the GENERALIZED_LABEL 599 object (Class-Num = 16, C-Type = 2) 601 In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered 602 list of the labels in the multiplex is given (this list can be 603 restricted to only one label when NMC = 1). Each label indicates a 604 component (ODUj tributary slot) of the multiplexed signal. The order 605 of the labels must reflect the order of the ODUj into the multiplex 606 (not the physical order of tributary slots). This ordered list of 607 labels is encoded as a sequence of 32 bit label values (as defined 608 in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C- 609 Type = 2). 611 In case of ODUk virtual concatenation, the explicit ordered list of 612 all labels in the concatenation is given. Each label indicates a 613 component of the virtually concatenated signal. The order of the 614 labels must reflect the order of the ODUk to concatenate (not the 615 physical order of time-slots). This representation limits virtual 616 concatenation to remain within a single (component) link. In case of 617 multiplexed virtually concatenated signals, the first set of labels 618 indicates the components (ODUj tributary slots) of the first 619 virtually concatenated signal, the second set of labels indicates 620 the components (ODUj tributary slots) of the second virtually 621 concatenated signal, and so on. This ordered list of labels is 622 encoded as a sequence of 32 bit label values (as defined in Section 623 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2). 624 In case of ODUk virtual concatenation, the number of label values is 625 determined by the NVC value. Multiplexed ODUk virtual concatenation 626 additionally uses the NMC value to determine the number of labels 627 per set (equal in size). 629 In case of multiplication (i.e. when using the MT field), the 630 explicit ordered list of all labels taking part in the composed 631 signal is given. The above representation limits multiplication to 632 remain within a single (component) link. In case of multiplication 633 of multiplexed virtually concatenated signals, the first set of 634 labels indicates the components of the first multiplexed virtually 635 concatenated signal, the second set of labels indicates components 637 D.Papadimitriou (Editor) et al. - Expires June 2005 12 638 of the second multiplexed virtually concatenated signal, and so on. 639 This ordered list of labels is encoded as a sequence of 32 bit label 640 values (as defined in Section 4.1) of the GENERALIZED_LABEL object 641 (Class-Num = 16, C-Type = 2). In case of multiplication of (equal) 642 ODUk virtual concatenated signals, the number of label values per 643 signal is determined by the NVC value. Multiplication of multiplexed 644 (equal) ODUk virtual concatenation additionally uses the NMC value 645 to determine the number of labels per set (equal in size). 647 4.3 Optical Channel Label Space 649 At the Optical Channel layer, the label space must be consistently 650 defined as a flat space whose values reflect the local assignment of 651 OCh identifiers corresponding to the OTM-n.m sub-interface signals 652 (m = 1, 2 or 3). Note that these identifiers do not cover OChr since 653 the corresponding Connection Function (OChr-CF) between OTM- 654 nr.m/OTM-0r.m is not defined in [ITUT-G798]. 656 The OCh label space values are defined by either absolute values 657 (i.e. channel identifiers or Channel ID also referred to as 658 wavelength identifiers) or relative values (channel spacing also 659 referred to as inter-wavelength spacing). The latter is strictly 660 confined to a per-port label space while the former could be defined 661 as a local or a global (per node) label space. Such an OCh label 662 space is applicable to both OTN Optical Channel layer and pre-OTN 663 Optical Channel layer. 665 Optical Channel label encoding (and distribution) rules are defined 666 in [RFC3471]. They MUST be used for the Upstream Label, the 667 Suggested Label and the Generalized Label. 669 5. Examples 671 The following examples are given in order to illustrate the 672 processing described in the previous sections of this document. 674 1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is 675 directly transported in an OTU1 (OTU2 or OTU3), the upstream node 676 requests results simply in an ODU1 (ODU2 or ODU3) signal request. 678 In such conditions, the downstream node has to return a unique 679 label since the ODU1 (ODU2 or ODU3) is directly mapped into the 680 corresponding OTU1 (OTU2 or OTU3). Since a single ODUk signal is 681 requested (Signal Type = 1, 2 or 3), the downstream node has to 682 return a single ODUk label which can be for instance one of the 683 following when the Signal Type = 1: 685 - t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1 686 - t3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2 687 - t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3 689 2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed 691 D.Papadimitriou (Editor) et al. - Expires June 2005 13 692 into the payload of a structured ODU2 (or ODU3), the upstream 693 node requests results simply in a ODU1 signal request. 695 In such conditions, the downstream node has to return a unique 696 label since the ODU1 is multiplexed into one ODTUG2 (or ODTUG3). 697 The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or 698 OPU3) and then mapped into the corresponding OTU2 (or OTU3). 699 Since a single ODU1 multiplexed signal is requested (Signal Type 700 = 1 and NMC = 1), the downstream node has to return a single ODU1 701 label which can take for instance one of the following values: 703 - t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2 704 - t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3 705 - t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3 707 3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is 708 multiplexed into the payload of a structured ODU3, the upstream 709 node requests results simply in a ODU2 signal request. 711 In such conditions, the downstream node has to return four labels 712 since the ODU2 is multiplexed into one ODTUG3. The latter is 713 mapped into an ODU3 (via OPU3) and then mapped into an OTU3. 714 Since an ODU2 multiplexed signal is requested (Signal Type = 2, 715 and NMC = 4), the downstream node has to return four ODU labels 716 which can take for instance the following values: 718 - t3=18, t2=0, t1=0 (first part of ODU2 in first TS of ODTUG3) 719 - t3=22, t2=0, t1=0 (second part of ODU2 in fifth TS of ODTUG3) 720 - t3=23, t2=0, t1=0 (third part of ODU2 in sixth TS of ODTUG3) 721 - t3=26, t2=0, t1=0 (fourth part of ODU2 in ninth TS of ODTUG3) 723 4. When a single OCh signal of 40 Gbps is requested (Signal Type = 724 8), the downstream node must return a single wavelength 725 label as specified in [RFC3471]. 727 5. When requesting multiple ODUk LSP (i.e. with a multiplier (MT) 728 value > 1), an explicit list of labels is returned to the 729 requestor node. 731 When the downstream node receives a request for a 4 x ODU1 signal 732 (Signal Type = 1, NMC = 1 and MT = 4) multiplexed into a ODU3, it 733 returns an ordered list of four labels to the upstream node: the 734 first ODU1 label corresponding to the first signal of the LSP, 735 the second ODU1 label corresponding to the second signal of the 736 LSP, etc. For instance, the corresponding labels can take the 737 following values: 739 - First ODU1: t3=2, t2=0, t1=0 (in first TS of ODTUG3) 740 - Second ODU1: t3=10, t2=0, t1=0 (in ninth TS of ODTUG3) 741 - Third ODU1: t3=7, t2=0, t1=0 (in sixth TS of ODTUG3) 742 - Fourth ODU1: t3=6, t2=0, t1=0 (in fifth TS of ODTUG3) 744 D.Papadimitriou (Editor) et al. - Expires June 2005 14 745 6. RSVP-TE Signaling Protocol Extensions 747 This section specifies the [RFC3473] protocol extensions needed to 748 accommodate G.709 traffic parameters. 750 The G.709 traffic parameters are carried in the G.709 SENDER_TSPEC 751 and FLOWSPEC objects. The same format is used both for 752 SENDER_TSPEC object and FLOWSPEC objects. The content of the 753 objects is defined above in Section 3.2. The objects have the 754 following class and type for G.709: 755 - G.709 SENDER_TSPEC Object: Class = 12, C-Type = TBA 756 - G.709 FLOWSPEC Object: Class = 9, C-Type = TBA 758 There is no Adspec associated with the SONET/SDH SENDER_TSPEC. 759 Either the Adspec is omitted or an Int-serv Adspec with the 760 Default General Characterization Parameters and Guaranteed Service 761 fragment is used, see [RFC2210]. 763 For a particular sender in a session the contents of the FLOWSPEC 764 object received in a Resv message SHOULD be identical to the 765 contents of the SENDER_TSPEC object received in the corresponding 766 Path message. If the objects do not match, a ResvErr message with 767 a "Traffic Control Error/Bad Flowspec value" error SHOULD be 768 generated. 770 Intermediate and egress nodes MUST verify that the node itself and 771 the interfaces on which the LSP will be established can support 772 the requested Signal Type, NMC and NVC values (as defined in 773 Section 3.2). If the requested value(s) can not be supported, the 774 receiver node MUST generate a PathErr message with a "Traffic 775 Control Error/Service unsupported" indication (see [RFC2205]). 777 In addition, if the MT field is received with a zero value, the 778 node MUST generate a PathErr message with a "Traffic Control 779 Error/Bad Tspec value" indication (see [RFC2205]). 781 7. Security Considerations 783 This draft introduces no new security considerations to [RFC3473]. 785 8. IANA Considerations 787 Two values have to be defined by IANA for this document: 789 Two RSVP C-Types in registry: 791 http://www.iana.org/assignments/rsvp-parameters 793 - A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5 794 (Suggested value, TBA) - see Section 6. 796 - A G.709 FLOWSPEC object: Class = 9, C-Type = 5 797 (Suggested value, TBA) - see Section 6. 799 D.Papadimitriou (Editor) et al. - Expires June 2005 15 800 IANA is also requested to track the code-point spaces extended 801 and/or updated by this document. For this purpose, the following 802 new registry entries are requested in the newly requested registry 803 entry: http://www.iana.org/assignments/gmpls 805 - LSP Encoding Type: 806 http://www.iana.org/assignments/gmpls/lsp-encoding-type 807 Name: LSP Encoding Type 808 Format: 8-bit number 809 Values: 810 [1..11] defined in [RFC3471] 811 12 defined in Section 3.1.1 812 13 defined in Section 3.1.1 813 Allocation Policy: 814 [0..239] Assigned by IANA via IETF Standards Track RFC 815 Action. 816 [240..255] Assigned temporarily for Experimental Usage. 817 these will not be registered with IANA 819 - Switching Type: 820 http://www.iana.org/assignments/gmpls/switching-type 821 Name: Switching Type 822 Format: 8-bit number 823 Values: defined in [RFC3471] 824 Allocation Policy: 825 [0..255] Assigned by IANA via IETF Standards Track RFC 826 Action. 828 - Generalized PID (G-PID): 829 http://www.iana.org/assignments/gmpls/generalized-pid 830 Name: G-PID 831 Format: 16-bit number 832 Values: 833 [0..31] defined in [RFC3471] 834 [32..35] defined in [RFC3471] and updated by Section 835 3.1.3 836 [36..46] defined in [RFC3471] 837 [47..58] defined in Section 3.1.3 838 Allocation Policy: 839 [0..31743] Assigned by IANA via IETF Standards Track RFC 840 Action. 841 [31744..32767] Assigned temporarily for Experimental Usage 842 [32768..65535] Not assigned. Before any assignments can be 843 made in this range, there MUST be a Standards 844 Track RFC that specifies IANA Considerations 845 that covers the range being assigned. 847 9. Acknowledgments 849 The authors would like to thank Jean-Loup Ferrant, Mathieu Garnot, 850 Massimo Canali, Germano Gasparini and Fong Liaw for their 851 constructive comments and inputs as well as James Fu, Siva 853 D.Papadimitriou (Editor) et al. - Expires June 2005 16 854 Sankaranarayanan and Yangguang Xu for their useful feedback. Many 855 thanks to Adrian Farrel for having thoroughly reviewing this 856 document. 858 This draft incorporates (upon agreement) material and ideas from 859 draft-lin-ccamp-ipo-common-label-request-00.txt. 861 10. References 863 10.1 Normative References 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-09.txt, 868 October 2003. 870 [RFC2026] Bradner, S., "The Internet Standards Process -- 871 Revision 3," BCP 9, RFC 2026, October 1996. 873 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 874 Requirement Levels," BCP 14, RFC 2119, March 1997. 876 [RFC2205] Braden, R., et al., "Resource ReSerVation Protocol 877 (RSVP) -- Version 1 Functional Specification," RFC 878 2205, September 1997. 880 [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated 881 Services," RFC 2210, September 1997. 883 [RFC3209] Awduche, D. et al., "RSVP-TE: Extensions to RSVP for LSP 884 Tunnels," RFC 3209, December 2001. 886 [RFC3471] Berger, L. (Editor) et al., "Generalized Multi- 887 Protocol Label Switching (GMPLS) Signaling - 888 Functional Description," RFC 3471, January 2003. 890 [RFC3473] Berger, L. (Editor) et al., "Generalized Multi- 891 Protocol Label Switching (GMPLS) Signaling Resource 892 ReserVation Protocol-Traffic Engineering (RSVP-TE) 893 Extensions," RFC 3473, January 2003. 895 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, 896 RFC 3667, February 2004. 898 [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF 899 Technology", BCP 79, RFC 3668, February 2004. 901 [RFC3946] Mannie, E. and Papadimitriou, D. (Editors) et al., 902 "Generalized Multiprotocol Label Switching Extensions 903 for SONET and SDH Control," RFC 3946, October 2004. 905 10.2 Informative References 907 D.Papadimitriou (Editor) et al. - Expires June 2005 17 909 [RFC3945] Mannie, E. (Editor) et al., "Generalized Multi-Protocol 910 Label Switching (GMPLS) Architecture," RFC 3945, 911 October 2004. 913 For information on the availability of the following documents, 914 please see http://www.itu.int 916 [ITUT-G707] ITU-T, "Network node interface for the synchronous 917 digital hierarchy (SDH)," G.707 Recommendation, October 918 2000. 920 [ITUT-G709] ITU-T, "Interface for the Optical Transport Network 921 (OTN)," G.709 Recommendation (and Amendment 1), 922 February 2001 (October 2001). 924 [ITUT-G798] ITU-T, "Characteristics of Optical Transport Network 925 Hierarchy Equipment Functional Blocks," G.798 926 Recommendation, October 2001. 928 11. Contributors 930 Alberto Bellato (Alcatel) 931 Via Trento 30, 932 I-20059 Vimercate, Italy 933 Email: alberto.bellato@alcatel.it 935 Sudheer Dharanikota (Consult) 936 Email: sudheer@ieee.org 938 Michele Fontana (Alcatel) 939 Via Trento 30, 940 I-20059 Vimercate, Italy 941 Email: michele.fontana@alcatel.it 943 Nasir Ghani (Sorrento Networks) 944 9990 Mesa Rim Road, 945 San Diego, CA 92121, USA 946 Email: nghani@sorrentonet.com 948 Gert Grammel (Alcatel) 949 Lorenzstrasse, 10, 950 70435 Stuttgart, Germany 951 Email: gert.grammel@alcatel.de 953 Dan Guo (Turin Networks) 954 1415 N. McDowell Blvd, 955 Petaluma, CA 94954, USA 956 Email: dguo@turinnetworks.com 958 Juergen Heiles (Siemens) 959 Hofmannstr. 51, 960 D-81379 Munich, Germany 961 Email: juergen.heiles@siemens.com 963 D.Papadimitriou (Editor) et al. - Expires June 2005 18 964 Jim Jones (Alcatel) 965 3400 W. Plano Parkway, 966 Plano, TX 75075, USA 967 Email: jim.d.jones@alcatel.com 969 Zhi-Wei Lin (Lucent) 970 101 Crawfords Corner Rd, Rm 3C-512 971 Holmdel, New Jersey 07733-3030, USA 972 Email: zwlin@lucent.com 974 Eric Mannie (Consult) 975 Email: eric_mannie@hotmail.com 977 Maarten Vissers (Alcatel) 978 Lorenzstrasse, 10, 979 70435 Stuttgart, Germany 980 Email: maarten.vissers@alcalel.de 982 Yong Xue (WorldCom) 983 22001 Loudoun County Parkway, 984 Ashburn, VA 20147, USA 985 Email: yong.xue@wcom.com 987 12. Editor's Address 989 Dimitri Papadimitriou (Alcatel) 990 Francis Wellesplein 1, 991 B-2018 Antwerpen, Belgium 992 Phone: +32 3 240-8491 993 Email: dimitri.papadimitriou@alcatel.be 995 D.Papadimitriou (Editor) et al. - Expires June 2005 19 996 Appendix 1 - Abbreviations 998 BSNT Bit Stream without Octet Timing 999 BSOT Bit Stream with Octet Timing 1000 CBR Constant Bit Rate 1001 ESCON Enterprise Systems Connection 1002 FC Fiber Channel 1003 FEC Forward Error Correction 1004 FICON Fiber Connection 1005 FSC Fiber Switch Capable 1006 GCC General Communication Channel 1007 GFP Generic Framing Procedure 1008 LSC Lambda Switch Capable 1009 LSP Label Switched Path 1010 MS Multiplex Section 1011 naOH non-associated Overhead 1012 NMC Number of Multiplexed Components 1013 NVC Number of Virtual Components 1014 OCC Optical Channel Carrier 1015 OCG Optical Carrier Group 1016 OCh Optical Channel (with full functionality) 1017 OChr Optical Channel (with reduced functionality) 1018 ODTUG Optical Date Tributary Unit Group 1019 ODU Optical Channel Data Unit 1020 OH Overhead 1021 OMS Optical Multiplex Section 1022 OMU Optical Multiplex Unit 1023 OOS OTM Overhead Signal 1024 OPS Optical Physical Section 1025 OPU Optical Channel Payload Unit 1026 OSC Optical Supervisory Channel 1027 OTH Optical Transport Hierarchy 1028 OTM Optical Transport Module 1029 OTN Optical Transport Network 1030 OTS Optical Transmission Section 1031 OTU Optical Channel Transport Unit 1032 OTUkV Functionally Standardized OTUk 1033 PPP Point to Point Protocol 1034 PSC Packet Switch Capable 1035 RES Reserved 1036 RS Regenerator Section 1037 TTI Trail Trace Identifier 1038 TDM Time Division Multiplex 1040 Appendix 2 - G.709 Indexes 1042 - Index k: The index "k" is used to represent a supported bit rate 1043 and the different versions of OPUk, ODUk and OTUk. k=1 represents an 1044 approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate 1045 bit rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s 1046 and k = 4 an approximate bit rate of 160 Gbit/s (under definition). 1047 The exact bit-rate values are in kbits/s: 1048 . OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322 1050 D.Papadimitriou (Editor) et al. - Expires June 2005 20 1051 . ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983 1052 . OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559 1054 - Index m: The index "m" is used to represent the bit rate or set of 1055 bit rates supported on the interface. This is a one or more digit 1056 "k", where each "k" represents a particular bit rate. The valid 1057 values for m are (1, 2, 3, 12, 23, 123). 1059 - Index n: The index "n" is used to represent the order of the OTM, 1060 OTS, OMS, OPS, OCG and OMU. This index represents the maximum number 1061 of wavelengths that can be supported at the lowest bit rate 1062 supported on the wavelength. It is possible that a reduced number of 1063 higher bit rate wavelengths are supported. The case n=0 represents a 1064 single channel without a specific wavelength assigned to the 1065 channel. 1067 - Index r: The index "r", if present, is used to indicate a reduced 1068 functionality OTM, OCG, OCC and OCh (non-associated overhead is not 1069 supported). Note that for n=0 the index r is not required as it 1070 implies always reduced functionality. 1072 D.Papadimitriou (Editor) et al. - Expires June 2005 21 1073 Intellectual Property Statement 1075 The IETF takes no position regarding the validity or scope of any 1076 Intellectual Property Rights or other rights that might be claimed 1077 to pertain to the implementation or use of the technology described 1078 in this document or the extent to which any license under such 1079 rights might or might not be available; nor does it represent that 1080 it has made any independent effort to identify any such rights. 1081 Information on the procedures with respect to rights in RFC 1082 documents can be found in BCP 78 and BCP 79. 1084 Copies of IPR disclosures made to the IETF Secretariat and any 1085 assurances of licenses to be made available, or the result of an 1086 attempt made to obtain a general license or permission for the use 1087 of such proprietary rights by implementers or users of this 1088 specification can be obtained from the IETF on-line IPR repository 1089 at http://www.ietf.org/ipr. 1091 The IETF invites any interested party to bring to its attention any 1092 copyrights, patents or patent applications, or other proprietary 1093 rights that may cover technology that may be required to implement 1094 this standard. Please address the information to the IETF at 1095 ietf-ipr@ietf.org. 1097 Disclaimer of Validity 1099 This document and the information contained herein are provided on 1100 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1101 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1102 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1103 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1104 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1105 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1107 Copyright Statement 1109 Copyright (C) The Internet Society (2004). This document is subject 1110 to the rights, licenses and restrictions contained in BCP 78, and 1111 except as set forth therein, the authors retain all their rights. 1113 Acknowledgment 1115 Funding for the RFC Editor function is currently provided by the 1116 Internet Society. 1118 D.Papadimitriou (Editor) et al. - Expires June 2005 22