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