idnits 2.17.1 draft-bellato-ccamp-g709-framework-00.txt: -(80): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(116): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(732): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(789): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(790): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(791): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(837): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(985): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1187): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1196): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1206): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1210): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1215): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1219): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1370): 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 62 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 26 longer pages, the longest (page 6) 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], [GMPLS-SIG]), 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: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 2001) is 8351 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 23 -- Looks like a reference, but probably isn't: '2' on line 41 == Missing Reference: 'ITUT-G.962' is mentioned on line 154, but not defined == Missing Reference: 'ITUT-G959.1' is mentioned on line 284, but not defined == Missing Reference: 'ITUT-G.872' is mentioned on line 289, but not defined -- Looks like a reference, but probably isn't: '0' on line 1065 -- Looks like a reference, but probably isn't: '4' on line 1065 -- Looks like a reference, but probably isn't: '20' on line 1065 == Missing Reference: 'ITUT-G.709' is mentioned on line 1155, but not defined == Unused Reference: 'ITUT-G707' is defined on line 1184, but no explicit reference was found in the text == Unused Reference: 'ITUT-G962' is defined on line 1193, but no explicit reference was found in the text == Unused Reference: 'ITUT-GASTN' is defined on line 1196, but no explicit reference was found in the text == Unused Reference: 'ITUT-GASON' is defined on line 1199, but no explicit reference was found in the text == Unused Reference: 'GMPLS-LDP' is defined on line 1206, but no explicit reference was found in the text == Unused Reference: 'GMPLS-RSVP' is defined on line 1210, 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' -- Possible downref: Normative reference to a draft: ref. 'GMPLS-ARCH' == Outdated reference: A later version (-07) exists of draft-ietf-mpls-generalized-cr-ldp-03 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-rsvp-te-03 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-generalized-signaling-04 == Outdated reference: A later version (-08) exists of draft-ietf-ccamp-gmpls-sonet-sdh-00 Summary: 9 errors (**), 0 flaws (~~), 18 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Alberto Bellato (Alcatel) 3 Category: Internet Draft Michele Fontana (Alcatel) 4 Expiration Date: December 2001 Germano Gasparini (Alcatel) 5 Gert Grammel (Alcatel) 6 Jim Jones (Alcatel) 7 Zhi-Wei Lin (Lucent) 8 Eric Mannie (Ebone) 9 Dimitri Papadimitriou (Alcatel) 10 Siva Sankaranarayanan (Lucent) 11 Maarten Vissers (Lucent) 13 June 2001 15 G.709 Optical Transport Networks GMPLS Control Framework 17 draft-bellato-ccamp-g709-framework-00.txt 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026 [1]. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. Internet-Drafts are draft documents valid for a maximum of 28 six months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet- Drafts 30 as reference material or to cite them other than as "work in 31 progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Conventions used in this document: 38 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 39 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 40 this document are to be interpreted as described in RFC-2119 [2]. 42 D.Papadimitriou - Internet Draft � Expires December 2001 1 43 Abstract 45 Along with the current development of packet over lambda switching 46 (referred to as MPLambdaS), there are considerable developments in 47 optical transport systems based on the ITU-T G.872 [ITUT-G872] and 48 G.709 [ITUT-G709] specification. The Optical Transport Network (OTN) 49 defined in G.872 and G.709 enables ultra-long-haul transmission of 50 various client signal types through the use of Forward Error 51 Correction (FEC) bytes. G.709 specifies the data plane transport 52 structure and allocates overhead bytes for the OTN control plane. 54 In this document, we describe the G.709 Digital and Optical 55 Transport Hierarchies (OTH) defined at the ITU-T and the 56 relationships with the current GMPLS specification [GMPLS-ARCH]. 57 This in order to specify how current GMPLS Signalling specification 58 [GMPLS-SIG] can be accommodated in order to encompass these 59 hierarchies to extend GMPLS signalling for OTN. 61 1. Introduction 63 Recently, the ITU-T finalized the first version of the Optical 64 Transport Networks (OTN) standardization [ITUT-G709] to provide the 65 transparent digital pipe (digital wrapper) to be transported into 66 optical channels. 68 The OTN provides two fundamental degrees of flexibility: in terms of 69 wavelength and in terms of bandwidth transmission optimization 70 without losing the integrity of the lower bit rates pipes filled by 71 the access network. From that perspective, the OTN specification 72 enables as well the control of all-optical sub-networks. 74 However, the OTN architecture has today no explicit association with 75 any IP-based control plane, without which the future deployment of 76 OTN equipment is clearly uncertain. Therefore, [ITUT-G709] foresees 77 a strong requirement for future evolutions that can provide explicit 78 support for the OTN control layer. Requirements for the definition 79 of the OTN control plane (also referred to as Automatic Switched 80 Transport Network � ASON) are currently under definition at the ITU- 81 T. 83 Consequently, Generalized MPLS (GMPLS) as specified in [GMPLS-SIG], 84 can more than certainly provide the efficient "control-plane 85 service" needed by the OTN specifications. Moreover, GMPLS can give 86 fundamental indications in terms of how OTN can be controlled and 87 where some additional features have to added (if needed) at the 88 optical transmission layer level, in order to hit the goal of 89 intelligent optical networks. 91 Today, GMPLS efforts are directed in extending IP well known 92 technology to control and manage lower non-packet based layered 93 networks. Using the same framework and the same kinds of signalling 94 and routing protocols suite to control multiple layers will not only 95 reduce the overall complexity of designing, deploying and 97 D.Papadimitriou - Internet Draft � Expires December 2001 2 98 maintaining OTN networks but also allow potentially two contiguous 99 layers to inter-operate when using either an overlay, an augmented 100 or a peer model. In the mean time, GMPLS is very suitable for 101 controlling each layer completely independently. 103 Moreover, GMPLS can provide new capabilities and features for OTN 104 such as flexible and distributed LSP establishment (today performed 105 through the use of centralized Network Management Systems - NMS), 106 multi-layer circuit establishment and GMPLS-based restoration 107 methods that are of paramount importance for operators and carriers. 109 2. Current Solutions 111 In this section, we describe the G.709 specification foundations. 113 2.1 Pre-OTN DWDM Development 115 ITU-T G.709 describes also pre-OTN WDM development for backward 116 compatibility with state of the art equipment�s. Pre-OTN development 117 has generated the current OTN development at the ITU-T but also the 118 current MPLambdaS and All-optical developments at the IETF for the 119 next generation optical networks. 121 Pre-OTN DWDM has been developed during the last years in order to 122 overcome the bandwidth limitations and increase the bit-rate per 123 fiber until several Tbps per fiber. Tomorrow, pre-OTN DWDM systems 124 will provide up to 1000 wavelengths at 2.5 Gbps (or 500 x 10 Gbps or 125 250 x 40 Gbps) per fiber. This development includes the definition 126 of point-to-point DWDM optical channels on top of a mesh optical 127 topology including Optical Cross-Connects (OXC) or Photonic Cross- 128 Connects (PXC). A PXC is defined as an all-optical device (i.e. no 129 O/E) and an OXC as a bit-rate transparent device (i.e. it provides 130 O/E/O conversion at each interface). 132 The signalling paradigm developed for Lambda-switched LSP-capable 133 networks has been included of the MPLS signalling paradigm. The MPLS 134 generalization for fiber (space switching) lambda (wavelength 135 switching), TDM (circuit switching) and packet LSPs (packet 136 switching) is referred to as Generalized MPLS [GMPLS-SIG]. 138 The current bandwidth bottleneck is overcome by the use of DWDM 139 systems. DWDM systems allow the multiplexing of more than 160 140 wavelengths of 10 Gbps (1.6 Tbps per fiber with a 25 GHz spacing) by 141 using simultaneously both the C-band and the L-band. Today, some 142 vendors are proposing a lambda spacing of 12.5 GHz. Consequently, it 143 will be possible to house 320 wavelengths of 10 Gbps in a single 144 fiber (for a total throughput of 3.2 Terabits per fiber). 146 A complementary method for increasing the effective capacity of a 147 DWDM system is to include the 1480nm (S-Band) and 1650nm (U-Band) 148 together with the deployment of fibers covering an ultra-wide 149 waveband from 1460 to 1675nm (i.e. from the S-Band to the U-Band). 151 D.Papadimitriou - Internet Draft � Expires December 2001 3 152 Nevertheless, the ITU-T currently refers to 50 GHz spacing within 153 the so-called ITU-T Grid, and in order to guarantee line interface 154 interoperability, [ITUT-G.962] recommends 200 GHz wavelength 155 spacing. 157 In the pre-OTN application, client signals (STM-N, STS-N, GbE, IP, 158 etc.) are directly mapped on wavelength through the use of a 159 mapping-framing variable-length layer. This means that this 160 development does not include G.709 client-signal mapping 161 specification through the definition of a dedicated framing 162 protocol. 164 Moreover, additional standard Transparency levels to the one defined 165 for SONET/SDH networks are defined for pre-OTN networks. 167 2.2 OTN Standard 169 Optical networks include a set of functionality providing transport, 170 multiplexing, routing, supervision and survivability of client 171 signals that are processed predominantly in the optical domain. 172 Optical signals are characterized by wavelength and may be processed 173 per wavelength or as a wavelength division multiplexed group. 175 The OTN model is decomposed into independent (transport) network 176 layers where each layer can be separately partitioned in a way that 177 reflects its internal structure. So that the OTN model refers to a 178 layered structure comprising a Digital and an Optical Transport 179 Hierarchy (OTH). The latter is constituted by the following network 180 layers: 182 - Optical Transmission Section (OTS) layer: This network layer 183 provides functionality for transmission of optical signals on 184 optical media of various types. This layer ensures the integrity 185 and maintenance of the optical transmitted signal by overhead 186 processing 188 - Optical Multiplex Section (OMS) layer: This network layer provides 189 functionality for networking of a multi-wavelength optical signal. 190 A "multi-wavelength" signal includes the case of just one optical 191 channel. This layer ensures the integrity and maintenance of the 192 multi-wavelength signal by overhead processing. 194 - Optical Channel (OCh) layer: this network layer provides end-to- 195 end networking of optical channels for transparently conveying 196 client information of various formats (e.g. SDH STM-N, Sonet OC-N, 197 ATM, IP, etc.). The capabilities of this network layer concern 198 With connection rearrangement for flexible routing, overhead 199 processing, administration and maintenance functions. 201 For the three layers specified above, non-associated overhead is 202 transported via the Optical Supervisory Channel (OSC) in order to 203 manage the optical connectivity. It has to be noted that these three 204 layers are common to both pre-OTN and OTN applications. 206 D.Papadimitriou - Internet Draft � Expires December 2001 4 207 As far as the client signal handling is concerned, the Digital 208 Wrapper layer is further layered as follows: 209 - The Optical Channel Transport Unit (OTUk) provides FEC 210 capabilities and optical section protection and monitoring 211 capabilities. 212 - The Optical Channel Data Unit (ODUk) layer provides client 213 independent connectivity, connection protection and monitoring 214 (also without the need to terminate the overhead information, 215 the ODUk overhead may be monitored non-intrusively). 216 - Clients signals i.e. STM-N signals, IP packets, ATM cells and 217 Ethernet frames are mapped (meaning digitally wrapped) into a new 218 structured frame defined as Optical Channel Payload Unit (OPUk). 220 For each of the three layers specified above, an associated (in- 221 band) overhead carrying the management information is added inside 222 the framed structure itself. Notice, that only the ODUk (k= 1, 2, 3) 223 and OCh are defined today as networking layers. The OTN layered 224 transport structure can be schematically represented as follows: 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== 227 | OCh Payload Unit (OPUk) | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- 229 | OCh Data Unit (ODUk) | Digital Path Layer 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- 231 | OCh Transport Unit (OTUk) | Digital Section Layer 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== 233 | Optical Channel Layer (OCh) | 234 +-----------------------------------+ Optical Channel Layer 235 | Optical Channel Multiplexing | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== 237 | Optical Multiplex Section OMS | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Physical Section 239 | Optical Transmission Section OTS | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== 242 The OPUk, ODUk and OTUk layers constitute the Digital Transport 243 Hierarchy also referred to as Digital Wrapper Layer. 245 The development of a digital and an optical transport hierarchy 246 (i.e. networking layer) is required for the following reasons: 247 - It is the next step (after TDM - SDH/SONET) to support ever 248 growing data driven needs for bandwidth and emergence of new 249 broadband services 250 - To support next generation Terabit/second per fiber via DWDM lines 251 at the transport level as well as optical channels at 2.5 Gbps, 10 252 Gbps and 40 Gbps bit rates at wire speed level (and in the future 253 160 Gbps currently under definition) 254 - To provide network operational management, planning, 255 administration, survivability, and finally cost of maintenance 256 limited only to the OTUk/ODUk rates of transmission without caring 257 about the granularity of the client signal. 259 The OTN Specification is described in details in the next section. 261 D.Papadimitriou - Internet Draft � Expires December 2001 5 262 4. Optical Transport Networks Specification 264 The OTN specifies an Optical Transport Hierarchy (OTH) supporting 265 the operation and management aspects of optical networks of various 266 architectures such as point-to-point, ring and mesh architectures. 268 The G.709 specification defines the interfaces of the OTN to be used 269 within and between sub-networks of the optical network, in terms of: 270 - Optical Transport Hierarchy (OTH) 271 - functionality of the overhead in support of multi-wavelength 272 optical sub-networks 273 - frame structures 274 - bit rates 275 - formats for mapping client signals 277 The OTN interfaces specifications can be applied at User to Network 278 Interfaces (UNI) and Network Node Interfaces (NNI) of the OTN. The 279 overhead functionality necessary for operations and management of 280 optical sub-networks is also defined. For interfaces used within 281 optical sub-networks, the aspects related to the interface depend on 282 the optical technology progress and so are not covered by G.709 283 recommendation. This is within the scope of other ITU-T 284 recommendations [ITUT-G959.1]. 286 4.1 Optical Transport Hierarchy (OTH) 288 The Optical Transport Hierarchy (OTH) structure is defined as 289 specified in [ITUT-G.872] that defines the Optical Channel (OCH) 290 layer. The OTH further sub-structured the OCh layer in sub-layer 291 networks in order to support the network management and supervision 292 functions such as: 294 - The Optical Channel with full (OCh) or reduced functionality 295 (OChr), provides transparent network connections between 3R 296 regeneration points in the OTN. 298 - The fully standardized Optical Channel Transport Unit-k (OTUk) 299 which provides supervision and conditions the signal for transport 300 between regeneration points in the OTN (1R, 2R and for pre-OTN 301 only, 3R). 303 - The Optical Channel Data Unit (ODUk) which provides 304 . tandem connection monitoring (ODUk-TCM), 305 . end-to-end path monitoring (ODUk-PM) 307 - The Optical Channel Payload Unit (OPUk) which provides adaptation 308 of client signals 310 The Optical Transport Module-n (OTM-n) is the information structure 311 used to support OTN interfaces. Two OTM-n structures are defined: 312 - OTM interfaces with full functionality (OTM-n.m) 313 - OTM interfaces with reduced functionality (OTM-0.m, OTM-nr.m) 315 D.Papadimitriou - Internet Draft � Expires December 2001 6 316 The reduced functionality OTM interfaces are defined with 3R 317 processing at each end of the OTN. 319 4.1.1 Full Functional Stack: OTM-n.m 321 With a full functional stack (OTM-n.m), up to n OCC are multiplexed 322 into an OCG-n.m using wavelength division multiplexing. The OCC 323 tributary slots of the OCG-n.m can be of different size depending on 324 the value of the index m (m = 1, 2, 3, 12, 23 or 123). The OCG-n.m 325 is transported via the OTM-n.m. 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | OCh Payload Unit OPUk | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 330 | OCh Data Unit ODUk | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | OCh Transport Unit OTUk | ---------------------------- 333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Boundary 334 | Optical Channel Layer OCh | ---------------------------- 335 +-------------------------------------+ 336 | Optical Channel Carrier (OCC) | ^ 337 +-------------------------------------+ | Wavelength Multiplexing 338 | Optical Carrier Group (OCG-n.m) | v 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Optical Multiplex Section OMSn | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | Optical Transmission Section OTSn | 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 OTM-n.m (n > 1) 346 For the case of the full functional OTM-n.m interfaces, the OSC is 347 multiplexed into the OTM-n.m using wavelength division multiplexing. 349 4.1.2 Reduced Functionality Stack: OTM-0.r and OTM-nr.m 351 The OTM with reduced functionality could be either 352 - OTM-0: consists of a single optical channel without a specific 353 wavelength assigned (see Figure) 354 - OTM-nr.m: consists of up to n multiplexed optical channels. Non 355 associated overhead is not supported (see Figure) 357 The OTM-nr.m/OTM-0.m is the information structure used to support 358 Optical Physical Section (OPS) layer connections in the OTN. 360 The order of an OTM-nr is defined by the order of the OCG-nr that it 361 supports. Note that the first version of G.709, only includes 362 reduced functionality for standardized inter-domain interfaces 363 (IrDI). 365 1. OTM-nr.m 367 D.Papadimitriou - Internet Draft � Expires December 2001 7 368 Up to n OCCr are multiplexed into an OCG-nr.m using wavelength 369 division multiplexing. The OCCr tributary slots of the OCG-r.m can 370 be of different size (m = 1, 2, 3, 12, 23 or 123). The OCG-nr.m is 371 transported via the OTM-nr.m. 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | OCh Payload Unit (OPUk) | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | OCh Data Unit (ODUk) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | OCh Transport Unit (OTUk) | ---------------------------- 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Boundary 380 | Optical Channel Layer (OChr) | ---------------------------- 381 +-------------------------------------+ 382 | Optical Channel Carrier (OCCr) | ^ 383 +-------------------------------------+ | Wavelength Multiplexing 384 | Optical Carrier Group (OCG-nr.m) | v 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 386 | | 387 | Optical Physical Section (OPSn) | 388 | | 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 OTM-nr.m (n > 1) 392 2. OTM-0r.m (OTM-0.m) 394 Only one OCCr tributary slot is provided so that the OCG-0r.m is not 395 defined. Consequently, reduced functionality OTM-0r.m stack does not 396 support wavelength division multiplexing functionality. The OCCr 397 tributary slot can be of different size (m = 1, 2 or 3). The OCCr is 398 transported via the OTM-0.m. 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | OCh Payload Unit (OPUk) | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 | OCh Data Unit (ODUk) | 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | OCh Transport Unit (OTUk) | ---------------------------- 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Boundary 407 | Optical Channel Layer (OChr) | ---------------------------- 408 +-------------------------------------+ 409 | Optical Channel Carrier (OCCr) | 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | | 412 | Optical Physical Section (OPS0) | 413 | | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 OTM-0.m (n = 0) 417 4.2 Optical Channel Encapsulation 419 D.Papadimitriou - Internet Draft � Expires December 2001 8 420 An overhead is associated to the OPUk, the ODUk and the OTUk 421 signals. Moreover, the OTUk signal can include a tailer FEC. 423 As not indicated in the following figure, the control non-associated 424 overhead at the lower OCh level is multiplexed within the OTM 425 Overhead Signal (OOS) and then inserted to the OSC. The OOS is the 426 information structure used for transport of OTM non-associated 427 overhead over the OSC. The non-associated overhead consists of the 428 Optical Transmission Section (OTS) overhead, Optical Multiplex 429 Section (OMS) overhead and Optical Channel (OCh) non-associated 430 overhead; it is characterized by its frame structure, bit rate and 431 bandwidth. 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 | Client PDU | 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 . . 437 . . 438 . . 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 |OH | OCh Payload Unit Payload (OPUk) | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 |OH | OCh Data Unit Payload (ODUk) | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 |OH | OCh Transport Unit Payload (OTUk) | FEC | 445 +===============================================+=====+ 446 . . 447 . . 448 . . 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Optical Channel Layer | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 . / 453 . -------------------------------------------- 454 . / 455 +-------+ +-------+ +-------+ +-------+ +-------+ 456 | OCC | | OCC | | OCC | | OCC | | OCC | 457 +-------+ +-------+ +-------+ +-------+ +-------+ 458 . . . . . . . . . . 459 . . . . . . . . . . 460 . . . . . . . . . . 461 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+ 462 | Optical Multiplex Section OMSn | | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPS | 464 | Optical Transport Section OTSn | | | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+ 467 The optical channel network-layer overhead bytes defined in [ITUT- 468 G.709] support the following capabilities: 469 - Forward Error Correction (FEC) 470 - Performance Monitoring (PM) 471 - Network Fault localization 472 - Network Restoration Signaling 474 D.Papadimitriou - Internet Draft � Expires December 2001 9 475 - Network General Communications Channels (GCC) 476 - Manufacturer-Specific Communications Channel 478 4.3 Signal Types 480 Signal types defined by the [ITUT-G709] specification can be divided 481 in Optical Channel Unit layer and Optical Transport Module (OTM). 482 The Payload Unit layer can itself be sub-divided in OCh Payload 483 Unit, OCh Data Unit and OCh Transport Unit. The Appendix 2 describes 484 the indexes used within the [ITUT-G709] terminology. 486 4.3.1 OPUk Signal 488 Optical channel Payload Unit (OPU) is defined as a structured signal 489 of order k (k = 1, 2, 3) and referred to as OPUk signal. The OPUk 490 frame structure is organized in an octet based block frame structure 491 with 4 rows and 3810 columns. The two main areas of the OPUk frame 492 (4 x 3810 Bytes) are the OPUk Overhead area (column 15 and 16) and 493 OPUk Payload area (columns 17 to 3824). 495 4.3.2 ODUk Signal 497 Optical channel Data Unit (ODU) is defined as a structured signal of 498 order k (k = 1, 2, 3) and referred to as ODUk signal. The ODUk frame 499 structure is organized in an octet based block frame structure with 500 4 rows and 3824 columns. The two main areas of the ODUk frame are 501 ODUk Overhead area (columns 1 to 14 with column 1 dedicated to FA 502 and OTUk specific alignment) and OPUk area (Columns 15 to 3824 which 503 are dedicated to the OPUk area). 505 4.3.3 OTUk Signal 507 Optical channel Transport Unit (OTU) of order k (k = 1, 2, 3) 508 defines the conditioning for transport over an Optical Channel 509 network connection. This signal is referred to as OTUk signal. The 510 OTUk (k=1,2,3) frame structure is based on the ODUk frame structure 511 and extends it with a forward error correction (FEC). Scrambling is 512 performed after FEC computation and insertion into the OTUk signal. 514 In the OTUk signal, 256 columns are added to the ODUk frame for the 515 FEC and the reserved overhead bytes in row 1, columns 9 to 14 of the 516 ODUk overhead are used for OTUk specific overhead, resulting in an 517 octet based block frame structure with 4 rows and 4080 columns (4 x 518 4080 bytes). 520 4.3.4 OTM Interface Signal 522 The OTM-n interface signal supports n optical channels on a single 523 fiber with 3R regeneration and termination of the OTUk signal on 524 each end. As 3R regeneration is performed on both sides of the OTM- 525 0.m and OTM-nr.m interfaces access to OTUk overhead is available and 526 maintenance as well as supervision of the interface is provided via 527 this overhead. Therefore non-associated OTM overhead is not required 529 D.Papadimitriou - Internet Draft � Expires December 2001 10 530 across the OTM-0.m and OTM-nr.m interfaces. Consequently, Optical 531 Supervisory Channel (OSC) and OTM Overhead Signal (OOS) are not 532 supported. 534 In the first G.709 version, only two OTM interfaces classes with 535 reduced functionality are defined: OTM-0.m and OTM-16r.m. 537 1. OTM-16r.m Interface 539 The OTM-16r.m interface supports 16 Optical Channels (n = 16) on a 540 single optical span with 3R regeneration at each end. Six OTM-16r.m 541 interface signals are currently defined (m = 1, 2, 3, 12, 23, 123). 543 The OTM-16r.m signal is an OTM-nr.m signal with 16 Optical Channel 544 Carriers (OCCr) numbered OCCr #0 to OCCr #15. An Optical OSC is not 545 present and there is no OOS either. 547 For instance, the OTM16 can be separated in several cases: 548 - the OTM-16r.1 (with up to 16 wavelengths only at 2.5 Gbps) 549 - the OTM-16r.2 (with up to 16 wavelengths only at 10 Gbps) 550 - the OTM-16r.3 (with up to 16 wavelengths only at 40 Gbps) 551 - the OTM-16r.m (with up to 16 wavelengths mixing possibly bit- 552 rates) 554 At least one of the OCCr is in service during normal operation and 555 transporting an OTUk. However, there is no predefined order in which 556 the OCCr�s are taken into service. 558 Note: OTM-16r.m OPS overhead is not defined. The interface will use 559 the OTUk SMOH in this multi-wavelength interface for supervision and 560 management. OTM-16r.m connectivity failure (TIM) reports will be 561 computed from the individual OTUk reports by means of failure 562 correlation in fault management. 564 2. OTM-0.m Interface 566 The OTM-0.m supports a single wavelength optical channel on a single 567 optical fiber with 3R regeneration at each end. Three OTM-0.m 568 interface signals are defined (with m = 1, 2, 3), each carrying a 569 single channel optical signal containing one OTUk (with k = 1, 2, 3) 570 signal. There is neither OSC defined nor OOS for OTM-0.m. 572 4.4 ODUk Mapping and Multiplexing 574 Since G.709 defines at the Optical Channel layer three distinct 575 client payload bit rates, an Optical Channel Data Unit (ODU) frame 576 has been defined for each of these bit rates. An ODUk refers to a 577 bit rate k framing signal, where k = 1 (for 2.5 Gbps), 2 (for 10 578 Gbps) or 3 (for 40 Gbps). 580 ODUk Multiplexing will be included in the future release of G.709 581 [ITUT-G709] while ODUk Mapping can be considered as the basic 582 mechanism underlying the Digital Transport Hierarchy layered 584 D.Papadimitriou - Internet Draft � Expires December 2001 11 585 structure. Note that ODUk and OTUk layers still remain in the 586 electrical domain and are referred to as Digital Path and Digital 587 Section in the ITU-T G.709 recommendation. 589 4.4.1 ODUk Mapping 591 By definition in ODUk mapping, the client signal is mapped into the 592 OPUk. The OPUk is mapped into an ODUk and the ODUk is mapped into an 593 OTUk. The OTUk is mapped into an OChr and the OChr is then modulated 594 onto an OCCr. 596 The ODUk mapping is described by the following figure: 598 x1 x1 599 OTU3 <---- ODU3 <---- OPU3 <--------------------------- Client PDU 601 x1 x1 602 OTU2 <--------------- ODU2 <---- OPU2 <---------------- Client PDU 604 x1 x1 605 OTU1 <-------------------------- ODU1 <---- OPU1 ------ Client PDU 607 4.4.2 ODUk Multiplexing 609 By definition of ODUk multiplexing, an ODUk (or ODUk Tributary Unit 610 Group) is mapped into the OPU[k+1] if k = 1 or 2 or OPU[k+2] if k = 611 1. The resulting OPUk is mapped into an ODUk and the ODUk is mapped 612 into an OTUk. The OTUk is mapped into an OChr and the OChr is then 613 modulated onto an OCCr. 615 Therefore, two levels of ODUk multiplexing can be defined: 616 - ODU1 multiplexing: 617 . four ODU1 are multiplexed into one OPU2 which is mapped into one 618 ODU2 619 . sixteen ODU1 are multiplexed into one OPU3 which is mapped into 620 one ODU3 621 - ODU2 multiplexing: 622 . four ODU2 are multiplexed into one OPU3 which is mapped into 623 one ODU3 625 For instance, when multiplexing four ODU1 signals into an ODU2. The 626 ODU1 signals including the Frame Alignment OH and an all-0's pattern 627 in the OTUk Overhead locations are scrambled and then adapted to the 628 ODU2 clock via justification (asynchronous mapping). These adapted 629 ODU1 signals are byte interleaved into the OPU2 Payload area, and 630 their justification control and opportunity signals are frame 631 interleaved into the OPU2 Overhead area. ODU2 Overhead is added 632 after which the ODU2 is mapped into the OTU2. OTU2 Overhead and 633 Frame Alignment Overhead are added to complete the signal for 634 transport via an OTM signal. 636 D.Papadimitriou - Internet Draft � Expires December 2001 12 637 The ODUk multiplexing is described by the following figure: 639 x1 x1 640 OTU3 <---- ODU3 <---- OPU3 <---------------------------- Client PDU 641 | <-- 642 x4| |x16 643 x1 | | 644 OTU2 <--------------- ODU2 <----- OPU2 <---------------- Client PDU 645 | | 646 | |x4 647 x1 -- | x1 648 OTU1 <--------------------------- ODU1 <---- OPU1 ------ Client PDU 650 4.4.3 ODUk Inverse Multiplexing 652 Inverse multiplexing is currently under specification at the ITU-T. 653 It should be implemented by means of virtual concatenation of two or 654 more than two ODUk signals (defined as ODUk-Xv). The ODUk-Xv signal 655 can transport a non-OTN client signal (for instance, an ODU2-4v may 656 transport an STM-256). 658 The characteristic information of a virtual concatenated ODUk (ODUk- 659 Xv) layer network is transported via a set of X ODUk LSP, each LSP 660 having its own transfer delay. The egress LSR terminating the ODUk- 661 Xv LSP has to compensate this differential delay in order to provide 662 a contiguous payload at the output. 664 4.5 Wavelength Division Multiplexing 666 With reduced stack functionality: up to n (n >= 1) OCCr are 667 multiplexed into an OCG-nr.m using wavelength division multiplexing. 668 The OCCr tributary slots of the OCG-nr.m can be of different size. 669 The OCG-nr.m is transported via the OTM-nr.m. 671 x1 x1 672 -------- OCCr <-------- OChr <-------- OTU3 673 | 674 |xi 675 x1 | xj x1 x1 676 OTM-nr.m <------- OCG-nr.m <----- OCCr <-------- OChr <-------- OTU2 677 | 678 |xk 679 | x1 x1 680 -------- OCCr <-------- OChr <-------- OTU1 682 with 1 =< i + j + k =< n 684 With full stack functionality: up to n (n >= 1) OCC are multiplexed 685 into an OCG-n.m using wavelength division multiplexing. The OCC 686 tributary slots of the OCG-n.m can be of different size. The OCG-n.m 687 is transported via the OTM-n.m. 689 D.Papadimitriou - Internet Draft � Expires December 2001 13 690 x1 x1 691 --------- OCC <-------- OCh <-------- OTU3 692 | 693 |xi 694 x1 | xj x1 x1 695 OTM-n.m <------- OCG-n.m <------ OCC <-------- OCh <-------- OTU2 696 | | 697 | |xk 698 | | x1 x1 699 | --------- OCC <-------- OCh <-------- OTU1 700 | 701 | x1 702 -------------- OSC <------ OOS (OTS, OMS, OCh OH) 704 with 1 =< i + j + k =< n 706 For the case of the full functionality OTM-n.m interfaces the OSC is 707 multiplexed into the OTM-n.m using wavelength division multiplexing. 709 4.6 Client Signal Mapping 711 The specification of the Client-layer signal encapsulation in the 712 OPU layer has been provided through the definition of different 713 solutions depending upon the type of Client-layer signal. 715 IP and Ethernet packet mapping is defined by the G.709 specification 716 through the use of the Generic Framing Procedure (GFP). This (new) 717 framing has been specified in order to avoid the use of Ethernet 718 framing or SDH/Sonet in order to encapsulate IP packets and other 719 types of packet (such as ESCON, Fiber Channel, etc.). 721 GFP is defined as a generic mechanism to transport any client layer 722 over a fixed data-rate optical channels (specifically, the so-called 723 OTN ODU of unit-k). This means that GFP idle frames must be 724 generated when the client layer does not send data packet. 725 Consequently the service offered to the client packet layer is 726 strictly equivalent to the one offered in SDH. 728 The Generic Framing Procedure (GFP) frame format is defined as: 730 +----------+--------------------------------------------+----------+ 731 | Header | Payload | FCS | 732 | 4 bytes | 4 � 65535 bytes | Optional | 733 +----------+--------------------------------------------+----------+ 735 The header (4-bytes) is composed by a PDU Length Indicator (PLI) of 736 2 bytes and a HEC (Header Error Control) of 2 bytes. 738 The GFP Idle frame format, which includes a NULL PLI and a HEC of 2 739 bytes, is defined as: 741 D.Papadimitriou - Internet Draft � Expires December 2001 14 742 +----------+ 743 |Idle Frame| 744 | 4bytes | 745 +----------+ 747 GFP defines also two basic frame-oriented mechanisms: 749 1. GFP Frame Multiplexing: the GFP frame multiplexing is performed 750 on a frame-by-frame basis. When no frames are waiting, idle 751 frames are inserted. 753 2. GFP Frame Delineation Algorithm: as defined for cell delineation, 754 GFP frame delineation is based on the detection of correct HEC. 755 PLI is used to find the start of the next frame. 757 The GFP frames constitute the OPUk payload. The corresponding OPUk 758 overhead is defined as follows by the Payload Structure Identifier 759 (PSI) which includes the following fields: 760 - PT: Payload Type (1-byte) 761 - RES: Reserved (254-bytes) 763 The GFP OPUk (k = 1, 2, 3) capacity are defined such that they can 764 include the following client bit rates: 765 - GFP (OPU1): 2 488 320 kbit/s 766 - GFP (OPU2): 9 995 276 kbit/s 767 - GFP (OPU3): 40 150 519 kbit/s 769 Aligning the byte structure of every GFP frame with the byte 770 structure of the OPUk Payload performs the mapping of GFP frames. 771 Since the GFP frames are of variable length (the mapping does not 772 impose any restrictions on the maximum frame length), a frame may 773 cross the OPUk frame boundary. 775 GFP frames arrive as a continuous bit stream (Idle frames when no 776 client packets) with a capacity that is identical to the OPUk 777 payload area, due to the insertion of Idle frames at the GFP 778 encapsulation stage. Note that here, the GFP frame stream is 779 scrambled during encapsulation. 781 As currently defined in [ITUT-G709], GFP provides also ATM Constant 782 Bit Rate (CBR) � by using ATM cell multiplexing - and TDM Circuits 783 Encapsulation and mapping into the OPUk payload area. 785 5. GMPLS Extensions for G.709 787 Adapting GMPLS to control G.709 can be achieved by considering that 788 G.709 defines two transport hierarchies: a digital hierarchy (also 789 known as the �Digital Wrapper�) and an optical transport hierarchy. 790 First, within the digital hierarchy (the previously defined �Digital 791 Wrapper�), a Digital Path Layer is defined. Then, within the optical 792 transport hierarchy, an Optical Channel layer or Optical Path layer 793 including a digital OTM Overhead Signal (OOS), i.e. a non-associated 794 overhead, is defined. 796 D.Papadimitriou - Internet Draft � Expires December 2001 15 797 GMPLS extensions for G.709 need to cover the Generalized Label 798 Request, the Generalized Label as well as specific technology 799 dependent fields such as those currently assigned to the SDH/Sonet 800 labels [GMPLS-SSS]. Since the multiplexing in the electrical domain 801 (such as ODUk multiplexing) will be added very soon into the next 802 version of the G.709 recommendation, we can already specify a label 803 space definition suitable for that purpose. 805 As implicitly specified in GMPLS control for SDH/SONET Networks 806 [GMPLS-SSS], since GFP is only used as a framing protocol we don�t 807 consider this framing layer to be included into the G.709 label 808 space. Rather, we directly use the G.709 digital and optical 809 transport hierarchies in order to define the corresponding label 810 spaces. 812 5.1 G.709 Label Request Considerations 814 The Generalized Label Request as defined in [GMPLS-SIG], includes a 815 technology independent part and a technology dependent part (i.e. 816 the traffic parameters). 818 5.1.1 Technology Independent Part 820 As defined in [GMPLS-SIG], the LSP Encoding Type and the Generalized 821 Protocol Identifier (G-PID) constitute the technology independent 822 part. As mentioned here above, we suggest here to adapt the LSP 823 Encoding Type and the G-PID (Generalized-PID) to accommodate G.709 824 recommendation [ITUT-G709]. 826 1. LSP Encoding Type 828 Since G.709 defines two networking layers (ODUk layers and OCh 829 layer), the LSP Encoding Type can reflect these two layers or be 830 considered as a common layer: 832 - If an LSP Encoding Type is specified per networking layer or more 833 precisely per group of functional networking layer (i.e. ODUk and 834 OCh), then the Signal Type must not reflect these layers. This 835 means that two LSP Encoding Types have to defined: 836 . one reflecting the digital hierarchy (also referred to as the 837 �Digital Wrapper� layer) through the definition of the digital 838 path layer i.e. the ODUk layers 839 . the other reflecting the Optical Transport Hierarchy through the 840 definition of the optical path layer i.e. the OCh layer 842 - If the LSP Encoding Type is considered as a common space for G.709 843 meaning that the LSP Encoding Type doesn�t reflect the two G.709 844 hierarchies, then the Signal Type must reflect these layers. This 845 means that at least four Signal types must be defined: one for each 846 ODUk signal and one for the OCh signal 848 D.Papadimitriou - Internet Draft � Expires December 2001 16 849 In the latter case only one new code-point has to be defined for the 850 LSP Encoding Type while in the former case, two new code-points must 851 be defined. Therefore, the current "Digital Wrapper" code defined in 852 [GMPLS-SIG], could be replaced by two separated codes: 853 - code for the G.709 Digital Path layer 854 - code for the non-standard Digital Wrapper layer 856 In the same way, two separated code points could replace the current 857 defined �Lambda� code: 858 - code for the G.709 Optical Channel layer 859 - code for the non-standard Lambda layer (also simply referred to 860 as Lambda layer) which the pre-OTN Optical Channel layer 862 Moreover, the code for the G.709 Optical Channel (OCh) layer will 863 indicate the capability of an end-system to use the G.709 non- 864 associated overhead (naOH) i.e. the OTM Overhead Signal (OOS) 865 multiplexed into the OTM-n.m interface signal. 867 2. Generalized-PID 869 The Generalized-PID (G-PID) as defined in [GMPLS-SIG], identifies 870 the payload carried by an LSP. The G-PID, which defines the client 871 layer of that LSP, is used by the G.709 endpoints of the LSP. 873 As described in [ITUT-G709], the G-PID could take one of the 874 following values at the Digital Path layer, in addition to the 875 payload identifiers already defined in [GMPLS-SIG]: 876 - CBRa: asynchronous Constant Bit Rate i.e. STM-16/OC-48, STM- 877 64/OC-192 and STM-256/OC-768 878 - CBRb: bit synchronous Constant Bit Rate i.e. STM-16/OC-48, STM- 879 64/OC-192 and STM-256/OC-768 880 - ATM: Constant Bit Rate at 2.5, 10 and 40 Gbps 881 - BSOT: non-specific client Bit Stream with Octet Timing at 2.5, 10 882 and 40 Gbps 883 - BSNT: non-specific client Bit Stream without Octet Timing at 2.5, 884 10 and 40 Gbps 886 The G-PID defined in [GMPLS-SIG] are then used when the client 887 payloads are encapsulated through the GFP mapping procedure: 888 Ethernet, ATM Mapping and Packets (translated by PoS). Other G-PID 889 values not defined in [GMPLS-SIG] such as Escon and Fiber Channel 890 could complete in the near future the list of payload mapped by 891 using GFP mapping procedure. 893 In order to include pre-OTN developments, the G-PID at the Optical 894 Channel Layer can in addition to the G.709 Digital Path Layer (at 895 2.5 Gbps i.e. ODU1, 10 Gbps i.e. ODU2 and 40 Gbps i.e. ODU3) take 896 one of the values currently defined in [GMPLS-SIG], in particular: 897 - SDH: STM-16, STM-64 and STM-256 898 - Sonet: OC-48, OC-192 and OC-768 899 - Ethernet: 1 Gbps and 10 Gbps 901 5.1.2 Technology Dependent Part 903 D.Papadimitriou - Internet Draft � Expires December 2001 17 904 The technology dependent of the Generalized Label Request also 905 referred to as traffic-parameters must reflect the following G.709 906 features: ODUk mapping, ODUk multiplexing, OCh multiplexing, OTM 907 Overhead signal (OOS) and Transparency (only for pre-OTN). 909 1. Signal Type 911 As defined in [GMPLS-SSS], the traffic-parameters must include the 912 technology specific G.709 networking Signal Types i.e. the signals 913 processed by the GMPLS control-plane. The corresponding identifiers 914 reflect the signal types requested during the LSP setup. As 915 described in section 5.1, the following signal types must be 916 considered: ODU1, ODU2, ODU3 and (at least one) OCh. Obviously, pre- 917 OTN developments support only one OCh Signal Type value. 919 Note: Additional Signal Type code-points such as ODU4 (currently 920 under definition at the ITU-T) could also be reserved for future 921 considerations. 923 2. Multiplexing 925 A second field must indicate the type of multiplexing being 926 requested for ODUk LSP or OCh LSP. As defined in section 4.4, two 927 kinds of multiplexing are currently defined: flexible multiplexing 928 (or simply multiplexing) and inverse multiplexing. 930 At the ODUk layer (i.e. digital path layer), flexible multiplexing 931 as described in Section 4.4, refers to the mapping of an ODU2 into 932 four arbitrary OPU3 tributary slots (i.e. each slot containing one 933 ODU1) arbitrarily selected. Inverse multiplexing currently under 934 definition at ITU-T should also be considered. The requested 935 multiplexing type must include a default value indicating that 936 neither ODUk flexible multiplexing nor ODUk inverse multiplexing is 937 requested. 939 At the Optical Channel layer, flexible multiplexing is not defined 940 today while inverse multiplexing means that the requested composed 941 signal constitutes a waveband (i.e. an optical channel multiplex). A 942 waveband, denoted as OCh[j.k] (j >= 1) is defined as a non- 943 contiguous set of identical optical channels j x OCh, each of them 944 is associated to an OTM-x.m (x = nr or n) sub-interface signal. The 945 bit rate of each OCh constituting the waveband (i.e. the composed L- 946 LSP) must be identical, k is unique per OCh multiplex. 948 Note: today both OTN and Pre-OTN specifications do not define the 949 optical channel multiplex. Therefore, in this context, any waveband 950 switching development as defined in this specification is purely 951 vendor specific. 953 Consequently, since the number of identical components included in 954 an ODU multiplex or an OCh multiplex is arbitrary, a dedicated field 955 indicating the requested number of components must also be defined 957 D.Papadimitriou - Internet Draft � Expires December 2001 18 958 in order to reflect individual signals constituting the requested 959 LSP. 961 3. OTM Overhead Signal (OOS) 963 A dedicated field should indicate whether or not the non-associated 964 overhead is supported at the G.709 Optical Channel layer. This 965 feature is irrelevant at the G.709 Digital Path layer and the pre- 966 OTN Optical Channel layer if the latter does not support non 967 associated overhead (naOH). 969 This field should also not restrict the transport mechanism of the 970 OTM Overhead Signal (OOS) since in-fiber/out-of-band OSC and out-of- 971 fiber/out-of-band transport mechanisms are allowed. This field must 972 ideally support the following options: 974 - With OTM-0r.m and OTM-nr.m interfaces (reduced functionality 975 stack), OTM Overhead Signal (OOS) is not supported. Therefore with 976 these types of interface signals, non-associated OTM overhead 977 indication is not required. 979 - With OTM-n.m interfaces (full functionality stack), the OOS is 980 supported and mapped into the Optical Supervisory Channel (OSC) 981 which is multiplexed into the OTM-n.m using wavelength division 982 multiplexing. 984 - With OTM-n.m interfaces or even with OTM-0.m and OTM-nr.m 985 interfaces, �non-standard� OOS can be defined to allow for instance 986 interoperability with pre-OTN based devices or with any optical 987 devices which does not support G.709 OOS specification. This 988 specific OOS enables the use of any proprietary monitoring signal 989 exchange through any kind of supervisory channel (it can be 990 transport by using any kind of IP-based control channel). 992 4. Transparency 994 Transparency is only defined for pre-OTN developments since by 995 definition any signal transported over an OTN is fully transparent. 996 This feature is used to request a pre-OTN LSP (i.e. a non-standard 997 Lambda-LSP) including transparency support. It may also be used to 998 setup the transparency process to be applied in each intermediate 999 LSR. 1001 As it is commonly the case today with pre-OTN capable interfaces, 1002 three kinds of transparency levels are currently defined: 1004 - SONET/SDH Pre-OTN interfaces with RS/Section and MS/Line overhead 1005 transparency: the pre-OTN network is capable to transport 1006 transparently STM-N/OC-N signals. 1008 - SONET/SDH Pre-OTN interfaces terminating RS/Section overhead with 1009 MS/Line overhead transparency: the pre-OTN network is capable to 1010 transport transparently MSn signals 1012 D.Papadimitriou - Internet Draft � Expires December 2001 19 1013 - SONET/SDH Pre-OTN interfaces terminating RS/Section and MS/Line 1014 overhead: the pre-OTN network is capable to transport 1015 transparently HOVC/STS-SPE signals. 1017 Consequently, for pre-OTN Optical Channels a specific field (in the 1018 Generalized Label Request) must indicate the transparency level 1019 requested during the L-LSP setup. However, this field is only 1020 relevant when the LSP Encoding Type value corresponds to the Non- 1021 standard Lambda layer. 1023 5.2 G.709 Label Space 1025 The G.709 label space must include two sub-spaces: the first 1026 reflecting the digital path layer (i.e. the ODUk layers) and the 1027 second, the optical path layer (i.e. the OCh layer). 1029 5.2.1 ODUk Label Space 1031 At the Digital Path layer (i.e. ODUk layers), G.709 defines three 1032 different client payload bit rates. An Optical Data Unit (ODU) 1033 frame has been defined for each of these bit rates. ODUk refers to 1034 the frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps) 1035 or 3 (for 40 Gbps). 1037 In addition to the support of ODUk mapping into OTUk, the G.709 1038 label space must support the sub-levels of ODUk flexible 1039 multiplexing (or simply ODUk multiplexing): 1040 - ODU2 multiplexing: 1041 . The mapping of an ODU2 into four arbitrary OPU3 tributary 1042 slots selected arbitrarily (i.e. each slot containing one 1043 ODU1) 1044 - ODU3 multiplexing: 1045 . Not applicable today since higher order OPU tributary slots 1046 are not defined in the current [ITUT-G709] recommendation 1048 Defining three fields (k1, k2 and k3) self-consistently specifies 1049 the ODUk label space. The value space of the k1, k2 and k3 fields 1050 are defined as follows: 1051 - k1: indicates a particular ODU1 in one ODU2 (k1 = 1,..,4), ODU3 1052 (k1 = 5,..,20); k1 values from 21 to 84 are reserved for 1053 future use 1054 - k2: indicates a particular ODU2 in one ODU3 (k2 = 1,..,4); k2 1055 values from 5 to 20 are reserved for future use 1056 - k3: k3 values (k3 = 1,..,4) are reserved for future use 1058 If k1, k2 and k3 values are equal to zero, the corresponding ODUk 1059 are not structured, i.e. k[i]=0 (i=1,2,3) indicates that the ODU[i] 1060 is not structured and the ODU[i] is simply mapped into the OTU[i] as 1061 described in Section 4.4. 1063 D.Papadimitriou - Internet Draft � Expires December 2001 20 1064 Since k3 usage is not yet fully specified, k3 value always equals 1065 zero, k2 valid interval is [0,4] and k1 valid interval is [0,20]. 1066 Thus, when used in a G.709 Generalized Label: 1067 - k1: indicates a particular ODU1 in one ODU2 (k1 = 1,..,4) or in 1068 one ODU3 (k1 = 5,..,20) 1069 - k2: indicates a particular ODU2 in one ODU3 (k2 = 1,..,4) 1071 If k1 and k2 values are equal to zero means non-significant: a 1072 particular ODUk is not structured, i.e. ki=0 indicates that the ODUi 1073 in not structured. 1075 Examples: 1077 - k2=0, k1=0 indicates a full ODU3 (full 40 Gbps). 1078 - k2=0, k1=3 indicates the third unstructured ODU1 in the ODU2. 1079 - k2=2, k1=0 indicates the second unstructured ODU2 in the ODU3. 1080 - k2=0, k1=8 indicates the fourth unstructured ODU1 in the ODU3. 1081 - k2=4, k1=2 indicates the second ODU1 of the fourth ODU2 in the 1082 ODU3. 1084 5.2.2 OCh Label Space 1086 The OCh label space should be consistently defined as a flat value 1087 space whose values reflect the local assignment of OCh identifiers 1088 corresponding to the OTM-x.m sub-interface signals (m = 1, 2 or 3 1089 and x = 0r, nr or n). The OCh identifiers could be defined as 1090 specified in [GMPLS-SIG] either with absolute values: channel 1091 identifiers (Channel ID) also referred to as wavelength identifiers 1092 or relative values: channel spacing also referred to as inter- 1093 wavelength spacing. The latter is strictly confined to a per-port 1094 label space while the latter could be defined as a local or a global 1095 label space. 1097 Such an OCh label space is applicable to the OTN Optical Channel 1098 layer and the pre-OTN Optical Channel layer. 1100 5.3 Applications 1102 GMPLS extensions for G.709 must support the following applications: 1104 1. When one ODU1 (ODU2 or ODU3) non-structured signal is transported 1105 into one OTU1 (OTU2 or OTU3) payload, the upstream node requests in 1106 a non-structured ODU1 (ODU2 or ODU3) signal. In such conditions, the 1107 downstream node has to return a unique label since the ODU1 (ODU2 or 1108 ODU3) is directly mapped into the corresponding OTU1 (OTU2 or OTU3). 1109 When a single ODUk signal is requested the downstream node has to 1110 return a single ODUk label. 1112 2. When one ODU2 signal is transported into an ODU3 payload, which 1113 is sub-divided into 16 ODU1 tributary slots, the ODU1 tributary 1114 slots (here, denoted A, B, C and D with A < B < C < D) can be 1115 arbitrary selected. For instance, one ODU2 can be transported in 1116 ODU1 tributary slots 5, 12, 13 and 18. Therefore, when the upstream 1118 D.Papadimitriou - Internet Draft � Expires December 2001 21 1119 node requests in such conditions a composed ODU2 signal, the 1120 downstream node returns four labels each of them representing a 1121 pointer to an ODU1 tributary slot. 1123 3. When a single OCh signal of 40Gbps is requested, the downstream 1124 node has to return a single wavelength label to the requestor node. 1126 4. When a composed OCh[4.2] signal is requested i.e. a waveband or 1127 optical channel multiplex composed by four bit-rate identical OCh 1128 signal of 10Gbps, the downstream node has to return four wavelength 1129 labels to the requesting upstream node since the optical channels 1130 constituting the optical multiplex are not necessarily contiguously 1131 multiplexed. 1133 5. When requesting multiple LSP, more than one label is returned to 1134 the requestor node. For instance, when the downstream node receives 1135 a 4 x ODU1 Generalized Label Request, it returns four labels to the 1136 upstream node: the first ODU1 label corresponding to the first 1137 signal of the LSP, the second ODU1 label corresponding to the second 1138 signal of the LSP, etc. 1140 6. GMPLS Signalling Transport for G.709 1142 Furthermore, standardization is further required within ITU-T to 1143 define an in-fiber/in-band signaling transport mechanism through an 1144 OTN. Here, we propose the allocation of a General Communication 1145 Channel (GCC), particularly GCC(0) at the OTUk layer and GCC(1), 1146 GCC(2) at the ODUk layer, within the optical layer overhead to 1147 transport the GMPLS signalling. 1149 Notice that [ITUT-G.709] foresees also the possibility to provide 1150 transport in-fiber/out-of-band signalling (through the use of 1151 communication channels). 1153 6.1 ODUk General Communication Channel 1155 As defined in the [ITUT-G.709] recommendation, two fields of two 1156 bytes are allocated in the ODUk Overhead to support two General 1157 Communications Channels between any two network elements with access 1158 to the ODUk frame structure (i.e. at 3-R regeneration points). The 1159 bytes for GCC(1) are located in row 4, columns 1 and 2, and the 1160 bytes for GCC(2) are located in bytes row 4, columns 3 and 4 of the 1161 ODUk overhead. 1163 These bytes are defined as clear channels so that the format 1164 specification and their content can be defined for the purpose of 1165 in-fiber/in-band signalling transport mechanism. 1167 6.2 OTUk General Communication Channel 1169 Similarly, one field of two bytes is allocated in the OTUk Overhead 1170 to support two General Communications Channels between any couple of 1171 network elements with access to the OTUk frame structure (i.e. 1173 D.Papadimitriou - Internet Draft � Expires December 2001 22 1174 between OTUk termination points). These GCC(0) bytes are located in 1175 row 1, columns 11 and 12 of the OTUk overhead. 1177 7. Security Considerations 1179 Security considerations for OTN networks are not defined in this 1180 document. 1182 8. References 1184 1. [ITUT-G707] �Network node interface for the synchronous digital 1185 hierarchy (SDH)�, ITU-T Recommendation, March 1996. 1187 2. [ITUT-G709] �Interface for the Optical Transport Network (OTN)�, 1188 ITU-T draft version, February 2001. 1190 3. [ITUT-G872] �Architecture of Optical Transport Network�, ITU-T 1191 draft version, February 2001. 1193 4. [ITUT-G962] �Optical interfaces for multi-channel systems with 1194 optical amplifiers�, ITU-T Recommendation, October 1998. 1196 5. [ITUT-GASTN] �Automated Switched Transport Network�, ITU-T draft 1197 version, May 2001. 1199 6. [ITUT-GASON] �Automated Switched Optical Network�, ITU-T draft 1200 version, May 2001. 1202 7. [GMPLS-ARCH] E. Mannie et al., �Generalized Multi-Protocol Label 1203 Switching (GMPLS) Architecture�, Internet Draft, Work in progress, 1204 draft-many-gmpls-architecture-00.txt, February 2001. 1206 8. [GMPLS-LDP] P. Ashwood-Smith et al., �Generalized MPLS Signaling - 1207 CR-LDP Extensions�, Internet Draft, Work in progress, draft-ietf- 1208 mpls-generalized-cr-ldp-03.txt, May 2001. 1210 9. [GMPLS-RSVP] P. Ashwood-Smith et al., �Generalized MPLS Signaling 1211 - RSVP-TE Extensions�, Internet Draft, draft-ietf-mpls-generalized- 1212 rsvp-te-03.txt, May 2001. 1214 10. [GMPLS-SIG] P. Ashwood-Smith et al., �Generalized MPLS - 1215 Signaling Functional Description�, Internet Draft, Work in progress, 1216 draft-ietf-mpls-generalized-signaling-04.txt, May 2001. 1218 11. [GMPLS-SSS] S. Ansorge et al., �Generalized MPLS � SDH/Sonet 1219 Specifics�, Internet Draft, Work in progress, draft-ietf-ccamp-gmpls- 1220 sonet-sdh-00.txt, May 2001. 1222 9. Acknowledgments 1224 The authors would like to be thank Bernard Sales, Emmanuel Desmet, 1225 Jean-Loup Ferrant, Mathieu Garnot and Massimo Canali for their 1226 constructive comments and inputs. 1228 D.Papadimitriou - Internet Draft � Expires December 2001 23 1229 This draft incorporates material and ideas from draft-lin-ccamp-ipo- 1230 common-label-request-00.txt. 1232 10. Author's Addresses 1234 Michele Fontana 1235 Alcatel TND-Vimercate 1236 Via Trento 30, 1237 I-20059 Vimercate, Italy 1238 Phone: +39 039 686-7053 1239 Email: michele.fontana@netit.alcatel.it 1241 Germano Gasparini 1242 Alcatel TND-Vimercate 1243 Via Trento 30, 1244 I-20059 Vimercate, Italy 1245 Phone: +39 039 686-7670 1246 Email: germano.gasparini@netit.alcatel.it 1248 Alberto Bellato 1249 Alcatel TND-Vimercate 1250 Via Trento 30, 1251 I-20059 Vimercate, Italy 1252 Phone: +39 039 686-7215 1253 Email: alberto.bellato@netit.alcatel.it 1255 Gert Grammel 1256 Alcatel TND-Vimercate 1257 Via Trento 30, 1258 I-20059 Vimercate, Italy 1259 Phone: +39 039 686-7060 1260 Email: gert.grammel@netit.alcatel.it 1262 Jim Jones 1263 Alcatel TND-USA 1264 3400 W. Plano Parkway, 1265 Plano, TX 75075, USA 1266 Phone: +1 972 519-2744 1267 Email: Jim.D.Jones1@usa.alcatel.com 1269 Dimitri Papadimitriou (Editor) 1270 Senior R&D Engineer � Optical Networking 1271 Alcatel IPO-NSG 1272 Francis Wellesplein 1, 1273 B-2018 Antwerpen, Belgium 1274 Phone: +32 3 240-8491 1275 Email: Dimitri.Papadimitriou@alcatel.be 1277 Eric Mannie 1278 EBone (GTS) 1279 Terhulpsesteenweg, 6A 1280 1560 Hoeilaart, Belgium 1282 D.Papadimitriou - Internet Draft � Expires December 2001 24 1283 Phone: +32 2 658-5652 1284 Email: eric.mannie@ebone.com 1286 Zhi-Wei Lin 1287 Lucent Technologies 1288 101 Crawfords Corner Rd, Rm 3C-512 1289 Holmdel, New Jersey 07733-3030, USA 1290 Tel: +1 732 949-5141 1291 Email: zwlin@lucent.com 1293 Appendix 1 � Abbreviations 1295 1R Re-amplification 1296 2R Re-amplification and Re-shaping 1297 3R Re-amplification, Re-shaping and Re-timing 1298 AI Adapted information 1299 AIS Alarm Indication Signal 1300 APS Automatic Protection Switching 1301 BDI Backward Defect Indication 1302 BEI Backward Error Indication 1303 BI Backward Indication 1304 BIP Bit Interleaved Parity 1305 CBR Constant Bit Rate 1306 CI Characteristic information 1307 CM Connection Monitoring 1308 EDC Error Detection Code 1309 EXP Experimental 1310 ExTI Expected Trace Identifier 1311 FAS Frame Alignment Signal 1312 FDI Forward Defect Indication 1313 FEC Forward Error Correction 1314 GCC General Communication Channel 1315 IaDI Intra-Domain Interface 1316 IAE Incoming Alignment Error 1317 IrDI Inter-Domain Interface 1318 MFAS MultiFrame Alignment Signal 1319 MS Maintenance Signal 1320 naOH non-associated Overhead 1321 NNI Network-to-Network interface 1322 OCC Optical Channel Carrier 1323 OCG Optical Carrier Group 1324 OCI Open Connection Indication 1325 OCh Optical Channel (with full functionality) 1326 OChr Optical Channel (with reduced functionality) 1327 ODU Optical Channel Data Unit 1328 OH Overhead 1329 OMS Optical Multiplex Section 1330 OMU Optical Multiplex Unit 1331 OOS OTM Overhead Signal 1332 OPS Optical Physical Section 1333 OPU Optical Channel Payload Unit 1334 OSC Optical Supervisory Channel 1336 D.Papadimitriou - Internet Draft � Expires December 2001 25 1337 OTH Optical transport hierarchy 1338 OTM Optical transport module 1339 OTN Optical transport network 1340 OTS Optical transmission section 1341 OTU Optical Channel Transport Unit 1342 PCC Protection Communication Channel 1343 PLD Payload 1344 PM Path Monitoring 1345 PMI Payload Missing Indication 1346 PRBS Pseudo Random Binary Sequence 1347 PSI Payload Structure Identifier 1348 PT Payload Type 1349 RES Reserved 1350 RS Reed-Solomon 1351 SM Section Monitoring 1352 TC Tandem Connection 1353 TCM Tandem Connection Monitoring 1354 UNI User-to-Network Interface 1356 Appendix 2 � G.709 Indexes 1358 - Index k: The index "k" is used to represent a supported bit rate 1359 and the different versions of OPUk, ODUk and OTUk. k=1 represents an 1360 approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate 1361 bit rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s 1362 and k = 4 an approximate bit rate of 160 Gbit/s (under definition). 1363 The exact bit-rate values are in kbits/s: 1364 . OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322 1365 . ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983 1366 . OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559 1368 - Index m: The index "m" is used to represent the bit rate or set of 1369 bit rates supported on the interface. This is a one or more digit 1370 �k�, where each �k� represents a particular bit rate. The valid 1371 values for m are (1, 2, 3, 12, 23, 123). 1373 - Index n: The index "n" is used to represent the order of the OTM, 1374 OTS, OMS, OPS, OCG and OMU. This index represents the maximum number 1375 of wavelengths that can be supported at the lowest bit rate 1376 supported on the wavelength. It is possible that a reduced number of 1377 higher bit rate wavelengths are supported. The case n=0 represents a 1378 single channel without a specific wavelength assigned to the 1379 channel. 1381 - Index r: The index "r", if present, is used to indicate a reduced 1382 functionality OTM, OCG, OCC and OCh (non-associated overhead is not 1383 supported). Note that for n=0 the index r is not required as it 1384 implies always reduced functionality. 1386 D.Papadimitriou - Internet Draft � Expires December 2001 26 1387 Full Copyright Statement 1389 "Copyright (C) The Internet Society (date). All Rights Reserved. 1390 This document and translations of it may be copied and furnished to 1391 others, and derivative works that comment on or otherwise explain it 1392 or assist in its implementation may be prepared, copied, published 1393 and distributed, in whole or in part, without restriction of any 1394 kind, provided that the above copyright notice and this paragraph 1395 are included on all such copies and derivative works. However, this 1396 document itself may not be modified in any way, such as by removing 1397 the copyright notice or references to the Internet Society or other 1398 Internet organizations, except as needed for the purpose of 1399 developing Internet standards in which case the procedures for 1400 copyrights defined in the Internet Standards process must be 1401 followed, or as required to translate it into languages other than 1402 English. 1404 The limited permissions granted above are perpetual and will not be 1405 revoked by the Internet Society or its successors or assigns. 1407 This document and the information contained herein is provided on an 1408 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1409 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1410 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1411 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1412 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1414 D.Papadimitriou - Internet Draft � Expires December 2001 27