idnits 2.17.1 draft-ietf-ccamp-gmpls-g709-00.txt: -(110): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(132): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(677): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(686): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(701): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(708): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(723): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(895): 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 57 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 18 longer pages, the longest (page 3) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([GMPLS-LDP], [ITUT-G709], [GMPLS-RSVP], [GMPLS-SIG]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 601 has weird spacing: '... (first part ...' == Line 603 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 (March 2002) is 8078 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 96, but not defined == Missing Reference: 'ITUT-G.709' is mentioned on line 119, but not defined == Missing Reference: 'GMPSL-SIG' is mentioned on line 550, but not defined == Missing Reference: 'RFC2210' is mentioned on line 645, but not defined == Unused Reference: 'ITUT-G707' is defined on line 677, but no explicit reference was found in the text == Unused Reference: 'ITUT-G872' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'ITUT-GASTN' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'GMPLS-ARCH' is defined on line 696, but no explicit reference was found in the text == Unused Reference: 'G709-FRM' is defined on line 732, but no explicit reference was found in the text == Unused Reference: 'RFC-2210' is defined on line 737, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G707' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G709' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G798' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G872' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-GASTN' == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-02 -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-LDP' == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-06 == Outdated reference: A later version (-09) exists of draft-ietf-ccamp-gmpls-routing-02 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-07 == Outdated reference: A later version (-08) exists of draft-ietf-ccamp-gmpls-sonet-sdh-03 == Outdated reference: A later version (-03) exists of draft-ietf-ccamp-gmpls-sonet-sdh-extensions-01 ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-gmpls-sonet-sdh-extensions (ref. 'GMPLS-SSS-EXT') -- Possible downref: Normative reference to a draft: ref. 'G709-FRM' Summary: 8 errors (**), 0 flaws (~~), 21 warnings (==), 11 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: September 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 March 2002 19 GMPLS Signalling Extensions 20 for G.709 Optical Transport Networks Control 22 draft-ietf-ccamp-gmpls-g709-00.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 September 2002 1 51 Abstract 53 This document is a companion to the Generalized MPLS (GMPLS) 54 signalling documents [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It 55 describes the G.709 [ITUT-G709] technology specific information 56 needed to extend GMPLS signalling to control Optical Transport 57 Networks (OTN); it also includes the so-called pre-OTN 58 developments. 60 DISCLAIMER 62 In this document, the presented views on ITU-T G.709 OTN 63 Recommendation (and referenced) are intentionally restricted as 64 needed from the GMPLS perspective within the IETF CCAMP WG context. 66 Hence, the objective of this document is not to replicate the 67 content of the ITU-T OTN recommendations. Therefore, the reader 68 interested in going into more details concerning the corresponding 69 technologies is strongly invited to consult the corresponding ITU- 70 T documents (also referenced in this memo). 72 1. Introduction 74 Generalized MPLS extends MPLS from supporting Packet Switching 75 Capable (PSC) interfaces and switching to include support of three 76 new classes of interfaces and switching: Time-Division Multiplex 77 (TDM), Lambda Switch (LSC) and Fiber-Switch (FSC) Capable. A 78 functional description of the extensions to MPLS signaling needed 79 to support these new classes of interfaces and switching is 80 provided in [GMPLS-SIG]. [GMPLS-RSVP] describes RSVP-TE specific 81 formats and mechanisms needed to support all four classes of 82 interfaces, and CR-LDP extensions can be found in [GMPLS-LDP]. 84 This document presents the technology details that are specific to 85 G.709 Optical Transport Networks (OTN) as specified in the ITU-T 86 G.709 recommendation [ITUT-G709] (and referenced documents), 87 including pre-OTN developments. Per [GMPLS-SIG], G.709 specific 88 parameters are carried through the signaling protocol in traffic 89 parameter specific objects. 91 Note: in the context of this memo, by pre-OTN developments, one 92 refers to Optical Channel, Digital Wrapper and Forward Error 93 Correction (FEC) solutions that are not G.709 compliant. Details 94 concerning pre-OTN SONET/SDH based solutions including Optical 95 Sections (OS), Regenerator Section(RS)/Section and Multiplex 96 Section(MS)/ Line overhead transparency are covered in [GMLS-SSS] 97 and [GMPLS-SSS-EXT]. 99 2. GMPLS Extensions for G.709 101 Although G.709 defines several networking layers (OTS, OMS, OPS, 102 OCh, OChr constituting the optical transport hierarchy and OTUk, 103 ODUk constituting the digital transport hierarchy) only the OCh 105 D.Papadimitriou et al. - Internet Draft � Expires September 2002 2 106 (Optical Channel) and the ODUk (Optical Channel Data Unit) layers 107 are defined as switching layers. Both OCh (but not OChr) and ODUk 108 layers include the overhead for supervision and management. The OCh 109 overhead is transported in a non-associated manner (so also referred 110 to as the non-associated overhead � naOH) in the OTM Overhead Signal 111 (OOS), together with the OTS and OMS non-associated overhead. The 112 OOS is transported via a dedicated wavelength referred to as the 113 Optical Supervisory Channel (OSC). It should be noticed that the 114 naOH is only functionally specified and as such open to vendor 115 specific solutions. The ODUk overhead is transported in an 116 associated manner as part of the digital ODUk frame. 118 As described in [ITUT-G709], in addition to the support of ODUk 119 mapping into OTUk (k = 1, 2, 3), [ITUT-G.709] supports ODUk 120 multiplexing. It refers to the multiplexing of ODUj (j = 1, 2) into 121 an ODUk (k > j) signal, in particular: 122 - ODU1 into ODU2 multiplexing 123 - ODU1 into ODU3 multiplexing 124 - ODU2 into ODU3 multiplexing 125 - ODU1 and ODU2 into ODU3 multiplexing 127 Therefore, adapting GMPLS to control G.709 OTN, can be achieved by 128 considering that: 129 - a Digital Path layer by extending the previously defined 130 �Digital Wrapper� in [GMPLS-SIG] corresponding to the ODUk 131 (digital) path layer. 132 - an Optical Path layer by extending the �Lambda� concept defined 133 in [GMPLS-SIG] to the OCh (optical) path layer. 134 - a label space structure by considering a tree whose root is an 135 OTUk signal and leaves the ODUj signals (k >= j); enabling to 136 identify the exact position of a particular ODUj signal in an 137 ODUk multiplexing structure. 139 Thus, GMPLS extensions for G.709 need to cover the Generalized Label 140 Request, the Generalized Label as well as the specific technology 141 dependent fields equivalent to the one currently specified for 142 SDH/SONET in [GMPLS-SSS]. Since the multiplexing in the digital 143 domain (such as ODUk multiplexing) has been considered in the 144 updated version of the G.709 recommendation (October 2001), we also 145 propose a label space definition suitable for that purpose. Notice 146 also that we directly use the G.709 ODUk (i.e. Digital Path) and OCh 147 layers in order to define the corresponding label spaces. 149 3. Generalized Label Request 151 The Generalized Label Request as defined in [GMPLS-SIG], includes a 152 technology independent part and a technology dependent part (i.e. 153 the traffic parameters). In this section, we suggest to adapt both 154 parts in order to accommodate the GMPLS Signalling to the G.709 155 recommendation [ITUT-G709]. 157 3.1 Technology Independent Part 159 D.Papadimitriou et al. - Internet Draft � Expires September 2002 3 160 As defined in [GMPLS-SIG], the LSP Encoding Type and the Generalized 161 Protocol Identifier (Generalized-PID) constitute the technology 162 independent part of the Generalized Label Request. 164 The information carried in the technology independent part of the 165 Generalized Label Request is defined as follows: 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | LSP Enc. Type |Switching Type | G-PID | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 As mentioned here above, we suggest here to adapt the LSP Encoding 174 Type and the G-PID (Generalized-PID) to accommodate G.709 175 recommendation [ITUT-G709]. 177 3.1.1 LSP Encoding Type 179 Since G.709 defines two networking layers (ODUk layers and OCh 180 layer), the LSP Encoding Type code-points can reflect these two 181 layers currently defined in [GMPLS-SIG] as �Digital Wrapper� and 182 �Lambda� code. 184 The LSP Encoding Type is specified per networking layer or more 185 precisely per group of functional networking layer: the ODUk layers 186 and the OCh layer. 188 Therefore, the current �Digital Wrapper� code-point defined in 189 [GMPLS-SIG] can be replaced by two separated code-points: 190 - code-point for the G.709 Digital Path layer 191 - code-point for the non-standard Digital Wrapper layer 193 In the same way, two separated code-points can replace the current 194 defined �Lambda� code-point: 195 - code-point for the G.709 Optical Channel layer 196 - code-point for the non-standard Lambda layer (also referred to 197 as Lambda layer which includes the pre-OTN Optical Channel 198 layer) 200 Consequently, we have the following additional code-points for the 201 LSP Encoding Type: 203 Value Type 204 ----- ---- 205 12 G.709 ODUk (Digital Path) 206 13 G.709 Optical Channel 208 Moreover, the code-point for the G.709 Optical Channel (OCh) layer 209 will indicate the capability of an end-system to use the G.709 non- 210 associated overhead (naOH) i.e. the OTM Overhead Signal (OOS) 211 multiplexed into the OTM-n.m interface signal. 213 D.Papadimitriou et al. - Internet Draft � Expires September 2002 4 214 3.1.2 Switching Type 216 The Switching Type indicates the type of switching that should be 217 performed at the termination of a particular link. This field is 218 only needed for links that advertise more than one type of switching 219 capability (see [GMPLS-RTG]). 221 Here, no additional values are to be considered in order to 222 accommodate G.709 switching types since an ODUk switching (and so 223 LSPs) belongs to the TDM class while an OCh switching (and so LSPs) 224 to the Lambda class (i.e. LSC). 226 Moreover, in a strict layered G.709 network architecture, when a 227 downstream node receives a Generalized Label Request with one of 228 these values as Switching Type, this value is ignored. 230 3.1.3 Generalized-PID (G-PID) 232 The G-PID (16 bits field) as defined in [GMPLS-SIG], identifies the 233 payload carried by an LSP, i.e. an identifier of the client layer of 234 that LSP. This identifier is used by the endpoints of the G.709 LSP. 236 The G-PID can take one of the following values when the client 237 payload is transported over the Digital Path layer, in addition to 238 the payload identifiers already defined in [GMPLS-SIG]: 239 - CBRa: asynchronous Constant Bit Rate i.e. mapping of STM-16/OC-48, 240 STM-64/OC-192 and STM-256/OC-768 241 - CBRb: bit synchronous Constant Bit Rate i.e. mapping of STM-16/OC- 242 48, STM-64/OC-192 and STM-256/OC-768 243 - ATM: mapping at 2.5, 10 and 40 Gbps 244 - BSOT: non-specific client Bit Stream with Octet Timing i.e. 245 Mapping of 2.5, 10 and 40 Gbps Bit Stream 246 - BSNT: non-specific client Bit Stream without Octet Timing i.e. 247 Mapping of 2.5, 10 and 40 Gbps Bit Stream 248 - ODUk: transport of Digital Path at 2.5, 10 and 40 Gbps 250 The G-PID can take one of the following values when the client 251 payload is transported over the Optical Channel layer, in addition 252 to the payload identifiers already defined in [GMPLS-SIG]: 253 - CBR: Constant Bit Rate i.e. mapping of STM-16/OC-48, STM-64/OC-192 254 and STM-256/OC-768 255 - OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps 257 When the client payloads such as Ethernet/MAC and IP/PPP are 258 encapsulated through the Generic Framing Procedure (GFP) as 259 described in ITU-T G.7041, we use dedicated G-PID values. Notice 260 that additional G-PID values such as ESCON, FICON and Fiber Channel 261 could complete this list in future releases. 263 In order to include pre-OTN developments as defined above, the G-PID 264 can take one of the values currently defined in [GMPLS-SIG], when 265 the client payload is transported over an Optical Channel (i.e. a 266 lambda): 268 D.Papadimitriou et al. - Internet Draft � Expires September 2002 5 269 - Gigabit Ethernet: 1 Gbps and 10 Gbps 270 - ESCON and FICON : left for further consideration 271 - Fiber Channel : left for further consideration 273 The following table summarizes the G-PID with respect to the LSP 274 Encoding Type: 276 Value G-PID Type LSP Encoding Type 277 ----- ---------- ----------------- 278 44 G.709 ODUj G.709 ODUk (with k > j) 279 45 G.709 OTUk(v) G.709 OCh (ODUk mapped into OTUk(v)) 280 46 CBR/CBRa G.709 ODUk, G.709 OCh 281 47 CBRb G.709 ODUk 282 48 BSOT G.709 ODUk 283 49 BSNT G.709 ODUk 284 50 IP/PPP (GFP) G.709 ODUk 285 51 Ethernet (GFP) G.709 ODUk 287 Note: Value 46 and 47 includes mapping of SDH/Sonet 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 SONET, SDH, G.709 ODUk 295 33 Ethernet (GbE) G.709 OCh, Lambda, Fiber 296 34 SDH G.709 OCh, Lambda, Fiber 297 35 SONET 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-parameters 304 is carried additionally to the one included in the Generalized Label 305 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 3.2.1 Signal Type 323 D.Papadimitriou et al. - Internet Draft � Expires September 2002 6 324 This field (8 bits) indicates the requested G.709 elementary Signal 325 Type. The possible 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 3.2.3 Number of Multiplexed Components (NMC) 354 The NMC field (16 bits) indicates the number of ODU tributary slots 355 used by an ODUj when multiplexed into an ODUk (k > j) for the 356 requested LSP. This field is not applicable when an ODUk is mapped 357 into an OTUk and irrelevant at the Optical Channel layer. In both 358 cases, it MUST be set to zero (NMC = 0) when sent and should be 359 ignored when received. 361 When applied at the Digital Path layer, in particular for ODU2 362 connections multiplexed into one ODU3 payload, the NMC field 363 specifies the number of individual tributary slots (NMC = 4) 364 constituting the requested connection. These components are still 365 processed within the context of a single connection entity. For all 366 other currently defined multiplexing cases (see Section 2), the NMC 367 field is set to 1. 369 3.2.4 Number of Virtual Components (NVC) 371 The NVC field (16 bits) is dedicated to ODUk virtual concatenation 372 (i.e. ODUk Inverse Multiplexing) purposes. It indicates the number 373 of ODU1, ODU2 or ODU3 elementary signals that are requested to be 374 virtually concatenated to form an ODUk-Xv signal. By definition, 375 these signals MUST be of the same type. 377 D.Papadimitriou et al. - Internet Draft � Expires September 2002 7 378 This field is set to 0 (default value) to indicate that no virtual 379 concatenation is requested. 381 Note: the current usage of this field only applies for G.709 ODUk 382 LSP. Therefore, it must be set to zero when requesting G.709 OCh 383 LSP. 385 3.2.5 Multiplier (MT) 387 The multiplier field (16 bits) indicates the number of identical 388 composed signals requested for the LSP. A composed signal is the 389 resulting signal from the application of the NMC and NVC fields to 390 an elementary Signal Type. GMPLS signalling implies today that all 391 the composed signals must be part of the same LSP. 393 The multiplier field is set to one (default value) to indicate that 394 exactly one base signal is being requested. Zero is an invalid 395 value. When the multiplier field is greater than one, the resulting 396 signal is referred to as a multiplied signal. 398 3.2.6 Reserved Fields 400 The reserved fields (8 bits and 32 bits) are dedicated for future 401 use. Reserved bits should be set to zero when sent and must be 402 ignored when received. 404 4. Generalized Label 406 This section describes the Generalized Label space for the Digital 407 Path and the Optical Channel Layer. The label distribution rules 408 follows the ones defined in [GMPLS-SSS] and are detailed in Section 409 4.2. 411 4.1 ODUk Label Space 413 At the Digital Path layer (i.e. ODUk layers), G.709 defines three 414 different client payload bit rates. An Optical Data Unit (ODU) 415 frame has been defined for each of these bit rates. ODUk refers to 416 the frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps) 417 or 3 (for 40 Gbps). 419 In addition to the support of ODUk mapping into OTUk, the G.709 420 label space supports the sub-levels of ODUk multiplexing. ODUk 421 multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk 422 (k > j), in particular: 423 - ODU1 into ODU2 multiplexing 424 - ODU1 into ODU3 multiplexing 425 - ODU2 into ODU3 multiplexing 426 - ODU1 and ODU2 into ODU3 multiplexing 428 More precisely, ODUj into ODUk multiplexing (k > j) is defined when 429 an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an 431 D.Papadimitriou et al. - Internet Draft � Expires September 2002 8 432 ODTUG constituted by ODU tributary slots) which is mapped into an 433 OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is 434 mapped into an OTUk. 436 Therefore, the label space structure is a tree whose root is an OTUk 437 signal and leaves the ODUj signals (k >= j) that can be transported 438 via the tributary slots and switched between these slots. A G.709 439 Digital Path layer label identifies the exact position of a 440 particular ODUj signal in an ODUk multiplexing structure. 442 The G.709 Digital Path Layer label or ODUk label has the following 443 format: 445 0 1 2 3 446 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 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | Reserved | t3 | t2 |t1| 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 The specification of the three fields t1, t2 and t3 self- 452 consistently characterizes the ODUk label space. The value space of 453 the t1, t2 and t3 fields is defined as follows: 455 1. t1 (1-bit): 456 - t1=1 indicates an ODU1 signal. 457 - t1 is not significant for the other ODUk signal types (t1=0). 459 2. t2 (3-bit): 460 - t2=1 indicates a not further sub-divided ODU2 signal. 461 - t2=2->5 indicates the tributary slot (t2th-2) used by the 462 ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2). 463 - t2 is not significant for an ODU3 (t2=0). 465 3. t3 (6-bit): 466 - t3=1 indicates a not further sub-divided ODU3 signal. 467 - t3=2->17 indicates the tributary slot (t3th-1) used by the 468 ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3). 469 - t3=18->33 indicates the tributary slot (t3th-17) used by the 470 ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3). 472 Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required 473 to identify the 4 tributary slots used by the ODU2; these tributary 474 time slots have to be allocated in ascending order. 476 If the label sub-field value t[i]=1 (i, j = 1, 2 or 3) and t[j]=0 (j 477 > i), the corresponding ODUk signal ODU[i] is directly mapped into 478 the corresponding OTUk signal (k=i). We refer to this as the mapping 479 of an ODUk signal into an OTUk of the same order. Therefore, the 480 numbering starts at 1; zero is used to indicate a non-significant 481 field. A label field equal to zero is an invalid value. 483 Examples: 484 - t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1 486 D.Papadimitriou et al. - Internet Draft � Expires September 2002 9 487 - t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2 488 - t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3 489 - t3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot 490 of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2 491 - t3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot 492 of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3 494 4.2 Label Distribution Rules 496 In case of ODUk in OTUk mapping, only one of label can appear in the 497 Label field of a Generalized Label. 499 In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered 500 list of the labels in the multiplex is given (this list can be 501 restricted to only one label when NMC = 1). Each label indicates a 502 component (ODUj tributary slot) of the multiplexed signal. The order 503 of the labels must reflect the order of the ODUj into the multiplex 504 (not the physical order of tributary slots). 506 In case of ODUk virtual concatenation, the explicit ordered list of 507 all labels in the concatenation is given. Each label indicates a 508 component of the virtually concatenated signal. The order of the 509 labels must reflect the order of the ODUk to concatenate (not the 510 physical order of time-slots). This representation limits virtual 511 concatenation to remain within a single (component) link. In case of 512 multiplexed virtually concatenated signals, the first set of labels 513 indicates the components (ODUj tributary slots) of the first 514 virtually concatenated signal, the second set of labels indicates 515 the components (ODUj tributary slots) of the second virtually 516 concatenated signal, and so on. 518 In case of multiplication (i.e. when using the MT field), the 519 explicit ordered list of all labels taking part in the composed 520 signal is given. The above representation limits multiplication to 521 remain within a single (component) link. In case of multiplication 522 of multiplexed/virtually concatenated signals, the first set of 523 labels indicates the components of the first multiplexed/virtually 524 concatenated signal, the second set of labels indicates components 525 of the second multiplexed/virtually concatenated signal, and so on. 527 Note: As defined in [GMPLS-SIG], label field values only have 528 significance between two neighbors, and the receiver may need (in 529 some particular cases) to convert the received value into a value 530 that has local significance. 532 4.3 Optical Channel Label Space 534 At the Optical Channel layer, the label space must be consistently 535 defined as a flat space whose values reflect the local assignment of 536 OCh identifiers corresponding to the OTM-n.m sub-interface signals 537 (m = 1, 2 or 3). Notice that these identifiers do not cover OChr 538 since the corresponding Connection Function (OChr-CF) between OTM- 539 nr.m/OTM-0r.m is not yet defined in [ITUT-G798]. 541 D.Papadimitriou et al. - Internet Draft � Expires September 2002 10 542 The OCh identifiers could be defined as specified in [GMPLS-SIG] 543 either with absolute values (channel identifiers (Channel ID) also 544 referred to as wavelength identifiers) or relative values (channel 545 spacing also referred to as inter-wavelength spacing). The latter is 546 strictly confined to a per-port label space while the former could 547 be defined as a local or a global label space. Such an OCh label 548 space is applicable to both OTN Optical Channel layer and pre-OTN 549 Optical Channel layer. For this layer, label distribution rules are 550 defined in [GMPSL-SIG]. 552 5. Examples 554 The following examples are given in order to illustrate the 555 processing described in the previous sections of this document. 557 1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is 558 directly transported in an OTU1 (OTU2 or OTU3), the upstream node 559 requests results simply in an ODU1 (ODU2 or ODU3) signal request. 561 In such conditions, the downstream node has to return a unique 562 label since the ODU1 (ODU2 or ODU3) is directly mapped into the 563 corresponding OTU1 (OTU2 or OTU3). Since a single ODUk signal is 564 requested (Signal Type = 1, 2 or 3), the downstream node has to 565 return a single ODUk label which can be for instance one of the 566 following when the Signal Type = 1: 568 - t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1 569 - t3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2 570 - t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3 572 2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed 573 into the payload of a structured ODU2 (or ODU3), the upstream 574 node requests results simply in a ODU1 signal request. 576 In such conditions, the downstream node has to return a unique 577 label since the ODU1 is multiplexed into one ODTUG2 (or ODTUG3). 578 The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or 579 OPU3) and then mapped into the corresponding OTU2 (or OTU3). 580 Since a single ODU1 multiplexed signal is requested (Signal Type 581 = 1 and NMC = 1), the downstream node has to return a single ODU1 582 label which can take for instance one of the following values: 584 - t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2 585 - t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3 586 - t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3 588 3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is 589 multiplexed into the payload of a structured ODU3, the upstream 590 node requests results simply in a ODU2 signal request. 592 In such conditions, the downstream node has to return four labels 593 since the ODU2 is multiplexed into one ODTUG3. The latter is 595 D.Papadimitriou et al. - Internet Draft � Expires September 2002 11 596 mapped into an ODU3 (via OPU3) and then mapped into an OTU3. 597 Since an ODU2 multiplexed signal is requested (Signal Type = 2, 598 and NMC = 4), the downstream node has to return four ODU labels 599 which can take for instance the following values: 601 - t3=18, t2=0, t1=0 (first part of ODU2 in first TS of ODTUG3) 602 - t3=22, t2=0, t1=0 (second part of ODU2 in fifth TS of ODTUG3) 603 - t3=23, t2=0, t1=0 (third part of ODU2 in sixth TS of ODTUG3) 604 - t3=26, t2=0, t1=0 (fourth part of ODU2 in ninth TS of ODTUG3) 606 4. When a single OCh signal of 40 Gbps is requested (Signal Type = 607 8), the downstream node must return a single wavelength 608 label as specified in [GMPLS-SIG]. 610 5. When requesting multiple ODUk LSP (i.e. with a multiplier (MT) 611 value > 1), an explicit list of labels is returned to the 612 requestor node. 614 When the downstream node receives a request for a 4 x ODU1 signal 615 (Signal Type = 1, NMC = 1 and MT = 4) multiplexed into a ODU3, it 616 returns an ordered list of four labels to the upstream node: the 617 first ODU1 label corresponding to the first signal of the LSP, 618 the second ODU1 label corresponding to the second signal of the 619 LSP, etc. For instance, the corresponding labels can take the 620 following values: 622 - First ODU1: t3=2, t2=0, t1=0 (in first TS of ODTUG3) 623 - Second ODU1: t3=10, t2=0, t1=0 (in ninth TS of ODTUG3) 624 - Third ODU1: t3=7, t2=0, t1=0 (in sixth TS of ODTUG3) 625 - Fourth ODU1: t3=6, t2=0, t1=0 (in fifth TS of ODTUG3) 627 6. Signalling Protocol Extensions 629 This section specifies the [GMPLS-RSVP] and [GMPLS-LDP] protocol 630 extensions needed to accommodate G.709 traffic parameters. 632 6.1 RSVP-TE Details 634 For RSVP-TE, the G.709 traffic parameters are carried in the G.709 635 SENDER_TSPEC and FLOWSPEC objects. The same format is used both 636 for SENDER_TSPEC object and FLOWSPEC objects. The content of the 637 objects is defined above in Section 3.2. The objects have the 638 following class and type for G.709: 639 - G.709 SENDER_TSPEC Object: Class = 12, C-Type = 4 (TBA) 640 - G.709 FLOWSPEC Object: Class = 9, C-Type = 4 (TBA) 642 There is no Adspec associated with the SONET/SDH SENDER_TSPEC. 643 Either the Adspec is omitted or an Int-serv Adspec with the 644 Default General Characterization Parameters and Guaranteed Service 645 fragment is used, see [RFC2210]. 647 For a particular sender in a session the contents of the FLOWSPEC 648 object received in a Resv message SHOULD be identical to the 650 D.Papadimitriou et al. - Internet Draft � Expires September 2002 12 651 contents of the SENDER_TSPEC object received in the corresponding 652 Path message. If the objects do not match, a ResvErr message with 653 a "Traffic Control Error/Bad Flowspec value" error SHOULD be 654 generated. 656 6.2 CR-LDP Details 658 For CR-LDP, the G.709 traffic parameters are carried in the G.709 659 Traffic Parameters TLV. The content of the TLV is defined in 660 Section 3.2. The header of the TLV has the following format: 662 0 1 2 3 663 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 664 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 665 |U|F| Type | Length | 666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 The type field indicates G.709 traffic parameters: 0xTBA 670 7. Security Considerations 672 This document introduces no new security considerations to either 673 [GMPLS-RSVP] or [GMPLS-LDP]. 675 8. References 677 [ITUT-G707] ITU-T G.707 Recommendation, �Network node interface for 678 the synchronous digital hierarchy (SDH)�, ITU-T, April 679 2000. 681 [ITUT-G709] ITU-T G.709 Recommendation, version 1.0 (and Addendum), 682 �Interface for the Optical Transport Network (OTN)�, 683 ITU-T, October 2001. 685 [ITUT-G798] ITU-T G.798 Recommendation, version 1.0, 686 �Characteristics of Optical Transport Network Hierarchy 687 Equipment Functional Blocks�, ITU-T, October 2001. 689 [ITUT-G872] ITU-T G.872 Recommendation, version 1.0, revision 6, 690 �Architecture of Optical Transport Network�, ITU-T, 691 August 2001. 693 [ITUT-GASTN] ITU-T G.807 Recommendation, version 1.0, �Automated 694 Switched Transport Network�, ITU-T, February 2001. 696 [GMPLS-ARCH] E.Mannie (Editor) et al., �Generalized Multi-Protocol 697 Label Switching (GMPLS) Architecture�, Internet Draft, 698 Work in progress, draft-ietf-ccamp-gmpls-architecture- 699 02.txt, February 2002. 701 [GMPLS-LDP] L.Berger (Editor) et al., �Generalized MPLS Signaling - 702 CR-LDP Extensions�, Internet Draft, Work in progress, 704 D.Papadimitriou et al. - Internet Draft � Expires September 2002 13 705 draft-ietf-mpls-generalized-cr-ldp-05.txt, November 706 2001. 708 [GMPLS-RSVP] L.Berger (Editor) et al., �Generalized MPLS Signaling - 709 RSVP-TE Extensions�, Internet Draft, Work in progress, 710 draft-ietf-mpls-generalized-rsvp-te-06.txt, November 711 2001. 713 [GMPLS-RTG] K.Kompella et al., �Routing Extensions in Support of 714 Generalized MPLS,� Internet Draft, Work in Progress, 715 draft-ietf-ccamp-gmpls-routing-02.txt, February 716 2002. 718 [GMPLS-SIG] L.Berger (Editor) et al., �Generalized MPLS 719 - Signaling Functional Description�, Internet Draft, 720 Work in progress, draft-ietf-mpls-generalized- 721 signaling-07.txt, October 2001. 723 [GMPLS-SSS] E.Mannie (Editor) et al., �Generalized MPLS � SDH/Sonet 724 Specifics�, Internet Draft, Work in progress, draft- 725 ietf-ccamp-gmpls-sonet-sdh-03.txt, February 2002. 727 [GMPLS-SSS-EXT] E.Mannie (Editor) et al., �Generalized MPLS � 728 SDH/Sonet Specifics Extensions�, Internet Draft, 729 Work, in progress, draft-ietf-ccamp-gmpls-sonet-sdh- 730 extensions-01.txt, February 2002. 732 [G709-FRM] A.Bellato, D.Papadimitriou et al., �G.709 Optical 733 Transport Networks GMPLS Control Framework�, Internet 734 Draft, Work in progress, draft-bellato-ccamp-g709- 735 framework-01.txt, November 2001. 737 [RFC-2210] J.Wroclawski, �The Use of RSVP with IETF Integrated 738 Services�, Internet RFC 2210, IETF Standard Track, 739 September 1997. 741 9. Acknowledgments 743 The authors would like to thank Jean-Loup Ferrant, Mathieu Garnot, 744 Massimo Canali, Germano Gasparini and Fong Liaw for their 745 constructive comments and inputs as well as James Fu, Siva 746 Sankaranarayanan and Yangguang Xu. 748 This draft incorporates (upon agreement) material and ideas from 749 draft-lin-ccamp-ipo-common-label-request-00.txt. 751 10. Author's Addresses 753 Alberto Bellato (Alcatel) 754 Via Trento 30, 755 I-20059 Vimercate, Italy 756 Phone: +39 039 686-7215 757 Email: alberto.bellato@netit.alcatel.it 759 D.Papadimitriou et al. - Internet Draft � Expires September 2002 14 760 Sudheer Dharanikota (Nayna Networks) 761 157 Topaz St., 762 Milpitas, CA 95035, USA 763 Phone: +1 408 956-8000X357 764 Email: sudheer@nayna.com 766 Michele Fontana (Alcatel) 767 Via Trento 30, 768 I-20059 Vimercate, Italy 769 Phone: +39 039 686-7053 770 Email: michele.fontana@netit.alcatel.it 772 Nasir Ghani (Sorrento Networks) 773 9990 Mesa Rim Road, 774 San Diego, CA 92121, USA 775 Phone: +1 858 646-7192 776 Email: nghani@sorrentonet.com 778 Gert Grammel (Alcatel) 779 Via Trento 30, 780 I-20059 Vimercate, Italy 781 Phone: +39 039 686-4453 782 Email: gert.grammel@netit.alcatel.it 784 Dan Guo (Turin Networks) 785 1415 N. McDowell Blvd 786 Petaluma, CA 94954, USA 787 Phone: +1 707 665-4357 788 Email: dguo@turinnetworks.com 790 Juergen Heiles (Siemens AG) 791 Hofmannstr. 51 792 D-81379 Munich, Germany 793 Phone: +49 89 7 22 - 4 86 64 794 Email: Juergen.Heiles@icn.siemens.de 796 Jim Jones (Alcatel) 797 3400 W. Plano Parkway, 798 Plano, TX 75075, USA 799 Phone: +1 972 519-2744 800 Email: Jim.D.Jones1@usa.alcatel.com 802 Zhi-Wei Lin (Lucent) 803 101 Crawfords Corner Rd, Rm 3C-512 804 Holmdel, New Jersey 07733-3030, USA 805 Tel: +1 732 949-5141 806 Email: zwlin@lucent.com 808 Eric Mannie (KPNQwest) 809 Terhulpsesteenweg, 6A 810 1560 Hoeilaart, Belgium 811 Phone: +32 2 658-5652 813 D.Papadimitriou et al. - Internet Draft � Expires September 2002 15 814 Email: eric.mannie@ebone.com 816 Dimitri Papadimitriou (Alcatel) 817 Francis Wellesplein 1, 818 B-2018 Antwerpen, Belgium 819 Phone: +32 3 240-8491 820 Email: Dimitri.Papadimitriou@alcatel.be 822 Maarten Vissers (Lucent) 823 Boterstraat 45 824 Postbus 18 825 1270 AA Huizen, Netherlands 826 Email: mvissers@lucent.com 828 Yong Xue (WorldCom) 829 22001 Loudoun County Parkway 830 Ashburn, VA 20147, USA 831 Tel: +1 703 886-5358 832 Email: yong.xue@wcom.com 834 D.Papadimitriou et al. - Internet Draft � Expires September 2002 16 835 Appendix 1 � Abbreviations 837 BSNT Bit Stream without Octet Timing 838 BSOT Bit Stream with Octet Timing 839 CBR Constant Bit Rate 840 ESCON Enterprise Systems Connection 841 FC Fiber Channel 842 FEC Forward Error Correction 843 FICON Fiber Connector 844 FSC Fiber Switch Capable 845 GFP Generic Framing Procedure 846 LSC Lambda Switch Capable 847 LSP Label Switched Path 848 MS Multiplex Section 849 naOH non-associated Overhead 850 NMC Number of Multiplexed Components 851 NNI Network-to-Network interface 852 NVC Number of Virtual Components 853 OCC Optical Channel Carrier 854 OCG Optical Carrier Group 855 OCh Optical Channel (with full functionality) 856 OChr Optical Channel (with reduced functionality) 857 ODTUG Optical Date Tributary Unit Group 858 ODU Optical Channel Data Unit 859 OH Overhead 860 OMS Optical Multiplex Section 861 OMU Optical Multiplex Unit 862 OOS OTM Overhead Signal 863 OPS Optical Physical Section 864 OPU Optical Channel Payload Unit 865 OSC Optical Supervisory Channel 866 OTH Optical transport hierarchy 867 OTM Optical transport module 868 OTN Optical transport network 869 OTS Optical transmission section 870 OTU Optical Channel Transport Unit 871 OTUkV Functionally Standardized OTUk 872 PPP Point to Point Protocol 873 PSC Packet Switch Capable 874 RES Reserved 875 RS Regenerator Section 876 TDM Time Division Multiplex 877 UNI User-to-Network Interface 879 Appendix 2 � G.709 Indexes 881 - Index k: The index "k" is used to represent a supported bit rate 882 and the different versions of OPUk, ODUk and OTUk. k=1 represents an 883 approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate 884 bit rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s 885 and k = 4 an approximate bit rate of 160 Gbit/s (under definition). 886 The exact bit-rate values are in kbits/s: 887 . OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322 889 D.Papadimitriou et al. - Internet Draft � Expires September 2002 17 890 . ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983 891 . OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559 893 - Index m: The index "m" is used to represent the bit rate or set of 894 bit rates supported on the interface. This is a one or more digit 895 �k�, where each �k� represents a particular bit rate. The valid 896 values for m are (1, 2, 3, 12, 23, 123). 898 - Index n: The index "n" is used to represent the order of the OTM, 899 OTS, OMS, OPS, OCG and OMU. This index represents the maximum number 900 of wavelengths that can be supported at the lowest bit rate 901 supported on the wavelength. It is possible that a reduced number of 902 higher bit rate wavelengths are supported. The case n=0 represents a 903 single channel without a specific wavelength assigned to the 904 channel. 906 - Index r: The index "r", if present, is used to indicate a reduced 907 functionality OTM, OCG, OCC and OCh (non-associated overhead is not 908 supported). Note that for n=0 the index r is not required as it 909 implies always reduced functionality. 911 D.Papadimitriou et al. - Internet Draft � Expires September 2002 18 912 Full Copyright Statement 914 "Copyright (C) The Internet Society (date). All Rights Reserved. 915 This document and translations of it may be copied and furnished to 916 others, and derivative works that comment on or otherwise explain it 917 or assist in its implementation may be prepared, copied, published 918 and distributed, in whole or in part, without restriction of any 919 kind, provided that the above copyright notice and this paragraph 920 are included on all such copies and derivative works. However, this 921 document itself may not be modified in any way, such as by removing 922 the copyright notice or references to the Internet Society or other 923 Internet organizations, except as needed for the purpose of 924 developing Internet standards in which case the procedures for 925 copyrights defined in the Internet Standards process must be 926 followed, or as required to translate it into languages other than 927 English. 929 The limited permissions granted above are perpetual and will not be 930 revoked by the Internet Society or its successors or assigns. 932 This document and the information contained herein is provided on an 933 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 934 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 935 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 936 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 937 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 939 D.Papadimitriou et al. - Internet Draft � Expires September 2002 19