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