idnits 2.17.1 draft-bellato-ccamp-g709-framework-01.txt: -(625): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(788): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(920): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(926): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(983): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1004): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1577): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1586): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1593): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1600): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1613): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1628): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1817): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1875): 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 seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == There are 90 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 37 longer pages, the longest (page 18) 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 ([ITUT-G709], [GMPLS-ARCH], [ITUT-G872]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == Unrecognized Status in 'Category: Informational 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 (November 2001) is 8188 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 30 -- Looks like a reference, but probably isn't: '2' on line 48 == Missing Reference: 'ITU-T G.872' is mentioned on line 84, but not defined == Missing Reference: 'ITUT-G.962' is mentioned on line 186, but not defined == Missing Reference: 'ITUT-G805' is mentioned on line 353, but not defined == Missing Reference: 'ITUT-G.872' is mentioned on line 404, but not defined == Missing Reference: 'ITUT-G798' is mentioned on line 1366, but not defined == Missing Reference: 'GMPSL-SIG' is mentioned on line 1376, but not defined == Missing Reference: 'ITUT-G.709' is mentioned on line 1464, but not defined == Missing Reference: 'MPLS-HIER' is mentioned on line 1509, but not defined == Missing Reference: 'LMP' is mentioned on line 1497, but not defined == Unused Reference: 'ITUT-G707' is defined on line 1574, but no explicit reference was found in the text == Unused Reference: 'ITUT-G962' is defined on line 1583, but no explicit reference was found in the text == Unused Reference: 'ITUT-GASTN' is defined on line 1586, but no explicit reference was found in the text == Unused Reference: 'ITUT-GASON' is defined on line 1589, but no explicit reference was found in the text == Unused Reference: 'GMPLS-LDP' is defined on line 1600, but no explicit reference was found in the text == Unused Reference: 'GMPLS-RSVP' is defined on line 1608, 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-G872' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-G962' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-GASTN' -- Possible downref: Non-RFC (?) normative reference: ref. 'ITUT-GASON' == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-gmpls-architecture-01 == Outdated reference: A later version (-19) exists of draft-ietf-isis-gmpls-extensions-04 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-gmpls-extensions (ref. 'GMPLS-ISIS-TE') == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-04 == Outdated reference: A later version (-12) exists of draft-ietf-ccamp-ospf-gmpls-extensions-00 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-05 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-06 == Outdated reference: A later version (-08) exists of draft-ietf-ccamp-gmpls-sonet-sdh-02 == Outdated reference: A later version (-05) exists of draft-ietf-isis-traffic-04 ** Downref: Normative reference to an Informational draft: draft-ietf-isis-traffic (ref. 'ISIS-TE') -- Possible downref: Normative reference to a draft: ref. 'MPLS-BDL' == Outdated reference: A later version (-10) exists of draft-katz-yeung-ospf-traffic-06 Summary: 11 errors (**), 0 flaws (~~), 28 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Alberto Bellato (Alcatel) 3 Category: Informational Draft Sudheer Dharanikota (Nayna) 4 Expiration Date: May 2002 Michele Fontana (Alcatel) 5 Germano Gasparini (Alcatel) 6 Nasir Ghani (Sorrento) 7 Gert Grammel (Alcatel) 8 Dan Guo (Turin) 9 Juergen Heiles (Siemens) 10 Jim Jones (Alcatel) 11 Zhi-Wei Lin (Lucent) 12 Eric Mannie (Ebone) 13 D. Papadimitriou (Alcatel) 14 S. Sankaranarayanan (Lucent) 15 Maarten Vissers (Lucent) 16 Yong Xue (WorldCom) 18 November 2001 20 Enabling GMPLS control of G.709 Optical Transport Networks 22 - Architectural Framework - 24 draft-bellato-ccamp-g709-framework-01.txt 26 Status of this Memo 28 This document is an Internet-Draft and is in full conformance with 29 all provisions of Section 10 of RFC2026 [1]. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. Internet-Drafts are draft documents valid for a maximum of 35 six months and may be updated, replaced, or obsoleted by other 36 documents at any time. It is inappropriate to use Internet- Drafts 37 as reference material or to cite them other than as "work in 38 progress." 39 The list of current Internet-Drafts can be accessed at 40 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: 45 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 46 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 47 this document are to be interpreted as described in RFC-2119 [2]. 49 D.Papadimitriou - Internet Draft � Expires May 2002 1 50 Abstract 52 Along with the current development of packet over lambda switching 53 (referred to as MPLambdaS), there are considerable developments in 54 optical transport systems based on the ITU-T G.872 [ITUT-G872] and 55 G.709 [ITUT-G709] specification. The Optical Transport Network (OTN) 56 defined in G.872 and G.709 enables ultra-long-haul transmission of 57 various client signal types through the use of Forward Error 58 Correction (FEC) bytes. G.709 specifies the data plane transport 59 structure and allocates overhead bytes for the OTN control plane. 61 In this document, we describe the G.709 Optical Transport Hierarchy 62 (OTH) defined at the ITU-T and the relationships with the current 63 GMPLS specification [GMPLS-ARCH]. The purpose is to determine how 64 the current GMPLS protocol suite can be accommodated in order to 65 encompass G.709-based optical networks. 67 DISCLAIMER 69 The scope of this memo is to provide basic information about ITU-T 70 G.709 recommendation by keeping in mind the IETF CCAMP context aka 71 �how GMPLS shall be extended in order to provide a control plane 72 supporting G.709 OTN networks�. Consequently, the presented view of 73 G.709 is restricted intentionally as needed from the GMPLS 74 perspective. 76 Hence, the objective of this document is not to replicate the 77 content of the ITU-T OTN recommendations. Therefore, the reader 78 interested in going into more details is kindly invited to consult 79 the corresponding ITU-T documents (referenced in this memo). 81 1. Introduction 83 The ITU-T recommendations "Optical Transport Networks (OTN) 84 Architecture" [ITU-T G.872] and "Interfaces for the OTN" [ITU-T 85 G.709] specify in detail the Optical Transport Hierarchy (OTH) and 86 corresponding functions of the interfaces for (all-)optical 87 networks. These include the transport of transparent digital pipes, 88 carried into optical channels by using the so-called digital wrapper 89 layer. The OTN recommendations provide an additional degree of 90 flexibility compared to the current pre-OTN approach (also referred 91 to as MPLambdaS due to the similarity between Label and Lambda 92 Switching when using MPLS for control plane purposes) as they enable 93 the multiplexing of lower bit-rate optical channel with digital 94 wrapper sub-structure. 96 Consequently, the OTN provides two fundamental levels of 97 flexibility. First in terms of optical channels (i.e. wavelengths) 98 and second, in terms of bandwidth transmission optimization by using 99 re-grooming capabilities without losing the integrity of the lower 100 bit rates pipes, filled by the access network devices since the 101 transport of the client signal is fully transparent. 103 D.Papadimitriou - Internet Draft � Expires May 2002 2 104 Today, Generalized MPLS (GMPLS) efforts are directed in extending 105 IP/MPLS well known technologies and protocols to control and manage 106 lower non-packet based networks, in particular layered networks. 107 Using the same framework and the same kinds of signaling and routing 108 protocols suite to control multiple layers will not only reduce the 109 overall complexity of designing, deploying and maintaining OTN 110 networks but also allow potentially two contiguous layers to inter- 111 operate when using either an overlay, an augmented or a peer model. 112 In the mean time, GMPLS is perfectly suited for controlling each 113 layer completely independently. 115 Moreover, GMPLS can provide new capabilities and features for OTN 116 such as distributed, flexible and scalable connection i.e. LSP 117 establishment (today performed through the use of centralized 118 Network Management Systems - NMS), multi-layer circuit establishment 119 and distributed restoration, all methods that are of paramount 120 importance for operators and carriers. 122 Consequently, the Generalized MPLS (GMPLS) protocol suite (see 123 [GMPLS-ARCH]) can undoubtedly be used as the distributed "control- 124 plane architecture� requested by OTN. 126 In this memo, we introduce the additional signalling and traffic- 127 engineering routing extensions required to provide GMPLS control for 128 OTNs. For this purpose, we analyze the differences between Lambda 129 (pre-OTN) and G.709 OTN Label Switched Paths (LSP) as well as GMPLS- 130 based control-plane implementation aspects for such networks. G.709 131 connectivity and GMPLS control plane integration for (all-)optical 132 backbone networks are addressed through several illustrative and 133 detailed examples. 135 2. Current Solutions 137 In this section, we describe the G.709 OTN specification foundations 138 as the evolution from point-to-point Dense WDM (DWDM) link through 139 the pre-OTN developments(s). 141 2.1 Pre-OTN DWDM Development 143 ITU-T describes pre-OTN WDM development for backward compatibility 144 with state of the art equipment�s. Pre-OTN development constitutes 145 the early foundation of the current OTN recommendation(s) at the 146 ITU-T (see ITU-T G.872, G.798 and G.709), but also the MPLambdaS 147 developments at the IETF for the next generation optical networks. 148 MPLambdaS has evolved in two ways since end 90�s, first to the 149 current GMPLS control plane protocol suite at the CCAMP Working 150 Group and second to the so-called all-optical approach developed at 151 the IPO Working Group. The next paragraphs detail the key drivers 152 for the current pre-OTN developments. 154 Pre-OTN DWDM has been developed during the last years in order to 155 overcome the bandwidth limitations and increase the bit-rate per 157 D.Papadimitriou - Internet Draft � Expires May 2002 3 158 fiber until several Tbps per fiber. Tomorrow, pre-OTN DWDM systems 159 will provide up to 1000 wavelengths at 2.5 Gbps (or 500 x 10 Gbps or 160 250 x 40 Gbps) per fiber. This development includes the definition 161 of point-to-point DWDM optical channels on top of a meshed topology 162 including Optical Cross-Connects (OXC) or Photonic Cross- 163 Connects (PXC). 165 Note: the following terminology is used in the next sections of this 166 document, a PXC is defined as an all-optical device (i.e. no O/E) 167 and an OXC as a non-transparent device (i.e. it provides O/E/O 168 conversion at each interface) so at least bit-rate dependent. 170 The current bandwidth bottleneck is overcome by the use of DWDM 171 technology enabling systems. These systems allow the multiplexing of 172 more than 160 wavelengths at 10 Gbps (i.e. 1.6 Tbps per fiber with 173 25 GHz spacing) by using simultaneously both the C-band and the L- 174 band. Today, some DWDM equipment reduces the channel spacing to 12.5 175 GHz or/and improves the bit-rate per wavelength up to 160 Gbps. 176 Consequently, it will be possible for instance to house 320 177 wavelengths of 10 Gbps in a single fiber (for a total throughput of 178 3.2 Terabits per fiber). 180 A complementary method for increasing the effective capacity of a 181 DWDM system is to include the 1480nm (S-Band) and 1650nm (U-Band) 182 together with the deployment of fibers covering an ultra-wide 183 waveband from 1460 to 1675nm (i.e. from the S-Band to the U-Band). 184 Nevertheless, the ITU-T currently refers to 50 GHz spacing within 185 the ITU-T Grid, and in order to guarantee line interface 186 interoperability, [ITUT-G.962] currently recommends 200 GHz 187 wavelength spacing. 189 In the pre-OTN application, client signals (STM-N, STS-N, GbE, IP, 190 etc.) are directly mapped on wavelength through the use of a 191 mapping-framing variable-length layer. This means that this 192 development does not include G.709 client-signal mapping 193 specification through the definition of a dedicated framing protocol 194 (also referred to as a digital wrapper layer). Moreover, additional 195 standard Transparency levels to the one defined for SONET (ANSI 196 T1.105) and SDH (ITU-T G.707) are defined for pre-OTN networks. 198 2.2 OTN Standard 200 Optical networks include a set of functionality providing transport, 201 multiplexing, routing, supervision and survivability of client 202 signals that are processed predominantly in the optical domain. 203 Optical signals are characterized by wavelength and may be processed 204 per wavelength or as a wavelength division multiplexed group. 206 The OTN model is decomposed into independent (transport) network 207 layers where each layer can be separately partitioned in a way that 208 reflects its internal structure. So that the OTN model refers to a 210 D.Papadimitriou - Internet Draft � Expires May 2002 4 211 layered structure defining an Optical Transport Hierarchy (OTH) 212 comprising an optical and a digital part (or entity). The former is 213 composed by the following layers: 215 - Optical Transmission Section (OTS) layer: this networking layer 216 provides functionality for transmission of optical signals on 217 optical media of various types. This layer ensures the integrity 218 and maintenance of the optical transmitted signal by overhead 219 processing 221 - Optical Multiplex Section (OMS) layer: this networking layer 222 provides functionality for networking of a multi-wavelength 223 optical signal. A "multi-wavelength" signal includes the case of 224 just one optical channel. This layer ensures the integrity and 225 maintenance of the multi-wavelength signal by overhead processing. 227 - Optical Channel (OCh) layer: this switching layer provides end-to- 228 end networking of optical channels for transparently conveying 229 client information of various formats (e.g. SDH STM-N, Sonet STS- 230 N, ATM, IP, etc.). The capabilities of this network layer concern 231 With connection rearrangement for flexible routing, overhead 232 processing, administration and maintenance functions. 234 Note: OCh is defined as a switching layer since a connection 235 function (OCh-CF) for this layer exists. 237 For the three layers specified above, non-associated overhead (naOH) 238 is transported via the Optical Supervisory Channel (OSC) in order to 239 supervise and manage the connectivity in the optical domain. It has 240 to be noticed that these three layers are common to both pre-OTN and 241 OTN applications. 243 For applications with only a single optical link and no flexibility 244 between two 3R regenerators reduced functionality layers are 245 defined: 246 - Optical Physical Section (OPS): this layer represents a optical 247 single- or multi-wavelength signal on optical media of 248 various types with 3-R regeneration on both sides. 249 - Reduced functionality Optical Channel (OChr): this layer 250 represents a single optical channel over a single optical span 251 between two 3-R regenerators. 253 OPS and OChr have no overhead assigned. All supervision and 254 management functions that rely on overhead are performed at the 255 OTU layer (see below) which is also terminated at 3-R regenerators. 257 Above the OCh/OChr layer, the G.709 Digital part is further 258 subdivided as follows: 259 - The Optical Channel Transport Unit (OTUk): this networking layer 260 provides FEC capabilities and optical section protection and 261 monitoring capabilities; it also referred to as the Digital 262 Section layer 263 - The Optical Channel Data Unit (ODUk): this switching layer 265 D.Papadimitriou - Internet Draft � Expires May 2002 5 266 provides client independent connectivity, connection protection 267 and monitoring (also without the need to terminate the overhead 268 information, the ODUk overhead may be monitored non-intrusively); 269 it also referred to the Digital Path layer 270 - Clients signals i.e. STM-N signals, IP packets, ATM cells and 271 Ethernet frames are mapped (meaning digitally wrapped) into the 272 Optical Channel Payload Unit (OPUk). 274 For each of these digital entities specified above (the OPUk mapping 275 and ODUk/OTUk networking layers), an associated in-band overhead 276 carrying the management information is added inside the framed 277 structure itself. Notice, that only the ODUk (k= 1, 2, 3) and OCh 278 are defined today as switching layers. The OTN layered transport 279 structure (with full functionality) can be schematically represented 280 as follows: 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== 283 | OCh Payload Unit (OPUk) | Client Signal Adaptation 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- 285 | OCh Data Unit (ODUk) | Digital Path Layer 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- 287 | OCh Transport Unit (OTUk) | Digital Section Layer 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== 289 | Optical Channel Layer (OCh) | Optical Channel Layer 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- 291 | Optical Multiplex Section OMS | Optical Multiplex Layer 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- 293 | Optical Transmission Section OTS | Optical Transmission Layer 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== 296 Note: the OPUk, ODUk and OTUk constitute the Digital Transport 297 Hierarchy also referred to as Digital Wrapper Layer. 299 The OTN specification supports also layered transport structure with 300 reduced functionality that can be schematically represented as 301 follows: 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== 304 | OCh Payload Unit (OPUk) | Client Signal Adaptation 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- 306 | OCh Data Unit (ODUk) | Digital Path Layer 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- 308 | OCh Transport Unit (OTUk) | Digital Section Layer 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== 310 | Reduced functionality | 311 | Optical Channel Layer (OChr) | Optical Channel Layer 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- 313 | Optical Physical Section (OPS) | Optical Multiplex 314 | | and Physical Layer 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== 317 In this context, the main features the optical transport hierarchy 318 (i.e. networking layer) can be summarized as follows: 320 D.Papadimitriou - Internet Draft � Expires May 2002 6 321 - It is the next step (after SDH/SONET) to support ever growing data 322 driven needs for bandwidth and emergence of new broadband services 323 - It provides the transparent transport for any kind of 324 client signals including full STM-N/STS-N signals, and ODUk TDM 325 for higher channel bit rates 326 - It supports next generation Terabit/second per fiber via DWDM 327 lines at the transport level as well as optical channels at 2.5 328 Gbps, 10 Gbps and 40 Gbps bit rates at wire speed level (and in 329 the future 160 Gbps currently under definition) 330 - It enables network supervision and operational management, 331 planning, administration, survivability, and finally cost of 332 maintenance limited only to the OTUk/ODUk rates of transmission 333 without caring about the granularity of the client signal. 335 The OTN Specification is described in more details in Section 4. We 336 first give an overview of the relationship between ITU-T G.872 and 337 G.709 recommendations. 339 3. Relationship between G.872 and G.709 341 The ITU-T G.872 recommendation is restricted to the functional 342 description of optical transport networks that support digital 343 signals. It defines optical networks as comprising a set of 344 functionality providing transport, multiplexing, routing, 345 supervision and survivability of client signals that are processed 346 predominantly in the optical domain. This set of functionality for 347 optical networks is described from a network level viewpoint using 348 the generic principles defined ITU-T G.805. It provides the specific 349 aspects concerning the optical transport network layered structure, 350 characteristic information, client/server layer associations, 351 network topology, and layer network functionality. 353 In accordance with ITU-T G.805 recommendation (see [ITUT-G805]), the 354 optical transport network is decomposed into independent transport 355 layer networks where each layer network can be separately 356 partitioned in a way which reflects the internal structure of that 357 layer network. 359 In the following functional description, optical signals are 360 characterized by wavelength (or central frequency) and may be 361 processed per wavelength or as a wavelength division multiplexed 362 group of wavelengths. Latest release of ITU-T G.872 also includes 363 the description of OTN Time Division Multiplexing (TDM) in the 364 digital domain also referred to as ODUk multiplexing (see Section 365 5.2). 367 In this context, ITU-T G.872 defines the architectural and 368 functional aspects of OTNs while ITU-T G.709 recommendation 369 specifies the Optical Transport Module of order n (OTM-n) interface 370 signals required within and between OTN sub-networks. Using ITU-T 371 terminology, the interfaces defined in the G.709 recommendation are 372 applicable at the User to Network Interface (UNI) and Network Node 373 Interface (NNI) if the OTN. Both interface functions are currently 375 D.Papadimitriou - Internet Draft � Expires May 2002 7 376 (more than) covered by the GMPLS protocol suite and in particular by 377 the current signalling subset of specifications (see [GMPLS-SIG]). 378 In fact both interfaces perfectly fit within specific GMPLS profiles 379 (out of the scope of this document). 381 4. Optical Transport Networks Specification 383 The G.709 specification defines the interfaces of the OTN to be used 384 within and between sub-networks of the optical network, in terms of: 385 - Optical Transport Hierarchy (OTH) 386 - functionality of the overhead in support of multi-wavelength 387 optical sub-networks 388 - frame structures 389 - bit rates 390 - formats for mapping client signals 392 The OTN interfaces specifications can be applied at User to Network 393 Interfaces (UNI) and Network Node Interfaces (NNI) of the OTN. The 394 overhead functionality necessary for operations and management of 395 optical sub-networks is also defined. For interfaces used within 396 optical sub-networks, the aspects related to the interface depend on 397 the optical technology progress and so are only functionally covered 398 by ITU-T G.709 recommendation without limiting the implementation to 399 a specific technology. 401 4.1 Optical Transport Module (OTM) 403 The Optical Transport Hierarchy (OTH) structure is defined as 404 specified in [ITUT-G.872] which, specifies the Optical Channel (OCh) 405 layer. The OTH is further structured in the digital domain by sub- 406 dividing the OCh layer which provides transparent network 407 connections between 3R regeneration points in the OTN, in order to 408 support multiplexing, management and supervision functions: 410 - The fully standardized Optical Channel Transport Unit-k (OTUk) 411 which provides supervision and conditions the signal for transport 412 between regeneration points in the OTN (1-R, 2-R and for pre-OTN 413 only, 3-R). 415 - The Optical Channel Data Unit (ODUk) which provides 416 . time division multiplexing (ODUk-TDM) 417 . tandem connection monitoring (ODUk-TCM), 418 . end-to-end path monitoring (ODUk-PM) 420 - The Optical Channel Payload Unit (OPUk) which provides adaptation 421 of client signals and thus defined as an adaptation layer 423 The Optical Transport Module-n (OTM-n) is the information structure 424 used to support OTN interfaces. Two OTM-n structure classes are 425 currently defined: 426 - OTM interfaces with full functionality (OTM-n.m) 427 - OTM interfaces with reduced functionality (OTM-0.m, OTM-nr.m) 429 D.Papadimitriou - Internet Draft � Expires May 2002 8 430 The reduced functionality OTM interfaces are defined with 3R 431 processing at each end of the OTN. However, the full and reduced 432 functionality interfaces are identical in the digital domain 433 including OPUk, ODUk and OTUk. The only differ in the optical 434 domain. The full functionality interface supports non-associated 435 overhead for the optical layers while reduced functionality 436 interface doesn�t. 438 The optical layer non-associated overhead currently supports the 439 following capabilities: 440 - Backward and Forward Defect Indication (BDI and FDI, resp.) 441 - Open Connection Indication (OCI) at OCh 442 - Payload Missing Indication (PMI) at OMS and OTS 443 - Tracing using the Trail Trace Identifier (TTI) at OTS 445 Note: G.709 indexes k, m, n and r are described in Appendix 2. 447 4.1.1 Full Functional Stack: OTM-n.m 449 With a full functional stack (OTM-n.m), the digital structure is 450 transported by the OCh. The latter has its own overhead transported 451 in a non-associated manner in the OTM Overhead Signal (OOS). The OCh 452 is modulated into a wavelength to form the Optical Channel Carrier 453 (OCC). Up to n OCC are multiplexed into an OCG-n.m using wavelength 454 division multiplexing. Together with the OMS and the OCh non- 455 associated overhead (OMSOH and OCHOH, respectively), the OCG-n.m 456 constitutes the OMS layer. In a last step, the OTS non-associated 457 overhead (OTSOH) is added to the OOS which is then transported on a 458 dedicated optical channel also referred to as the Optical 459 Supervisory Channel (OSC). Both OCG-n.m and OSC are transported in 460 the OTM-n.m interface signal. 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 463 | OCh Payload Unit OPUk |A| | 464 +-------------------------------------+-+ | Digital 465 | OCh Data Unit ODUk |S| | 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 467 | OCh Transport Unit OTUk |N| ------------------------- 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical (Analog) Boundary 469 | Optical Channel Layer OCh |S| ------------------------- 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | Optical Channel Carrier (OCC) |A| ------------------------- 472 +-------------------------------------+-+ OCh Multiplexing 473 | Optical Carrier Group (OCG-n.m) |A| ------------------------- 474 +-------------------------------------+-+ 475 | Optical Multiplex Section OMSn |N| 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Optical Transmission Section OTSn |N| 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 OTM-n.m (n > 1) 481 Where A: Adaptation � N: Networking � S: Switching layer 483 D.Papadimitriou - Internet Draft � Expires May 2002 9 484 The order of an OTM-n is defined by the order of the OCG-n that it 485 supports. 487 4.1.2 Reduced Functionality Stack: OTM-0r.m and OTM-nr.m 489 The OTM with reduced functionality could be either 490 - OTM-0r.m: consists of a single optical channel without a specific 491 assigned wavelength. Non associated overhead is not supported (see 492 Figure) 493 - OTM-nr.m: consists of up to n multiplexed optical channels. Non 494 associated overhead is not supported (see Figure) 496 Note that the first version of G.709, only defines reduced 497 functionality stack for standardized inter-domain interfaces. 499 1. OTM-nr.m 501 The digital signal structure is transported by the reduced 502 functionality Optical Channel OChr (OCh without non-associated 503 overhead). The OChr is then modulated into a wavelength to form the 504 reduced functionality Optical Channel Carrier (OCCr). Up to n OCCr 505 can be multiplexed into an OCG-nr.m using wavelength division 506 multiplexing. The OCG-nr.m is transported via the OTM-nr.m interface 507 signal. 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 510 | OCh Payload Unit (OPUk) |A| | 511 +-------------------------------------+-+ | Digital Domain 512 | OCh Data Unit (ODUk) |S| | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 514 | OCh Transport Unit (OTUk) |N| -------------------------- 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical (Analog) Boundary 516 | Optical Channel Layer (OChr) |S| -------------------------- 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 | Optical Channel Carrier (OCCr) |A| -------------------------- 519 +-------------------------------------+-+ OCh Multiplexing 520 | Optical Carrier Group (OCG-nr.m) |A| -------------------------- 521 +-------------------------------------+-+ 522 | | | 523 | Optical Physical Section (OPSn) |N| 524 | | | 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 OTM-nr.m (n > 1) 528 Where A: Adaptation � N: Networking � S: Switching layer 530 The order of an OTM-nr is defined by the order of the OCG-nr that it 531 supports. 533 2. OTM-0r.m (OTM-0.m) 535 The digital signal structure is transported by one single reduced 536 functionality Optical Channel (OChr) without non-associated 538 D.Papadimitriou - Internet Draft � Expires May 2002 10 539 overhead. The OChr is modulated into a non-colored wavelength to 540 form the reduced functionality Optical Channel Carrier (OCCr). 541 Consequently, reduced functionality OTM-0r.m interface does not 542 support wavelength division multiplexing functionality. The OCCr is 543 transported via the OTM-0r.m (or simply OTM-0.m) interface. 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 546 | OCh Payload Unit (OPUk) |A| | 547 +-------------------------------------+-+ | Digital Domain 548 | OCh Data Unit (ODUk) |S| | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 550 | OCh Transport Unit (OTUk) |N| -------------------------- 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical (Analog) Boundary 552 | Optical Channel Layer (OChr) |S| -------------------------- 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ 554 | Optical Channel Carrier (OCCr) |A| | 555 +-------------------------------------+-+ | 556 | | | | Optical Domain 557 | Optical Physical Section (OPS0) |N| | 558 | | | | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v 560 OTM-0r.m 562 Where A: Adaptation � N: Networking � S: Switching layer 564 4.2 Standardized OTM Interfaces 566 In the current ITU-T G.709 version, only two sub-classes of the OTM- 567 nr.m interfaces with reduced functionality are currently defined: 568 OTM-0.m and OTM-16r.m. These interfaces are only defined for inter- 569 domain interoperability purposes (while not strictly restricted to 570 this usage). 572 The OTM-nr.m interface signal supports n optical channels on a 573 single fiber with 3R regeneration and termination of the OTUk signal 574 on each end. As 3R regeneration is performed on both sides of the 575 OTM-nr.m (and OTM-0r.m) interfaces access to OTUk overhead is 576 available and maintenance as well as supervision of the interface is 577 provided via this overhead. Therefore non-associated OTM overhead is 578 not required across the OTM-nr.m (and OTM-0r.m) interfaces and 579 consequently, Optical Supervisory Channel (OSC) and OTM Overhead 580 Signal (OOS) are not supported. 582 4.2.1 OTM-16r.m Interface 584 The OTM-16r.m interface supports 16 Optical Channels (n = 16) on a 585 single optical span with 3R regeneration at each end. Six OTM-16r.m 586 interface signals are currently defined with respect to the index m 587 values (m = 1, 2, 3, 12, 23, 123). Notice that m = 13 bit-rate is 588 not defined. 590 D.Papadimitriou - Internet Draft � Expires May 2002 11 591 The OTM-16r.m signal is an OTM-nr.m signal with 16 Optical Channel 592 Carriers (OCCr) numbered from OCCr #0 to OCCr #15. Moreover, the 593 optical OSC is not present and there is no OOS either. 595 For instance, the OTM-16r can be separated in several cases 596 depending on the m index value: 597 - OTM-16r.1 with up to 16 wavelengths only at 2.5 Gbps 598 - OTM-16r.2 with up to 16 wavelengths only at 10 Gbps 599 - OTM-16r.3 with up to 16 wavelengths only at 40 Gbps 600 - OTM-16r.m with up to 16 wavelengths mixing all possible bit-rates 602 At least one of the OCCr is in service during normal operation and 603 transporting an OTUk. However, there is no predefined order in which 604 the OCCr�s are taken into service. 606 Note: As OPS and OChr overhead is not currently defined. The 607 interface will use the OTUk Supervision and Management OverHead 608 (SMOH) in this multi-wavelength interface for supervision and 609 management. OTM-16r.m connectivity failure reports (using TIM � 610 Trace Identifier Mismatch) will be computed from the individual OTUk 611 reports by means of failure correlation in fault management process. 613 4.2.2 OTM-0.m Interface 615 The OTM-0.m supports a single wavelength optical channel on a single 616 optical fiber with 3-R regeneration at each end. Three OTM-0.m 617 interface signals are defined with respect to the index m values 1, 618 2 and 3; each these of them carrying a single channel optical signal 619 containing one OTUk (with k = 1, 2, 3) signal. There is neither OSC 620 defined nor OOS for OTM-0.m. 622 Note: As OPS and OChr overhead is not currently defined. The 623 interface will use the OTUk Supervision and Management OverHead 624 (SMOH) in this multi-wavelength interface for supervision and 625 management. OTM-0r.m connectivity failure reports (using TIM � Trace 626 Identifier Mismatch) will be computed from the individual OTUk 627 reports by means of failure correlation in fault management process. 629 4.3 Signal Types 631 Signal types defined by the [ITUT-G709] specification can be divided 632 in Optical Channel Unit layer and Optical Transport Module (OTM). 633 The Payload Unit layer can itself be sub-divided in OCh Payload Unit 634 (OPU), OCh Data Unit (ODU) and OCh Transport Unit (OTU). The 635 Appendix 2 describes the indexes used within the [ITUT-G709] 636 terminology. 638 4.3.1 OPUk Signal 640 Optical channel Payload Unit (OPU) is defined as a structured signal 641 of order k (k = 1, 2, 3) and referred to as OPUk signal. The OPUk 642 frame structure is organized in an octet based block frame structure 643 with 4 rows and 3810 columns. The two main areas of the OPUk frame 645 D.Papadimitriou - Internet Draft � Expires May 2002 12 646 (4 x 3810 Bytes) are the OPUk Overhead area (column 15 and 16) and 647 OPUk Payload area (columns 17 to 3824). 649 OPUk overhead includes payload type information, multiplex structure 650 information in case of ODU multiplexing, concatenation information 651 in case of ODU virtual concatenation and mapping specific 652 information (e.g. justification/stuffing information and data) if 653 needed. 655 4.3.2 ODUk Signal 657 Optical channel Data Unit (ODU) is defined as a structured signal of 658 order k (k = 1, 2, 3) and referred to as ODUk signal. The ODUk frame 659 structure is organized in an octet based block frame structure with 660 4 rows and 3824 columns. The two main areas of the ODUk frame are 661 ODUk Overhead area (columns 1 to 14 with row 1 dedicated to FA and 662 OTUk specific alignment) and OPUk area (Columns 15 to 3824). 664 The ODUk overhead includes connectivity supervision (trace), signal 665 quality supervision (bit interleaved parity BIP), backward 666 information (for single ended maintenance) and status information 667 (e.g. alarm indication signal, open connection) for the end-to-end 668 path and 6 levels of tandem connection monitoring. 670 Furthermore overhead for automatic protection switching/protection 671 control, generic communication channels (e.g. for network management 672 communication or signaling), fault type and fault location 673 indication and experimental use. 675 4.3.3 OTUk Signal 677 Optical channel Transport Unit (OTU) of order k (k = 1, 2, 3) 678 defines the conditioning for transport over an Optical Channel 679 network connection. This includes overhead for supervision and 680 management purposes, frame alignment information and scrambling/line 681 coding for clock recovery. 683 The fully standardized OTUk (k = 1, 2, 3) frame structure is based 684 on the ODUk frame structure and extends it with a forward error 685 correction (FEC). The ODUk frame structure is organized in an octet 686 based block frame structure with 4 rows and 4080 columns. Columns 1 687 to 3824 are the ODUk frame and columns 3825 to 4080 contain the FEC 688 code. The OTUk overhead and frame alignment is contained in columns 689 1 to 14 of row 1. 691 The ODUk overhead includes connectivity supervision (trace), signal 692 quality supervision (bit interleaved parity BIP), backward 693 information (for single ended maintenance) and status information 694 (e.g. alarm indication signal, open connection). Furthermore 695 overhead for generic communication channels also referred to as GCC 696 (e.g. for network management communication or signaling). For frame 697 and multi-frame alignment AIX frame alignment bytes and a multi- 698 frame counter (for a 256 frame multi-frame) are used. 700 D.Papadimitriou - Internet Draft � Expires May 2002 13 701 The whole OTUk signal including the FEC code, excluding the six 702 frame alignment bytes is scrambled. 704 Note: In addition to the standard OTUk, non-standardized, vendor 705 specific OTUk formats OTUkV are allowed for intra-domain interfaces. 706 An OTUkV has to support the same overhead as the standard OTUk, but 707 it can use different (and enhanced) FEC schemes. 709 4.3.4 OCh Signal 711 The OCh consists of the single channel payload signal and non-OCh 712 associated overhead. The overhead includes signal status 713 information: forward defect information for payload and overhead, 714 and open connection indication. 716 4.3.5 OMS Signal 718 The OMS consists of the multi-channel payload signal and non- 719 associated OMS overhead. The overhead includes signal status 720 information: forward defect information for payload and overhead, 721 backward defect information for payload and overhead, payload 722 missing indication. 724 4.3.6 OTS Signal 726 The OTS consists of the multi-channel payload signal and non- 727 associated OTS overhead (OTSOH). This overhead includes signal 728 status information: backward defect information for payload and 729 overhead, payload missing indication, and connectivity supervision 730 information (e.g. optical section trace). 732 4.3.7 OTM Overhead Signal (OOS) 734 The OOS is the digital structure that transports the OCh, OMS and 735 OTS non-associated overhead. In addition it provides overhead for 736 generic communication channels (e.g. network management 737 communication, signaling, engineering order wire). The specific 738 frame format of the OOS and overhead coding is not defined. The OOS 739 is transported on the OSC. The OSC wavelength is not defined. 741 4.4 ODUk Mapping and Multiplexing 743 Since G.709 defines at the Optical Channel layer three distinct 744 client payload bit rates, an Optical Channel Data Unit (ODU) frame 745 has been defined for each of these bit rates. An ODUk refers to a 746 bit rate k framing signal, where k = 1 (for 2.5 Gbps), 2 (for 10 747 Gbps) or 3 (for 40 Gbps). 749 ODUk Multiplexing will be included in the future release of G.709 750 [ITUT-G709] while ODUk Mapping can be considered as the basic 751 mechanism underlying the Digital Transport Hierarchy layered 753 D.Papadimitriou - Internet Draft � Expires May 2002 14 754 structure. Note that ODUk and OTUk layers still remain in the 755 electrical domain and are referred to as Digital Path and Digital 756 Section in the ITU-T G.709 recommendation. 758 4.4.1 ODUk Mapping 760 By definition in ODUk mapping, the client signal is mapped into the 761 OPUk. The OPUk is mapped into an ODUk and the ODUk is mapped into an 762 OTUk. The OTUk is mapped into an OCh/OChr and the OCh/OChr is then 763 modulated onto an OCC/OCCr. 765 The ODUk mapping is depicted by the following figure: 767 x1 x1 768 OTU3 <---- ODU3 <---- OPU3 <----------------------------- Client PDU 770 x1 x1 771 OTU2 <--------------- ODU2 <---- OPU2 <------------------ Client PDU 773 x1 x1 774 OTU1 <-------------------------- ODU1 <---- OPU1 -------- Client PDU 776 4.4.2 ODUk Multiplexing 778 In addition to the support of ODUk mapping into OTUk, the G.709 779 recommendation defines ODUk flexible multiplexing (or simply ODUk 780 multiplexing). By definition, when multiplexing ODUj into ODUk (k > 781 j) an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an 782 ODTUG constituted by ODU tributary slots) is mapped into an OPUk. 783 The resulting OPUk is then mapped into an ODUk. The ODUk follows 784 then the rules defined ODUk mapping as described in the Section 785 4.4.1. 787 For instance, when multiplexing four ODU1 signals into an ODU2. The 788 ODU1 signals including the Frame Alignment OH and an all-0�s pattern 789 in the OTUk Overhead locations are then adapted to the ODU2 clock 790 via justification (asynchronous mapping). These adapted ODU1 signals 791 are byte interleaved into the OPU2 Payload area, and their 792 justification control and opportunity signals are frame interleaved 793 into the OPU2 Overhead area. ODU2 Overhead is added after which the 794 ODU2 can be mapped into the OTU2. OTU2 Overhead and Frame Alignment 795 Overhead and FEC are added to complete the signal for transport via 796 an OTM signal. 798 In brief, ODUk multiplexing refers to multiplexing of ODUj (j = 1, 799 2) into an ODUk (k > j), and in particular: 800 - ODU1 into ODU2 multiplexing 801 - ODU1 into ODU3 multiplexing 802 - ODU2 into ODU3 multiplexing 803 - ODU1 and ODU2 into ODU3 multiplexing 805 D.Papadimitriou - Internet Draft � Expires May 2002 15 806 And, two levels of ODUk multiplexing are currently defined: 807 - ODU1 multiplexing: 808 . four ODU1 are multiplexed into one ODTUG2 mapped into one OPU2 809 which is then mapped into one ODU2 810 . sixteen ODU1 are multiplexed into one ODTUG3 mapped into one 811 OPU3 which is then mapped into one ODU3 812 - ODU2 multiplexing: 813 . four ODU2 are multiplexed into one ODTUG3 mapped into one OPU3 814 which is then mapped into one ODU3 816 The ODUk multiplexing (and mapping) is described by the following 817 figure (where Client means Client Signal): 819 x1 x1 820 OTU3 <---- ODU3 <---- OPU3 <--------------------------------- Client 821 <--ODTUG3- 822 | | 823 | | 824 |x4 |x16 825 x1 | | 826 OTU2 <----------------------- ODU2 <--- OPU2 <--------------- Client 827 | <-ODTUG2 828 | | 829 | |x4 830 x1 -------- | 831 OTU1 <---------------------------------------- ODU1 <- OPU1 - Client 833 4.4.3 ODUk Inverse Multiplexing (Virtual Concatenation) 835 Inverse multiplexing is implemented by means of virtual 836 concatenation of two (or more than two) ODUk signals resulting into 837 an ODUk-Xv signal. The resulting ODUk-Xv signal can then transport a 838 non-OTN client signal (for instance, an ODU2-4v may transport an 839 STM-256). 841 The characteristic information of a virtual concatenated ODUk (ODUk- 842 Xv) layer network is transported via the set of X ODUk signals 843 constituting a single connection (i.e. a single LSP), each of the X 844 ODUk signal having its own transfer delay. The egress LSR 845 terminating the ODUk-Xv LSP has to compensate this differential 846 delay in order to provide a contiguous payload at the output. 848 4.5 Wavelength Division Multiplexing 850 With reduced stack functionality: up to n (n >= 1) OCCr are 851 multiplexed into an OCG-nr.m using wavelength division multiplexing. 852 The OCCr tributary slots of the OCG-nr.m can be of different size. 853 The OCG-nr.m is transported via the OTM-nr.m. 855 x1 x1 856 --------- OCCr <-------- OChr <-------- OTU3 858 D.Papadimitriou - Internet Draft � Expires May 2002 16 859 | 860 |xi 861 x1 | xj x1 x1 862 OTM-nr.m <------ OCG-nr.m <------ OCCr <-------- OChr <-------- OTU2 863 | 864 |xk 865 | x1 x1 866 --------- OCCr <-------- OChr <-------- OTU1 868 with 1 =< i + j + k =< n 870 With full stack functionality: up to n (n >= 1) OCC are multiplexed 871 into an OCG-n.m using wavelength division multiplexing. The OCC 872 tributary slots of the OCG-n.m can be of different size. The OCG-n.m 873 is transported via the OTM-n.m. 875 x1 x1 876 --------- OCC <-------- OCh <-------- OTU3 877 | 878 |xi 879 x1 | xj x1 x1 880 OTM-n.m <------ OCG-n.m <------ OCC <-------- OCh <-------- OTU2 881 | | 882 | |xk 883 | | x1 x1 884 | --------- OCC <-------- OCh <-------- OTU1 885 | 886 | x1 887 -------------- OSC <----- OOS (OTS OH, OMS OH, OCh OH) 889 with 1 =< i + j + k =< n 891 For the case of the full functionality OTM-n.m interfaces the OSC is 892 multiplexed into the OTM-n.m using wavelength division multiplexing. 894 4.6 Client Signal Mapping 896 The specification of the Client-layer signal encapsulation in the 897 OPU payload area has been provided through the definition of 898 different solutions depending upon the type of Client-layer signal. 900 ITU-T G.709 defines a bit synchronous and asynchronous mapping for 901 constant bit rate (CBR) at 2.5, 10 and 40 Gbps into OPU1, OPU2 and 902 OPU3, respectively. The CBR signals could be for instance SDH/Sonet 903 or 10 GbE WAN. 905 IP and Ethernet packet mapping is defined by the G.709 specification 906 through the use of the Generic Framing Procedure (GFP) as defined in 907 ITU-T G.7041 recommendation. This framing procedure has been 908 specified in order to avoid the use of Ethernet framing or SDH/Sonet 909 in order to encapsulate IP packets and other types of packet (such 910 as ESCON, Fiber Channel, etc.). As such, GFP provides a generic 911 framing for client signals. 913 D.Papadimitriou - Internet Draft � Expires May 2002 17 914 Details concerning GFP are covered in Appendix 3. 916 5. GMPLS Signalling Extensions for G.709 918 Adapting the GMPLS protocol suite to control G.709 can be achieved 919 by considering that G.709 defines an optical transport hierarchy 920 subdivided into a digital part (also known as the �Digital Wrapper�) 921 and an optical part. In this context, adapting GMPLS to control 922 G.709 OTN, can be achieved by considering: 923 - a Digital Path layer by extending the previously defined 924 �Digital Wrapper� in [GMPLS-SIG] corresponding to the ODUk 925 switching layer. 926 - an Optical Path layer by extending the �Lambda� concept defined in 927 [GMPLS-SIG] to the OCh switching layer. 929 GMPLS extensions for G.709 need also to be covered by the 930 Generalized Label Request, the Generalized Label as well as specific 931 technology dependent fields (also referred to as traffic parameters) 932 such as those currently assigned to the SDH/Sonet labels [GMPLS- 933 SSS]. 935 Moreover, since the multiplexing in the digital domain (such as ODUk 936 multiplexing) has been considered in the updated version of the 937 G.709 recommendation (October 2001), we can already propose a label 938 space definition suitable for that purpose. Notice also that 939 directly consider the usage of the G.709 ODUk (i.e. Digital Path) 940 and OCh layers in order to define the corresponding label spaces. 942 5.1 G.709 Label Request Considerations 944 A label request as defined in [GMPLS-SIG], includes a technology 945 independent part i.e. the Generalized Label Request and a technology 946 dependent part also referred to as the traffic parameters. 948 5.1.1 Technology Independent Part 950 As defined in [GMPLS-SIG], the Generalized Label Request includes 951 the LSP Encoding Type, Switching Type and the Generalized Protocol 952 Identifier (G-PID) which constitutes the technology independent part 953 of the label request. 955 As mentioned here above, we suggest here to adapt the LSP Encoding 956 Type, the Switching Type and the Generalized-PID (G-PID) to 957 accommodate G.709 recommendation [ITUT-G709]. 959 1. LSP Encoding Type 961 Since G.709 defines two networking layers (ODUk layers and OCh 962 layer), the LSP Encoding Type can reflect these two layers or be 963 considered as a common layer: 965 D.Papadimitriou - Internet Draft � Expires May 2002 18 966 - If an LSP Encoding Type is specified per networking layer or more 967 precisely per group of functional networking layer (i.e. ODUk and 968 OCh), then the Signal Type must not reflect these layers. This 969 means that two LSP Encoding Types have to defined: 970 . one reflecting the digital hierarchy (also referred to as the 971 �Digital Wrapper� layer) through the definition of the digital 972 path layer i.e. the ODUk layers 973 . the other reflecting the Optical Transport Hierarchy through the 974 definition of the optical path layer i.e. the OCh layer 976 - If the LSP Encoding Type is considered as a common space for G.709 977 meaning that the LSP Encoding Type doesn�t reflect the two G.709 978 hierarchies, then the Signal Type must reflect these layers without 979 distinguishing between LSPs. 981 In the latter case only one new code-point has to be defined for the 982 LSP Encoding Type while in the former case, two new code-points must 983 be defined. Therefore, the current �Digital Wrapper� code defined in 984 [GMPLS-SIG], could be replaced by two separated codes: 985 - code for the G.709 Digital Path layer 986 - code for the non-standard Digital Wrapper layer 988 In the same way, two separated code points could replace the current 989 defined �Lambda� code: 990 - code for the G.709 Optical Channel layer 991 - code for the non-standard Lambda layer (also simply referred to 992 as Lambda layer) which the pre-OTN Optical Channel layer 994 The fundamental point is not related to whether or not we have to 995 introduce one or two code-points but to the fact that a single LSP 996 Encoding Type will preclude ODUk switching when using reduced 997 functionality point-to-point optical channels (i.e. OChr). This 998 because the latter networking layer does not support any connection 999 function (i.e. OChr-CF is not defined by ITU-T G.709 1000 recommendation). 1002 Remember also here that the LSP encoding type represents the nature 1003 of the links that LSP traverses, for the sake of clarity, one 1004 assumes that when used with �layer model� based technologies such as 1005 G.709 OTN, the LSP Encoding type simply refers to the networking 1006 layer which determines the LSP definition. Consequently, a G.709 OCh 1007 LSP Encoding Type translates a G.709 OCh LSP request while a G.709 1008 ODUk LSP Encoding Type a G.709 ODUk LSP request. 1010 2. Switching Type 1012 The Switching Type indicates the type of switching that should be 1013 performed on a particular link. This field should only be used for 1014 links that advertise more than one type of switching capability. 1015 Noticed that in the context of layered networks the usage of this 1016 field is strictly optional and should not impact the processing of 1017 the other fields included in the Generalized Label Request. 1019 D.Papadimitriou - Internet Draft � Expires May 2002 19 1020 Moreover, no additional values are to be considered in order to 1021 accommodate G.709 switching since an ODUk switching belongs to the 1022 TDM Class while OCh switching to the OCh Class. Consequently, we 1023 have a 1:1 mapping between the LSP Encoding Type and the Switching 1024 Type making this field optional for G.709 LSP requests. 1026 3. Generalized-PID (G-PID) 1028 The G-PID (16 bits field) as defined in [GMPLS-SIG], identifies the 1029 payload carried by an LSP, i.e. an identifier of the client layer of 1030 that LSP. This identifier is used by the endpoints of the G.709 LSP. 1032 When the client payload is transported over the Digital Path layer, 1033 in addition to the payload identifiers already defined in [GMPLS- 1034 SIG], the G-PID can be defined as one of the following: 1035 - Asynchronous Constant Bit Rate (CBRa) i.e. mapping of STM-16/OC- 1036 48, STM-64/OC-192 and STM-256/OC-768 1037 - Bit synchronous Constant Bit Rate (CBRb) i.e. mapping of STM- 1038 16/OC-48, STM-64/OC-192 and STM-256/OC-768 1039 - ATM: mapping at 2.5, 10 and 40 Gbps 1040 - Non-specific client Bit Stream with Octet Timing (BSOT) i.e. 1041 Mapping of 2.5, 10 and 40 Gbps Bit Stream 1042 - Non-specific client Bit Stream without Octet Timing (BSNT) i.e. 1043 Mapping of 2.5, 10 and 40 Gbps Bit Stream 1044 - ODUj into ODUk (k > j) when performing ODU multiplexing before 1045 mapping into OTUk/OTUkV 1047 In addition, the G-PID can take one of the following definitions 1048 when the client payload is transported over the Optical Channel 1049 layer, in addition to the payload identifiers already defined in 1050 [GMPLS-SIG]: 1051 - Constant Bit Rate (CBR) i.e. mapping of STM-16/OC-48, STM-64/OC- 1052 192 and STM-256/OC-768 1053 - (ODUk mapped into) OTUk/OTUkV into OCh at 2.5, 10 or 40 Gbps 1055 When the client payloads such as Ethernet/MAC and IP/PPP are 1056 encapsulated through the Generic Framing Procedure (GFP) (ITU-T Rec. 1057 G.7042), we use dedicated G-PID values. Notice that additional G-PID 1058 values not defined in [GMPLS-SIG] such as ESCON, FICON and Fiber 1059 Channel could complete this list in the near future. 1061 In order to include pre-OTN developments, the G-PID can take one of 1062 the values currently defined in [GMPLS-SIG], when the client payload 1063 is transported over an Optical Channel (i.e. a lambda): 1064 - SDH: STM-16, STM-64 and STM-256 1065 - Sonet: OC-48, OC-192 and OC-768 1066 - Gigabit Ethernet: 1 Gbps and 10 Gbps 1068 5.1.2 Technology Dependent Part 1070 The technology dependent of the label request also referred to as 1071 the traffic-parameters must reflect the following G.709 features: 1072 ODUk mapping, ODUk multiplexing, OCh multiplexing and Multiple 1074 D.Papadimitriou - Internet Draft � Expires May 2002 20 1075 simultaneous requests. We also consider the support of the OTM 1076 Overhead Signal (OOS) for informational purposes only. 1078 1. Signal Type 1080 As defined in [GMPLS-SSS], the traffic-parameters must include the 1081 technology specific G.709 Signal Types i.e. the signals processed by 1082 the GMPLS control-plane. The corresponding identifiers reflect the 1083 Signal Types requested during the LSP setup. 1085 For each G.709 switching layers specific Signal Types must be 1086 considered: ODU1, ODU2, ODU3 for the Digital Path layer and (at 1087 least one) OCh for the Optical Channel layer. In the pre-OTN case, 1088 only one Signal Type value would be needed. 1090 Note: Additional Signal Type code-points such as ODU4 (currently 1091 under definition at the ITU-T) or ODU5 could also be reserved for 1092 future considerations. 1094 2. Multiplexing Type 1096 As defined in section 4.4, ODUk multiplexing is currently defined in 1097 the digital domain. Consequently, a dedicated field must indicate 1098 the type of multiplexing being requested during the ODUk LSP setup. 1099 The application of this field to an ODUk elementary signal results 1100 in an ODUk multiplexed signal. 1102 This multiplexing field specifies the type of multiplexing being 1103 requested for ODUk LSP. Each value of this field refers to a 1104 particular ODUk multiplexing type. Therefore we refer to this field 1105 as the Requested Multiplexing Type (RMT). This field is set to zero 1106 to indicate that no multiplexing is requested at all. 1108 This field can then allow an upstream node to indicate to a 1109 downstream node the different types of multiplexing that it 1110 supports. However, the downstream node decides which one to use 1111 according to its own rules. Several values could be set 1112 simultaneously to indicate a particular choice. 1114 Notice that this field (under the current version of the ITU-T G.709 1115 recommendation) is not applicable. Therefore, when requesting an OCh 1116 LSP, this field is set to its default value. 1118 3. ODUk Multiplexing 1120 A dedicated field must be considered which indicates the number of 1121 ODU tributary slots used by an ODUj when multiplexed into an ODUk (k 1122 > j) for the requested LSP, as specified by the RMT field. We refer 1123 to this field as the Number of Multiplexed Components (NMC). This 1124 field is thus irrelevant if no ODUk multiplexed signal is requested 1125 and in particular at the Optical Channel layer. 1127 D.Papadimitriou - Internet Draft � Expires May 2002 21 1128 When applied at the Digital Path layer and requesting flexible 1129 multiplexing, in particular for ODU2 connections multiplexed into an 1130 ODU3 payload, the NMC field specifies the number of individual 1131 tributary slots constituting the requested connection. These 1132 components are still processed within the context of a single 1133 connection entity. 1135 4. ODUk Virtual Concatenation 1137 A dedicated field must be considered to indicate the number of ODUk 1138 elementary signals to be inversely multiplexed (i.e. virtually 1139 concatenated) for the requested. We refer to this field as the 1140 Number of Virtual Components (NVC). This field is thus irrelevant if 1141 no ODUk virtually concatenated signal is requested and in particular 1142 at the Optical Channel layer. 1144 The NVC field indicates the number of ODU1, ODU2 or ODU3 elementary 1145 signals that are requested to be virtually concatenated to form a 1146 composed ODUk-Xv signal. These elementary signals must be of the 1147 same type by definition while being co-routed since belonging to a 1148 given LSP. This because GMPLS signalling implies today that all the 1149 components of a composed signal must be part of the same LSP. 1151 5. OTM Overhead Signal (OOS) 1153 A dedicated field could optionally be provided to indicate whether 1154 or not the non-associated overhead is supported at the G.709 Optical 1155 Channel layer. This feature is thus irrelevant for the G.709 Digital 1156 Path layer by definition and for the pre-OTN Optical Channel layer 1157 since the latter does not support non-associated overhead. 1159 This field should also not restrict the transport mechanism of the 1160 OTM Overhead Signal (OOS) since in-fiber/out-of-band OSC and out-of- 1161 fiber/out-of-band transport mechanisms are allowed. This field must 1162 ideally support the following options: 1164 - With OTM-0r.m and OTM-nr.m interfaces (reduced functionality 1165 stack), OTM Overhead Signal (OOS) is not supported. Therefore with 1166 these types of interface signals, non-associated OTM overhead 1167 indication is not required. 1169 - With OTM-n.m interfaces (full functionality stack), the OOS is 1170 supported and mapped into the Optical Supervisory Channel (OSC) 1171 which is multiplexed into the OTM-n.m using wavelength division 1172 multiplexing. 1174 - With OTM-0.m and OTM-nr.m interfaces, �non-standard� OOS can be 1175 defined to allow for instance interoperability with pre-OTN based 1176 devices or with any optical devices which does not support G.709 1177 OOS specification. This specific OOS enables the use of any 1178 proprietary monitoring signal exchange through any kind of 1179 supervisory channel (it can be transport by using any kind of IP- 1180 based control channel). 1182 D.Papadimitriou - Internet Draft � Expires May 2002 22 1183 6. Multiplication 1185 Multiplication is the operation allowing the simultaneous setup of 1186 more than one composed signal connection using a unique LSP request. 1187 A composed signal is the resulting signal from the application of 1188 the RMT, NMC and NVC fields to an elementary Signal Type. Therefore, 1189 a dedicated field simply referred to as Multiplier must be 1190 considered in order to specify the number of identical composed 1191 signals requested for the multiplied LSP. Consequently, the 1192 multiplier field will be set to one (default value) to indicate that 1193 exactly one composed signal is being requested. Notice that current 1194 GMPLS signalling implies today that all the composed signals must be 1195 part of the same LSP. 1197 7. Transparency 1199 Transparency could be considered for pre-OTN developments since by 1200 definition any signal transported over an OTN is fully transparent. 1202 This feature through its corresponding field referred to as 1203 Transparency is used when requesting a pre-OTN LSP (i.e. a non- 1204 standard Lambda-LSP) including transparency support. It may also be 1205 used to setup the transparency process to be applied in each 1206 intermediate LSR. 1208 As it is commonly the case today with pre-OTN capable interfaces, 1209 three kinds of transparency levels are currently defined: 1211 - SONET/SDH pre-OTN interfaces with RS/Section and MS/Line overhead 1212 transparency: the pre-OTN network is capable to transport 1213 transparently RSn STM-N/STS-N signals. 1215 - SONET/SDH pre-OTN interfaces terminating RS/Section overhead with 1216 MS/Line overhead transparency: the pre-OTN network is capable to 1217 transport transparently MSn STM-N/STS-N signals 1219 - SONET/SDH pre-OTN interfaces terminating RS/Section and MS/Line 1220 overhead: the pre-OTN network is capable to transport 1221 transparently HOVC/STS-SPE signals and STM-N/STS-N signals limited 1222 to a single contiguously concatenated VC-4-Nc/STS-Nc SPE 1224 Consequently, for pre-OTN Optical Channels a specific field (in the 1225 Generalized Label Request) must indicate the transparency level 1226 requested during the L-LSP setup. However, this field is only 1227 relevant when the LSP Encoding Type value corresponds to the Non- 1228 standard Lambda layer. 1230 With pre-OTN interfaces terminating RS/Section and MS/Line overhead, 1231 the optical network must be capable to transport transparently 1232 HOVC/STS-SPE signals. This transparency type is defined as the 1233 default transparency for pre-OTN LSP and is specified value by 1235 D.Papadimitriou - Internet Draft � Expires May 2002 23 1236 zeroing all flags (default Transport OH (TOH) transparency). We 1237 refer to [GMPLS-SSS] for an extended set of transparency flags. 1239 Pre-OTN developments also include the following cases which 1240 applies when the client signal is Gigabit Ethernet, ESCON, FICON 1241 or Fiber Channel (FC): 1242 - pre-OTN digital wrapper frame terminated; service signal is bit 1243 stream oriented and transparently passed throughout the network 1244 - pre-OTN case FEC frame terminated; service signal is bit stream 1245 oriented and transparently passed through 1247 Notice that in such a case Transparency feature is not considered 1248 in the scope of this document. 1250 5.2 G.709 Label Space 1252 This section describes the Generalized Label space for the Digital 1253 Path and the Optical Channel Layer. The G.709 label space must 1254 include two sub-spaces: the first reflecting the Digital Path layer 1255 (i.e. the ODUk layers) and the second, the Optical Channel layer 1256 (i.e. the OCh layer). The label distribution rules follows the ones 1257 defined in [GMPLS-SSS] as detailed in Section 4.2. 1259 5.2.1 ODUk Label 1261 At the Digital Path layer (i.e. ODUk layers), G.709 defines three 1262 different client payload bit rates. An Optical Data Unit (ODU) 1263 frame has been defined for each of these bit rates. ODUk refers to 1264 the frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps) 1265 or 3 (for 40 Gbps). 1267 In addition to the support of ODUk mapping into OTUk, the G.709 1268 label space supports the sub-levels of ODUk flexible multiplexing 1269 (or simply ODUk multiplexing). ODUk multiplexing refers to 1270 multiplexing of ODUj (j = 1, 2) into an ODUk (k > j), in particular: 1271 - ODU1 into ODU2 multiplexing 1272 - ODU1 into ODU3 multiplexing 1273 - ODU2 into ODU3 multiplexing 1274 - ODU1 and ODU2 into ODU3 multiplexing 1276 More precisely, ODUj into ODUk multiplexing (k > j) is defined when 1277 an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an 1278 ODTUG constituted by ODU tributary slots) which is mapped into an 1279 OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is 1280 mapped into an OTUk. 1282 Therefore, the corresponding label space structure can be defined as 1283 a tree whose root is an OTUk signal and leaves the ODUj signals (k 1284 >= j) that can be transported via the tributary slots and switched 1285 between these slots. A G.709 Digital Path layer label identifies the 1286 exact position of a particular ODUj signal in an ODUk multiplexing 1287 structure. 1289 D.Papadimitriou - Internet Draft � Expires May 2002 24 1290 The G.709 Digital Path Layer label or ODUk label is based on 1291 definition of the three fields: k1, k2 and k3. The value of these 1292 fields self-consistently characterizes the ODUk label space. The 1293 value space of the k1, k2 and k3 fields is defined as follows: 1295 1. k1 (1-bit) indicates: 1296 - an unstructured client signal mapped into an ODU1 (k1 = 1) 1297 via OPU1 1299 2. k2 (3-bit) indicates: 1300 - an unstructured client signal mapped into an ODU2 (k2 = 1) 1301 via OPU2 1302 - or the position of an ODU1 tributary slot in an ODTUG2 (k2 = 1303 2,..,5) mapped into an ODU2 (via OPU2) 1305 3. k3 (6-bit) indicates: 1306 - an unstructured client signal mapped into an ODU3 (k3 = 1) 1307 via OPU3 1308 - or the position of an ODU1 tributary slot in an ODTUG3 (k3 = 1309 2,..,17) mapped into an ODU3 (via OPU3) 1310 - or the position of an ODU2 tributary slot in an ODTUG3 (k3 = 1311 18,..,33) mapped into an ODU3 (via OPU3) 1313 If label k[i]=1 (i = 1, 2 or 3) and labels k[j]=0 (j = 1, 2 and 3 1314 with j=/=i), the corresponding ODUk signal ODU[i] is not structured 1315 and therefore simply mapped into the corresponding OTU[i]. We refer 1316 to this as the mapping of an ODUk into an OTUk. Therefore, the 1317 numbering starts at 1, zero is used to indicate a non-significant 1318 field. A label field equal to zero is an invalid value. 1320 Examples: 1321 - k3=0, k2=0, k1=1 indicated an ODU1 mapped into an OTU1 1322 - k3=0, k2=1, k1=0 indicated an ODU2 mapped into an OTU2 1323 - k3=1, k2=0, k1=0 indicates an ODU3 mapped into an OTU3 1324 - k3=0, k2=3, k1=0 indicates the second ODU1 into an ODTUG2 mapped 1325 into an ODU2 (via OPU2) mapped into an OTU2 1326 - k3=5, k2=0, k1=0 indicates the fourth ODU1 into an ODTUG3 mapped 1327 into an ODU3 (via OPU3) mapped into an OTU3 1329 5.2.2 Label Distribution Rules 1331 In case of ODUk in OTUk mapping, only one of label can appear in the 1332 Label field of a Generalized Label. 1334 In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered 1335 list of the labels in the multiplex is given (this list can be 1336 restricted to only one label when needed). Each label indicates a 1337 component (ODUj tributary slot) of the multiplexed signal. The order 1338 of the labels must reflect the order of the ODUj into the multiplex 1339 (not the physical order of tributary slots). 1341 In case of ODUk virtual concatenation, the explicit ordered list of 1342 all labels in the concatenation is given. Each label indicates a 1344 D.Papadimitriou - Internet Draft � Expires May 2002 25 1345 component of the virtually concatenated signal. The order of the 1346 labels must reflect the order of the ODUk to concatenate (not the 1347 physical order of time-slots). This representation limits virtual 1348 concatenation to remain within a single (component) link. 1350 In case of multiplication (i.e. when using the MT field), the 1351 explicit ordered list of all labels taking part in the composed 1352 signal is given. In case of multiplication of multiplexed/virtually 1353 concatenated signals, the first set of labels indicates the first 1354 multiplexed/virtually concatenated signal, the second set of labels 1355 indicates the second multiplexed/virtually concatenated signal, and 1356 so on. The above representation limits multiplication to remain 1357 within a single (component) link. 1359 5.2.3 Optical Channel Label 1361 At the Optical Channel layer, the label space should be consistently 1362 defined as a flat space whose values reflect the local assignment of 1363 OCh identifiers corresponding to the OTM-n.m sub-interface signals 1364 (m = 1, 2 or 3). Notice that these identifiers do not cover OChr 1365 since the corresponding Connection Function (OChr-CF) between OTM- 1366 nr.m/OTM-0r.m is not yet defined in [ITUT-G798]. 1368 The OCh identifiers could be defined as specified in [GMPLS-SIG] 1369 either with absolute values: (optical) channel identifiers (Channel 1370 ID) also referred to as wavelength identifiers or relative values: 1371 channel spacing also referred to as inter-wavelength spacing. The 1372 latter is strictly confined to a per-port label space while the 1373 former could be defined as a local or a global label space. Such an 1374 OCh label space is applicable to both OTN Optical Channel layer and 1375 pre-OTN Optical Channel layer. For this layer, label distribution 1376 rules are defined in [GMPSL-SIG]. 1378 5.3 Applications 1380 GMPLS extensions for G.709 OTN must support the following 1381 applications: 1383 1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) non- 1384 structured signal is transported into the payload of an OTU1 1385 (OTU2 or OTU3), the upstream node requests results in a non- 1386 structured ODU1 (ODU2 or ODU3) signal request. 1388 In such conditions, the downstream node has to return a unique 1389 label since the ODU1 (ODU2 or ODU3) is directly mapped into the 1390 corresponding OTU1 (OTU2 or OTU3). Since a single ODUk mapped 1391 signal is requested, the downstream node has to return a single 1392 ODUk label which can be for instance one of the following when 1393 the Signal Type = 1: 1394 - k3=0, k2=0, k1=1 indicating a single ODU1 mapped into an OTU1 1395 - k3=0, k2=1, k1=0 indicating a single ODU2 mapped into an OTU2 1396 - k3=1, k2=0, k1=0 indicating a single ODU3 mapped into an OTU3 1398 D.Papadimitriou - Internet Draft � Expires May 2002 26 1399 2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed 1400 into the payload of a structured ODU2 (or ODU3), the upstream 1401 node requests results in a multiplexed ODU1 signal request (RMT = 1402 1). 1404 In such conditions, the downstream node has to return a unique 1405 label since the ODU1 is multiplexed into one ODTUG2 (or ODTUG3). 1406 The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or 1407 OPU3) and then mapped into the corresponding OTU2 (or OTU3). 1408 Since a single ODU1 multiplexed signal is requested the 1409 downstream node has to return a single ODU1 label which can take 1410 for instance one of the following values: 1411 - k3=0, k2=4, k1=0 indicates the third ODU1 TS into ODTUG2 1412 - k3=2, k2=0, k1=0 indicates the first ODU1 TS into ODTUG3 1413 - k3=7, k2=0, k1=0 indicates the sixth ODU1 TS into ODTUG3 1415 3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is 1416 multiplexed into the payload of a structured ODU3, the upstream 1417 node requests results in a multiplexed ODU2 signal request. 1419 In such conditions, the downstream node has to return four labels 1420 since the ODU2 is multiplexed into one ODTUG3. The latter is 1421 mapped into an ODU3 (via OPU3) and then mapped into an OTU3. 1422 Since an ODU2 multiplexed signal is requested, the downstream 1423 node has to return four ODU label which can take for instance the 1424 following values: 1425 - k3=18, k2=0, k1=0 (first ODU TS into ODTUG3) 1426 - k3=22, k2=0, k1=0 (fifth ODU TS into ODTUG3) 1427 - k3=23, k2=0, k1=0 (sixth ODU TS into ODTUG3) 1428 - k3=26, k2=0, k1=0 (ninth ODU TS into ODTUG3) 1430 4. When a single OCh signal of 40 Gbps is requested, the downstream 1431 node must return a single wavelength label as specified in 1432 [GMPLS-SIG]. 1434 5. When requesting multiple ODUk LSP, an explicit list of labels is 1435 returned to the requestor node. When the downstream node receives 1436 a request for a 4 x ODU1 signal, it returns an ordered list of 1437 four labels to the upstream node: the first ODU1 label 1438 corresponding to the first signal of the LSP, the second ODU1 1439 label corresponding to the second signal of the LSP, etc. 1441 For instance, the corresponding labels can take the following 1442 values: 1443 - First ODU1: k3=2, k2=0, k1=0 (first ODU1 TS into ODTUG3) 1444 - Second ODU1: k3=6, k2=0, k1=0 (fifth ODU1 TS into ODTUG3) 1445 - Third ODU1: k3=7, k2=0, k1=0 (sixth ODU1 TS into ODTUG3) 1446 - Fourth ODU1: k3=10, k2=0, k1=0 (ninth ODU1 TS into ODTUG3) 1448 6. GMPLS Signalling Transport for G.709 1450 Furthermore, ITU-T defines an in-fiber/in-band signaling transport 1451 mechanism through an OTN by propose the allocation of a General 1453 D.Papadimitriou - Internet Draft � Expires May 2002 27 1454 Communication Channel (GCC), particularly GCC(0) at the OTUk layer 1455 and GCC(1), GCC(2) at the ODUk layer, within the optical layer 1456 overhead to transport the GMPLS signalling. 1458 Notice that [ITUT-G.709] foresees also the possibility to provide 1459 in-fiber/out-of-band signalling transport mechanisms (through the 1460 use of dedicated communication channels) at the OCh layer. 1462 6.1 ODUk General Communication Channel 1464 As defined in the [ITUT-G.709] recommendation, two fields of two 1465 bytes are allocated in the ODUk Overhead to support two General 1466 Communications Channels (GCC) between any pair of network elements 1467 with access to the ODUk frame structure (i.e. at 3-R regeneration 1468 points). The bytes for GCC(1) are located in row 4, columns 1 and 2, 1469 and the bytes for GCC(2) are located in bytes row 4, columns 3 and 4 1470 of the ODUk overhead. 1472 These bytes are defined as clear channels so that the format 1473 specification and their content can be defined for the purpose of 1474 in-fiber/in-band signalling transport mechanism. 1476 6.2 OTUk General Communication Channel 1478 Similarly, one field of two bytes is allocated in the OTUk Overhead 1479 to support two General Communications Channels (GCC) between any 1480 couple of network elements with access to the OTUk frame structure 1481 (i.e. between OTUk termination points). These GCC(0) bytes are 1482 located in row 1, columns 11 and 12 of the OTUk overhead. 1484 7. GMPLS TE-Routing Extensions for G.709 OTN 1486 TE extensions are defined for OSPF and ISIS in [OSPF-TE] and [ISIS- 1487 TE], respectively. They have been extended for GMPLS purposes in 1488 [GMPLS-OSPF-TE] and [GMPLS-ISIS-TE]. [MPLS-HIER] introduces the 1489 notion of Forwarding Adjacency (FA) while support of Link Bundling 1490 is defined in [MPLS-BDL]. 1492 The scope of the TE-Routing Extensions is restricted here to intra- 1493 domain routing. Routing information is transported by OSPF in Link 1494 State Advertisements (LSAs) grouped in OSPF PDUs, and is transported 1495 by IS-IS in Link State PDUs (LSPs). 1497 As specified in [LMP], a set of data bearing links between two 1498 adjacent LSRs is defined as a TE link (which is identified by a link 1499 ID). GMPLS integrates the TE-link notion by defining the following 1500 concepts: 1501 - links that are not Packet Switch Capable (PSC) may have TE 1502 properties; however, a Routing Adjacency (RA) cannot be brought up 1503 directly on such links 1504 - LSP can be advertised as a point-to-point TE-links in IGP routing 1505 protocol, i.e. as a Forwarding Adjacency (FA); thus, an advertised 1506 TE-link need no longer be between two direct neighbors (Forwarding 1508 D.Papadimitriou - Internet Draft � Expires May 2002 28 1509 Adjacencies (FA) are more extensively considered in [MPLS-HIER]). 1510 - several links having the same Traffic Engineering (TE) 1511 capabilities (i.e. same TE metric, same set of Resource Class and 1512 same Link Multiplexing capability) can be advertised as a single 1513 TE-link, such TE-links are referred to as link bundles whose 1514 individual link (or data bearing links) are referred to as 1515 component links; so there is no longer a one-to-one association 1516 between a regular routing adjacency and a TE-link. 1518 G.709 defines a digital hierarchy and an optical transport 1519 hierarchy. As described in Section 2, the first one includes the 1520 Digital Path Layer (i.e. the ODUk layers) while the OTH one includes 1521 the Optical Channel Layer (i.e. the OCh layer). Consequently we can 1522 define for of each of these hierarchies a separated set of specific 1523 TLV. We refer to the first set as LD (Link Digital) and to the 1524 second as LO (Link Optical). However, we do not foresee additional 1525 extensions from the one defined in [GMPLS-OSPF-TE] and [GMPLS-ISIS- 1526 TE] for pre-OTN routing domains. 1528 Moreover for each of these sets, two specific sub-sets of 1529 information must be transported by an extended routing protocol to 1530 enable Traffic-Engineering of the G.709 LSPs (ODUk and OCh LSPs) in 1531 OTN. First, a set of information describing the TE-link capabilities 1532 (i.e. the OTM-n.m/OTM-nr.m/OTM-0.m interface capabilities) 1533 independently of their usage must be defined. Then a set of 1534 information describing the resources utilization (also referred to 1535 as ODUk or OCh component allocation) used on each TE-link, i.e. the 1536 operational status of a link. This in turn (using fine-tuned 1537 parameter configuration) will reduce the amount of static 1538 information (changes are less frequent when considering TE-link 1539 capabilities) flooded throughout the routing domain. For more 1540 dynamic TE-attributes implying more frequent changes (consider for 1541 instance the TE-link component allocation), the information flooding 1542 will be confined to the layer to which this information is relevant. 1544 Therefore, for each of these sets, new TLV are defined: 1546 1. G.709 TE-link capabilities: 1548 - Link ODUk Mapping Capability TLV 1549 - Link ODUk Multiplexing Capability TLV 1550 - Link ODUk Virtual Concatenation Capability TLV 1551 - Link OCh Multiplexing Capability TLV 1553 2. G.709 TE-link allocation: 1555 - Link ODUk Component Allocation TLV 1556 - Link OCh Component Allocation TLV 1558 It results from the TE-link definition (see [MPLS-BDL]) that each 1559 component link of a bundled link must have the same G.709 1560 multiplexing and concatenation capabilities as defined hereafter. 1561 The corresponding TLVs (LD-MT, LO-MT and LD-VC) are specified once, 1563 D.Papadimitriou - Internet Draft � Expires May 2002 29 1564 and apply to each component link. No per component information or 1565 identification is required for these TLVs. 1567 8. Security Considerations 1569 Security considerations for OTN networks are not defined in this 1570 document. 1572 9. References 1574 1. [ITUT-G707] �Network node interface for the synchronous digital 1575 hierarchy (SDH)�, ITU-T Recommendation, March 1996. 1577 2. [ITUT-G709] �Interface for the Optical Transport Network (OTN)�, 1578 ITU-T draft version, February 2001 and Revision October 2001. 1580 3. [ITUT-G872] �Architecture of Optical Transport Network�, ITU-T 1581 draft version, February 2001. 1583 4. [ITUT-G962] �Optical interfaces for multi-channel systems with 1584 optical amplifiers�, ITU-T Recommendation, October 1998. 1586 5. [ITUT-GASTN] �Automated Switched Transport Network�, ITU-T draft 1587 version, G.807, October 2001. 1589 6. [ITUT-GASON] �Automated Switched Optical Network�, ITU-T draft 1590 version, G.8080, October 2001. 1592 7. [GMPLS-ARCH] E. Mannie et al., �Generalized Multi-Protocol Label 1593 Switching (GMPLS) Architecture�, Internet Draft, Work in progress, 1594 draft-ietf-ccamp-gmpls-architecture-01.txt, July 2001. 1596 8. [GMPLS-ISIS-TE] K. Kompella et al., �IS-IS Extensions in Support 1597 of Generalized MPLS,� Internet Draft, Work in progress, draft- 1598 ietf-isis-gmpls-extensions-04.txt, September 2001. 1600 9. [GMPLS-LDP] P. Ashwood-Smith, L. Berger et al., �Generalized MPLS 1601 Signaling -CR-LDP Extensions�, Internet Draft, Work in progress, 1602 draft-ietf-mpls-generalized-cr-ldp-04.txt, July 2001. 1604 10. [GMPLS-OSPF-TE] K. Kompella et al., �OSPF Extensions in Support 1605 of Generalized MPLS,� Internet Draft, Work in progress, draft- 1606 ietf-ccamp-ospf-gmpls-extensions-00.txt, September 2001. 1608 11. [GMPLS-RSVP] P. Ashwood-Smith, L. Berger et al., �Generalized 1609 MPLS Signaling - RSVP-TE Extensions�, Internet Draft, Work in 1610 progress, draft-ietf-mpls-generalized-rsvp-te-05.txt, October 1611 2001. 1613 12. [GMPLS-SIG] P. Ashwood-Smith, L. Berger et al., �Generalized MPLS 1614 - Signaling Functional Description�, Internet Draft, Work in 1615 progress, draft-ietf-mpls-generalized-signaling-06.txt, October 1616 2001. 1618 D.Papadimitriou - Internet Draft � Expires May 2002 30 1619 13. [GMPLS-SSS] E. Mannie et al., �Generalized MPLS � SDH/Sonet 1620 Specifics�, Internet Draft, Work in progress, draft-ietf-ccamp- 1621 gmpls-sonet-sdh-02.txt, October 2001. 1623 14. [ISIS-TE] T. Li et al.,�IS-IS Extensions for Traffic 1624 Engineering�, draft-ietf-isis-traffic-04.txt, Internet Draft, 1625 Work in Progress, August 2001. 1627 15. [MPLS-BDL] K. Kompella et al., �Link Bundling in MPLS Traffic 1628 Engineering,� Internet Draft, draft-kompella-mpls-bundle-05.txt, 1629 March 2001. 1631 16. [OSPF-TE] D. Katz et al., "Traffic Engineering Extensions to 1632 OSPF", draft-katz-yeung-ospf-traffic-06.txt, Internet Draft, Work 1633 in progress, September 2001. 1635 10. Acknowledgments 1637 The authors would like to be thank Bernard Sales, Emmanuel Desmet, 1638 Jean-Loup Ferrant, Mathieu Garnot and Massimo Canali for their 1639 constructive comments and inputs. 1641 This draft incorporates material and ideas from draft-lin-ccamp-ipo- 1642 common-label-request-00.txt. 1644 11. Author's Addresses 1646 Alberto Bellato 1647 Alcatel 1648 Via Trento 30, 1649 I-20059 Vimercate, Italy 1650 Phone: +39 039 686-7215 1651 Email: alberto.bellato@netit.alcatel.it 1653 Michele Fontana 1654 Alcatel 1655 Via Trento 30, 1656 I-20059 Vimercate, Italy 1657 Phone: +39 039 686-7053 1658 Email: michele.fontana@netit.alcatel.it 1660 Germano Gasparini 1661 Alcatel 1662 Via Trento 30, 1663 I-20059 Vimercate, Italy 1664 Phone: +39 039 686-7670 1665 Email: germano.gasparini@netit.alcatel.it 1667 Nasir Ghani 1668 Sorrento Networks 1669 9990 Mesa Rim Road, 1670 San Diego, CA 92121, USA 1672 D.Papadimitriou - Internet Draft � Expires May 2002 31 1673 Phone: +1 858 646-7192 1674 Email: nghani@sorrentonet.com 1676 Gert Grammel 1677 Alcatel 1678 Via Trento 30, 1679 I-20059 Vimercate, Italy 1680 Phone: +39 039 686-7060 1681 Email: gert.grammel@netit.alcatel.it 1683 Dan Guo 1684 Turin Networks 1685 1415 N. McDowell Blvd 1686 Petaluma, CA 94954, USA 1687 Phone: +1 707 665-4357 1688 Email: dguo@turinnetworks.com 1690 Juergen Heiles 1691 Siemens AG 1692 Hofmannstr. 51 1693 D-81379 Munich, Germany 1694 Phone: +49 89 722 - 486 64 1695 Email: Juergen.Heiles@icn.siemens.de 1697 Jim Jones 1698 Alcatel 1699 3400 W. Plano Parkway, 1700 Plano, TX 75075, USA 1701 Phone: +1 972 519-2744 1702 Email: Jim.D.Jones1@usa.alcatel.com 1704 Zhi-Wei Lin 1705 Lucent 1706 101 Crawfords Corner Rd, Rm 3C-512 1707 Holmdel, NJ 07733-3030, USA 1708 Phone: +1 732 949-5141 1709 Email: zwlin@lucent.com 1711 Dimitri Papadimitriou (Editor) 1712 Alcatel 1713 Francis Wellesplein 1, 1714 B-2018 Antwerpen, Belgium 1715 Phone: +32 3 240-8491 1716 Email: dimitri.papadimitriou@alcatel.be 1718 Siva Sankaranarayanan 1719 Lucent 1720 101 Crawfords Corner Rd 1721 Holmdel, NJ 07733-3030, USA 1722 Email: siva@hotair.hobl.lucent.com 1724 Maarten Vissers 1725 Lucent 1727 D.Papadimitriou - Internet Draft � Expires May 2002 32 1728 Boterstraat 45, PB-18 1729 1270 AA Huizen, Netherlands 1730 Email: mvissers@lucent.com 1732 Yong Xue 1733 WorldCom 1734 22001 Loudoun County Parkway 1735 Ashburn, VA 20147, USA 1736 Phone: +1 703 886-5358 1737 E-mail: yong.xue@wcom.com 1739 D.Papadimitriou - Internet Draft � Expires May 2002 33 1740 Appendix 1 � Abbreviations 1742 1R Re-amplification 1743 2R Re-amplification and Re-shaping 1744 3R Re-amplification, Re-shaping and Re-timing 1745 AI Adapted information 1746 AIS Alarm Indication Signal 1747 APS Automatic Protection Switching 1748 BDI Backward Defect Indication 1749 BEI Backward Error Indication 1750 BI Backward Indication 1751 BIP Bit Interleaved Parity 1752 CBR Constant Bit Rate 1753 CI Characteristic information 1754 CM Connection Monitoring 1755 EDC Error Detection Code 1756 EXP Experimental 1757 ExTI Expected Trace Identifier 1758 FAS Frame Alignment Signal 1759 FDI Forward Defect Indication 1760 FEC Forward Error Correction 1761 GCC General Communication Channel 1762 IaDI Intra-Domain Interface 1763 IAE Incoming Alignment Error 1764 IrDI Inter-Domain Interface 1765 MFAS MultiFrame Alignment Signal 1766 MS Maintenance Signal 1767 naOH non-associated Overhead 1768 NNI Network-to-Network interface 1769 OCC Optical Channel Carrier 1770 OCG Optical Carrier Group 1771 OCI Open Connection Indication 1772 OCh Optical Channel (with full functionality) 1773 OChr Optical Channel (with reduced functionality) 1774 ODU Optical Channel Data Unit 1775 OH Overhead 1776 OMS Optical Multiplex Section 1777 OMU Optical Multiplex Unit 1778 OOS OTM Overhead Signal 1779 OPS Optical Physical Section 1780 OPU Optical Channel Payload Unit 1781 OSC Optical Supervisory Channel 1782 OTH Optical transport hierarchy 1783 OTM Optical transport module 1784 OTN Optical transport network 1785 OTS Optical transmission section 1786 OTU Optical Channel Transport Unit 1787 PCC Protection Communication Channel 1788 PLD Payload 1789 PM Path Monitoring 1790 PMI Payload Missing Indication 1791 PRBS Pseudo Random Binary Sequence 1792 PSI Payload Structure Identifier 1794 D.Papadimitriou - Internet Draft � Expires May 2002 34 1795 PT Payload Type 1796 RES Reserved 1797 RS Reed-Solomon 1798 SM Section Monitoring 1799 TC Tandem Connection 1800 TCM Tandem Connection Monitoring 1801 UNI User-to-Network Interface 1803 Appendix 2 � G.709 Indexes 1805 - Index k: The index "k" is used to represent a supported bit rate 1806 and the different versions of OPUk, ODUk and OTUk. k=1 represents 1807 an approximate bit rate of 2.5 Gbit/s, k=2 represents an 1808 approximate bit rate of 10 Gbit/s, k = 3 an approximate bit rate 1809 of 40 Gbit/s and k = 4 an approximate bit rate of 160 Gbit/s 1810 (under definition). The exact bit-rate values are in kbits/s: 1811 . OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3:40 150 519.322 1812 . ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3:40 319 218.983 1813 . OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3:43 018 413.559 1815 - Index m: The index "m" is used to represent the bit rate or set of 1816 bit rates supported on the interface. This is a one or more digit 1817 �k�, where each �k� represents a particular bit rate. The valid 1818 values for m are (1, 2, 3, 12, 23, 123). 1820 - Index n: The index "n" is used to represent the order of the OTM, 1821 OTS, OMS, OPS, OCG and OMU. This index represents the maximum 1822 number of wavelengths that can be supported at the lowest bit rate 1823 supported on the wavelength. It is possible that a reduced number 1824 of higher bit rate wavelengths are supported. The case n=0 1825 represents a single channel without a specific wavelength assigned 1826 to the channel. 1828 - Index r: The index "r", if present, is used to indicate a reduced 1829 functionality OTM, OCG, OCC and OCh (non-associated overhead is 1830 not supported). Note that for n=0 the index r is not required as 1831 it implies always reduced functionality. 1833 Appendix 3 - Client Signal Mapping and GFP 1835 Generic Framing Procedure (GFP) provides a generic mechanism to 1836 adapt traffic from higher-layer client signals over SONET/SDH or 1837 OTNs. Client signals may be PDU-oriented (such as IP/PPP or Ethernet 1838 MAC), block-code-oriented such as Enterprise System Connect (ESCON), 1839 Fiber Connection (FICON), Fibre Channel (FC), or a Constant Bit Rate 1840 (CBR) stream. 1842 GFP consists of both common and client-specific aspects. Common 1843 aspects of GFP apply to all GFP-adapted traffic. Currently, two 1844 modes of client signal adaptation are defined for GFP: 1845 - a PDU-oriented adaptation mode, referred to as frame-mapped GFP 1846 - and a block-code-oriented adaptation mode, referred to as 1848 D.Papadimitriou - Internet Draft � Expires May 2002 35 1849 transparent GFP. 1851 Client-specific mapping definitions are well underway for 1852 Ethernet/GbE frames and HDLC, with work ongoing to include other 1853 client signals including unspecified 8B/10B, ESCON, FICON, and FC. 1854 In short, GFP defines a standard framing procedure for octet- 1855 aligned, variable-length payloads for subsequent mapping into 1856 SONET/SDH synchronous payload envelopes as defined in ANSI T1.105 1857 (v.02) or OTN G.709 OCh payloads. 1859 The GFP specification for SONET/SDH also leverages a parallel 1860 activity to standardize so-called virtual concatenation (VC) of 1861 SONET/SDH paths. In combination with VC, GFP will allow the mapping 1862 of a wide variety of data signals over SONET/SDH. 1864 Therefore GFP is defined as a generic mechanism to transport any 1865 client layer over a fixed data-rate optical channels (specifically, 1866 the so-called OTN ODU of unit-k or simply ODUk). This means that GFP 1867 idle frames must be generated when the client layer does not send 1868 data packet. Consequently the service offered to the client packet 1869 layer is strictly equivalent to the one offered in SDH. 1871 The Generic Framing Procedure (GFP) frame format is defined as: 1873 +----------+--------------------------------------------+----------+ 1874 | Header | Payload | FCS | 1875 | 4 bytes | 4 � 65535 bytes | Optional | 1876 +----------+--------------------------------------------+----------+ 1878 The header (4-bytes) is composed by a PDU Length Indicator (PLI) of 1879 2 bytes and a HEC (Header Error Control) of 2 bytes. 1881 The GFP Idle frame format, which includes a NULL PLI and a HEC of 2 1882 bytes, is defined as: 1884 +----------+ 1885 |Idle Frame| 1886 | 4bytes | 1887 +----------+ 1889 GFP defines also two basic frame-oriented mechanisms: 1891 1. GFP Frame Multiplexing: the GFP frame multiplexing is performed 1892 on a frame-by-frame basis. When no frames are waiting, idle 1893 frames are inserted. 1895 2. GFP Frame Delineation Algorithm: as defined for cell delineation, 1896 GFP frame delineation is based on the detection of correct HEC. 1897 PLI is used to find the start of the next frame. 1899 The GFP frames constitute the OPUk payload. The corresponding OPUk 1900 overhead is defined as follows by the Payload Structure Identifier 1901 (PSI) which includes the following fields: 1903 D.Papadimitriou - Internet Draft � Expires May 2002 36 1904 - PT: Payload Type (1-byte) 1905 - RES: Reserved (254-bytes) 1907 The GFP OPUk (k = 1, 2, 3) capacity are defined such that they can 1908 include the following client bit rates: 1909 - GFP (OPU1): 2 488 320 kbit/s 1910 - GFP (OPU2): 9 995 276 kbit/s 1911 - GFP (OPU3): 40 150 519 kbit/s 1913 Aligning the byte structure of every GFP frame with the byte 1914 structure of the OPUk Payload performs the mapping of GFP frames. 1915 Since the GFP frames are of variable length (the mapping does not 1916 impose any restrictions on the maximum frame length), a frame may 1917 cross the OPUk frame boundary. 1919 GFP frames arrive as a continuous bit stream (Idle frames when no 1920 client packets) with a capacity that is identical to the OPUk 1921 payload area, due to the insertion of Idle frames at the GFP 1922 encapsulation stage. Note that here, the GFP frame stream is 1923 scrambled during encapsulation. 1925 D.Papadimitriou - Internet Draft � Expires May 2002 37 1926 Full Copyright Statement 1928 "Copyright (C) The Internet Society (date). All Rights Reserved. 1929 This document and translations of it may be copied and furnished to 1930 others, and derivative works that comment on or otherwise explain it 1931 or assist in its implementation may be prepared, copied, published 1932 and distributed, in whole or in part, without restriction of any 1933 kind, provided that the above copyright notice and this paragraph 1934 are included on all such copies and derivative works. However, this 1935 document itself may not be modified in any way, such as by removing 1936 the copyright notice or references to the Internet Society or other 1937 Internet organizations, except as needed for the purpose of 1938 developing Internet standards in which case the procedures for 1939 copyrights defined in the Internet Standards process must be 1940 followed, or as required to translate it into languages other than 1941 English. 1943 The limited permissions granted above are perpetual and will not be 1944 revoked by the Internet Society or its successors or assigns. 1946 This document and the information contained herein is provided on an 1947 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1948 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1949 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1950 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1951 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1953 D.Papadimitriou - Internet Draft � Expires May 2002 38