CCAMP Working Group Alberto Bellato (Alcatel) Category: Internet Draft Michele Fontana (Alcatel) Expiration Date: December 2001 Germano Gasparini (Alcatel) Gert Grammel (Alcatel) Jim Jones (Alcatel) Zhi-Wei Lin (Lucent) Eric Mannie (Ebone) Dimitri Papadimitriou (Alcatel) Siva Sankaranarayanan (Lucent) Maarten Vissers (Lucent) June 2001 G.709 Optical Transport Networks GMPLS Control Framework draft-bellato-ccamp-g709-framework-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Conventions used in this document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. D.Papadimitriou - Internet Draft û Expires December 2001 1 draft-bellato-ccamp-g709-framework-00.txt June 2001 Abstract Along with the current development of packet over lambda switching (referred to as MPLambdaS), there are considerable developments in optical transport systems based on the ITU-T G.872 [ITUT-G872] and G.709 [ITUT-G709] specification. The Optical Transport Network (OTN) defined in G.872 and G.709 enables ultra-long-haul transmission of various client signal types through the use of Forward Error Correction (FEC) bytes. G.709 specifies the data plane transport structure and allocates overhead bytes for the OTN control plane. In this document, we describe the G.709 Digital and Optical Transport Hierarchies (OTH) defined at the ITU-T and the relationships with the current GMPLS specification [GMPLS-ARCH]. This in order to specify how current GMPLS Signalling specification [GMPLS-SIG] can be accommodated in order to encompass these hierarchies to extend GMPLS signalling for OTN. 1. Introduction Recently, the ITU-T finalized the first version of the Optical Transport Networks (OTN) standardization [ITUT-G709] to provide the transparent digital pipe (digital wrapper) to be transported into optical channels. The OTN provides two fundamental degrees of flexibility: in terms of wavelength and in terms of bandwidth transmission optimization without losing the integrity of the lower bit rates pipes filled by the access network. From that perspective, the OTN specification enables as well the control of all-optical sub-networks. However, the OTN architecture has today no explicit association with any IP-based control plane, without which the future deployment of OTN equipment is clearly uncertain. Therefore, [ITUT-G709] foresees a strong requirement for future evolutions that can provide explicit support for the OTN control layer. Requirements for the definition of the OTN control plane (also referred to as Automatic Switched Transport Network û ASON) are currently under definition at the ITU- T. Consequently, Generalized MPLS (GMPLS) as specified in [GMPLS-SIG], can more than certainly provide the efficient "control-plane service" needed by the OTN specifications. Moreover, GMPLS can give fundamental indications in terms of how OTN can be controlled and where some additional features have to added (if needed) at the optical transmission layer level, in order to hit the goal of intelligent optical networks. Today, GMPLS efforts are directed in extending IP well known technology to control and manage lower non-packet based layered networks. Using the same framework and the same kinds of signalling and routing protocols suite to control multiple layers will not only reduce the overall complexity of designing, deploying and D.Papadimitriou - Internet Draft û Expires December 2001 2 draft-bellato-ccamp-g709-framework-00.txt June 2001 maintaining OTN networks but also allow potentially two contiguous layers to inter-operate when using either an overlay, an augmented or a peer model. In the mean time, GMPLS is very suitable for controlling each layer completely independently. Moreover, GMPLS can provide new capabilities and features for OTN such as flexible and distributed LSP establishment (today performed through the use of centralized Network Management Systems - NMS), multi-layer circuit establishment and GMPLS-based restoration methods that are of paramount importance for operators and carriers. 2. Current Solutions In this section, we describe the G.709 specification foundations. 2.1 Pre-OTN DWDM Development ITU-T G.709 describes also pre-OTN WDM development for backward compatibility with state of the art equipmentÆs. Pre-OTN development has generated the current OTN development at the ITU-T but also the current MPLambdaS and All-optical developments at the IETF for the next generation optical networks. Pre-OTN DWDM has been developed during the last years in order to overcome the bandwidth limitations and increase the bit-rate per fiber until several Tbps per fiber. Tomorrow, pre-OTN DWDM systems will provide up to 1000 wavelengths at 2.5 Gbps (or 500 x 10 Gbps or 250 x 40 Gbps) per fiber. This development includes the definition of point-to-point DWDM optical channels on top of a mesh optical topology including Optical Cross-Connects (OXC) or Photonic Cross- Connects (PXC). A PXC is defined as an all-optical device (i.e. no O/E) and an OXC as a bit-rate transparent device (i.e. it provides O/E/O conversion at each interface). The signalling paradigm developed for Lambda-switched LSP-capable networks has been included of the MPLS signalling paradigm. The MPLS generalization for fiber (space switching) lambda (wavelength switching), TDM (circuit switching) and packet LSPs (packet switching) is referred to as Generalized MPLS [GMPLS-SIG]. The current bandwidth bottleneck is overcome by the use of DWDM systems. DWDM systems allow the multiplexing of more than 160 wavelengths of 10 Gbps (1.6 Tbps per fiber with a 25 GHz spacing) by using simultaneously both the C-band and the L-band. Today, some vendors are proposing a lambda spacing of 12.5 GHz. Consequently, it will be possible to house 320 wavelengths of 10 Gbps in a single fiber (for a total throughput of 3.2 Terabits per fiber). A complementary method for increasing the effective capacity of a DWDM system is to include the 1480nm (S-Band) and 1650nm (U-Band) together with the deployment of fibers covering an ultra-wide waveband from 1460 to 1675nm (i.e. from the S-Band to the U-Band). D.Papadimitriou - Internet Draft û Expires December 2001 3 draft-bellato-ccamp-g709-framework-00.txt June 2001 Nevertheless, the ITU-T currently refers to 50 GHz spacing within the so-called ITU-T Grid, and in order to guarantee line interface interoperability, [ITUT-G.962] recommends 200 GHz wavelength spacing. In the pre-OTN application, client signals (STM-N, STS-N, GbE, IP, etc.) are directly mapped on wavelength through the use of a mapping-framing variable-length layer. This means that this development does not include G.709 client-signal mapping specification through the definition of a dedicated framing protocol. Moreover, additional standard Transparency levels to the one defined for SONET/SDH networks are defined for pre-OTN networks. 2.2 OTN Standard Optical networks include a set of functionality providing transport, multiplexing, routing, supervision and survivability of client signals that are processed predominantly in the optical domain. Optical signals are characterized by wavelength and may be processed per wavelength or as a wavelength division multiplexed group. The OTN model is decomposed into independent (transport) network layers where each layer can be separately partitioned in a way that reflects its internal structure. So that the OTN model refers to a layered structure comprising a Digital and an Optical Transport Hierarchy (OTH). The latter is constituted by the following network layers: - Optical Transmission Section (OTS) layer: This network layer provides functionality for transmission of optical signals on optical media of various types. This layer ensures the integrity and maintenance of the optical transmitted signal by overhead processing - Optical Multiplex Section (OMS) layer: This network layer provides functionality for networking of a multi-wavelength optical signal. A "multi-wavelength" signal includes the case of just one optical channel. This layer ensures the integrity and maintenance of the multi-wavelength signal by overhead processing. - Optical Channel (OCh) layer: this network layer provides end-to- end networking of optical channels for transparently conveying client information of various formats (e.g. SDH STM-N, Sonet OC-N, ATM, IP, etc.). The capabilities of this network layer concern With connection rearrangement for flexible routing, overhead processing, administration and maintenance functions. For the three layers specified above, non-associated overhead is transported via the Optical Supervisory Channel (OSC) in order to manage the optical connectivity. It has to be noted that these three layers are common to both pre-OTN and OTN applications. D.Papadimitriou - Internet Draft û Expires December 2001 4 draft-bellato-ccamp-g709-framework-00.txt June 2001 As far as the client signal handling is concerned, the Digital Wrapper layer is further layered as follows: - The Optical Channel Transport Unit (OTUk) provides FEC capabilities and optical section protection and monitoring capabilities. - The Optical Channel Data Unit (ODUk) layer provides client independent connectivity, connection protection and monitoring (also without the need to terminate the overhead information, the ODUk overhead may be monitored non-intrusively). - Clients signals i.e. STM-N signals, IP packets, ATM cells and Ethernet frames are mapped (meaning digitally wrapped) into a new structured frame defined as Optical Channel Payload Unit (OPUk). For each of the three layers specified above, an associated (in- band) overhead carrying the management information is added inside the framed structure itself. Notice, that only the ODUk (k= 1, 2, 3) and OCh are defined today as networking layers. The OTN layered transport structure can be schematically represented as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== | OCh Payload Unit (OPUk) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- | OCh Data Unit (ODUk) | Digital Path Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- | OCh Transport Unit (OTUk) | Digital Section Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== | Optical Channel Layer (OCh) | +-----------------------------------+ Optical Channel Layer | Optical Channel Multiplexing | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== | Optical Multiplex Section OMS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Physical Section | Optical Transmission Section OTS | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== The OPUk, ODUk and OTUk layers constitute the Digital Transport Hierarchy also referred to as Digital Wrapper Layer. The development of a digital and an optical transport hierarchy (i.e. networking layer) is required for the following reasons: - It is the next step (after TDM - SDH/SONET) to support ever growing data driven needs for bandwidth and emergence of new broadband services - To support next generation Terabit/second per fiber via DWDM lines at the transport level as well as optical channels at 2.5 Gbps, 10 Gbps and 40 Gbps bit rates at wire speed level (and in the future 160 Gbps currently under definition) - To provide network operational management, planning, administration, survivability, and finally cost of maintenance limited only to the OTUk/ODUk rates of transmission without caring about the granularity of the client signal. The OTN Specification is described in details in the next section. D.Papadimitriou - Internet Draft û Expires December 2001 5 draft-bellato-ccamp-g709-framework-00.txt June 2001 4. Optical Transport Networks Specification The OTN specifies an Optical Transport Hierarchy (OTH) supporting the operation and management aspects of optical networks of various architectures such as point-to-point, ring and mesh architectures. The G.709 specification defines the interfaces of the OTN to be used within and between sub-networks of the optical network, in terms of: - Optical Transport Hierarchy (OTH) - functionality of the overhead in support of multi-wavelength optical sub-networks - frame structures - bit rates - formats for mapping client signals The OTN interfaces specifications can be applied at User to Network Interfaces (UNI) and Network Node Interfaces (NNI) of the OTN. The overhead functionality necessary for operations and management of optical sub-networks is also defined. For interfaces used within optical sub-networks, the aspects related to the interface depend on the optical technology progress and so are not covered by G.709 recommendation. This is within the scope of other ITU-T recommendations [ITUT-G959.1]. 4.1 Optical Transport Hierarchy (OTH) The Optical Transport Hierarchy (OTH) structure is defined as specified in [ITUT-G.872] that defines the Optical Channel (OCH) layer. The OTH further sub-structured the OCh layer in sub-layer networks in order to support the network management and supervision functions such as: - The Optical Channel with full (OCh) or reduced functionality (OChr), provides transparent network connections between 3R regeneration points in the OTN. - The fully standardized Optical Channel Transport Unit-k (OTUk) which provides supervision and conditions the signal for transport between regeneration points in the OTN (1R, 2R and for pre-OTN only, 3R). - The Optical Channel Data Unit (ODUk) which provides . tandem connection monitoring (ODUk-TCM), . end-to-end path monitoring (ODUk-PM) - The Optical Channel Payload Unit (OPUk) which provides adaptation of client signals The Optical Transport Module-n (OTM-n) is the information structure used to support OTN interfaces. Two OTM-n structures are defined: - OTM interfaces with full functionality (OTM-n.m) - OTM interfaces with reduced functionality (OTM-0.m, OTM-nr.m) D.Papadimitriou - Internet Draft û Expires December 2001 6 draft-bellato-ccamp-g709-framework-00.txt June 2001 The reduced functionality OTM interfaces are defined with 3R processing at each end of the OTN. 4.1.1 Full Functional Stack: OTM-n.m With a full functional stack (OTM-n.m), up to n OCC are multiplexed into an OCG-n.m using wavelength division multiplexing. The OCC tributary slots of the OCG-n.m can be of different size depending on the value of the index m (m = 1, 2, 3, 12, 23 or 123). The OCG-n.m is transported via the OTM-n.m. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OCh Payload Unit OPUk | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OCh Data Unit ODUk | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OCh Transport Unit OTUk | ---------------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Boundary | Optical Channel Layer OCh | ---------------------------- +-------------------------------------+ | Optical Channel Carrier (OCC) | ^ +-------------------------------------+ | Wavelength Multiplexing | Optical Carrier Group (OCG-n.m) | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optical Multiplex Section OMSn | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optical Transmission Section OTSn | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OTM-n.m (n > 1) For the case of the full functional OTM-n.m interfaces, the OSC is multiplexed into the OTM-n.m using wavelength division multiplexing. 4.1.2 Reduced Functionality Stack: OTM-0.r and OTM-nr.m The OTM with reduced functionality could be either - OTM-0: consists of a single optical channel without a specific wavelength assigned (see Figure) - OTM-nr.m: consists of up to n multiplexed optical channels. Non associated overhead is not supported (see Figure) The OTM-nr.m/OTM-0.m is the information structure used to support Optical Physical Section (OPS) layer connections in the OTN. The order of an OTM-nr is defined by the order of the OCG-nr that it supports. Note that the first version of G.709, only includes reduced functionality for standardized inter-domain interfaces (IrDI). 1. OTM-nr.m D.Papadimitriou - Internet Draft û Expires December 2001 7 draft-bellato-ccamp-g709-framework-00.txt June 2001 Up to n OCCr are multiplexed into an OCG-nr.m using wavelength division multiplexing. The OCCr tributary slots of the OCG-r.m can be of different size (m = 1, 2, 3, 12, 23 or 123). The OCG-nr.m is transported via the OTM-nr.m. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OCh Payload Unit (OPUk) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OCh Data Unit (ODUk) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OCh Transport Unit (OTUk) | ---------------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Boundary | Optical Channel Layer (OChr) | ---------------------------- +-------------------------------------+ | Optical Channel Carrier (OCCr) | ^ +-------------------------------------+ | Wavelength Multiplexing | Optical Carrier Group (OCG-nr.m) | v +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optical Physical Section (OPSn) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OTM-nr.m (n > 1) 2. OTM-0r.m (OTM-0.m) Only one OCCr tributary slot is provided so that the OCG-0r.m is not defined. Consequently, reduced functionality OTM-0r.m stack does not support wavelength division multiplexing functionality. The OCCr tributary slot can be of different size (m = 1, 2 or 3). The OCCr is transported via the OTM-0.m. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OCh Payload Unit (OPUk) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OCh Data Unit (ODUk) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OCh Transport Unit (OTUk) | ---------------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Boundary | Optical Channel Layer (OChr) | ---------------------------- +-------------------------------------+ | Optical Channel Carrier (OCCr) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Optical Physical Section (OPS0) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OTM-0.m (n = 0) 4.2 Optical Channel Encapsulation D.Papadimitriou - Internet Draft û Expires December 2001 8 draft-bellato-ccamp-g709-framework-00.txt June 2001 An overhead is associated to the OPUk, the ODUk and the OTUk signals. Moreover, the OTUk signal can include a tailer FEC. As not indicated in the following figure, the control non-associated overhead at the lower OCh level is multiplexed within the OTM Overhead Signal (OOS) and then inserted to the OSC. The OOS is the information structure used for transport of OTM non-associated overhead over the OSC. The non-associated overhead consists of the Optical Transmission Section (OTS) overhead, Optical Multiplex Section (OMS) overhead and Optical Channel (OCh) non-associated overhead; it is characterized by its frame structure, bit rate and bandwidth. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Client PDU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |OH | OCh Payload Unit Payload (OPUk) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |OH | OCh Data Unit Payload (ODUk) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |OH | OCh Transport Unit Payload (OTUk) | FEC | +===============================================+=====+ . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optical Channel Layer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . / . -------------------------------------------- . / +-------+ +-------+ +-------+ +-------+ +-------+ | OCC | | OCC | | OCC | | OCC | | OCC | +-------+ +-------+ +-------+ +-------+ +-------+ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+ | Optical Multiplex Section OMSn | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OPS | | Optical Transport Section OTSn | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+ The optical channel network-layer overhead bytes defined in [ITUT- G.709] support the following capabilities: - Forward Error Correction (FEC) - Performance Monitoring (PM) - Network Fault localization - Network Restoration Signaling D.Papadimitriou - Internet Draft û Expires December 2001 9 draft-bellato-ccamp-g709-framework-00.txt June 2001 - Network General Communications Channels (GCC) - Manufacturer-Specific Communications Channel 4.3 Signal Types Signal types defined by the [ITUT-G709] specification can be divided in Optical Channel Unit layer and Optical Transport Module (OTM). The Payload Unit layer can itself be sub-divided in OCh Payload Unit, OCh Data Unit and OCh Transport Unit. The Appendix 2 describes the indexes used within the [ITUT-G709] terminology. 4.3.1 OPUk Signal Optical channel Payload Unit (OPU) is defined as a structured signal of order k (k = 1, 2, 3) and referred to as OPUk signal. The OPUk frame structure is organized in an octet based block frame structure with 4 rows and 3810 columns. The two main areas of the OPUk frame (4 x 3810 Bytes) are the OPUk Overhead area (column 15 and 16) and OPUk Payload area (columns 17 to 3824). 4.3.2 ODUk Signal Optical channel Data Unit (ODU) is defined as a structured signal of order k (k = 1, 2, 3) and referred to as ODUk signal. The ODUk frame structure is organized in an octet based block frame structure with 4 rows and 3824 columns. The two main areas of the ODUk frame are ODUk Overhead area (columns 1 to 14 with column 1 dedicated to FA and OTUk specific alignment) and OPUk area (Columns 15 to 3824 which are dedicated to the OPUk area). 4.3.3 OTUk Signal Optical channel Transport Unit (OTU) of order k (k = 1, 2, 3) defines the conditioning for transport over an Optical Channel network connection. This signal is referred to as OTUk signal. The OTUk (k=1,2,3) frame structure is based on the ODUk frame structure and extends it with a forward error correction (FEC). Scrambling is performed after FEC computation and insertion into the OTUk signal. In the OTUk signal, 256 columns are added to the ODUk frame for the FEC and the reserved overhead bytes in row 1, columns 9 to 14 of the ODUk overhead are used for OTUk specific overhead, resulting in an octet based block frame structure with 4 rows and 4080 columns (4 x 4080 bytes). 4.3.4 OTM Interface Signal The OTM-n interface signal supports n optical channels on a single fiber with 3R regeneration and termination of the OTUk signal on each end. As 3R regeneration is performed on both sides of the OTM- 0.m and OTM-nr.m interfaces access to OTUk overhead is available and maintenance as well as supervision of the interface is provided via this overhead. Therefore non-associated OTM overhead is not required D.Papadimitriou - Internet Draft û Expires December 2001 10 draft-bellato-ccamp-g709-framework-00.txt June 2001 across the OTM-0.m and OTM-nr.m interfaces. Consequently, Optical Supervisory Channel (OSC) and OTM Overhead Signal (OOS) are not supported. In the first G.709 version, only two OTM interfaces classes with reduced functionality are defined: OTM-0.m and OTM-16r.m. 1. OTM-16r.m Interface The OTM-16r.m interface supports 16 Optical Channels (n = 16) on a single optical span with 3R regeneration at each end. Six OTM-16r.m interface signals are currently defined (m = 1, 2, 3, 12, 23, 123). The OTM-16r.m signal is an OTM-nr.m signal with 16 Optical Channel Carriers (OCCr) numbered OCCr #0 to OCCr #15. An Optical OSC is not present and there is no OOS either. For instance, the OTM16 can be separated in several cases: - the OTM-16r.1 (with up to 16 wavelengths only at 2.5 Gbps) - the OTM-16r.2 (with up to 16 wavelengths only at 10 Gbps) - the OTM-16r.3 (with up to 16 wavelengths only at 40 Gbps) - the OTM-16r.m (with up to 16 wavelengths mixing possibly bit- rates) At least one of the OCCr is in service during normal operation and transporting an OTUk. However, there is no predefined order in which the OCCrÆs are taken into service. Note: OTM-16r.m OPS overhead is not defined. The interface will use the OTUk SMOH in this multi-wavelength interface for supervision and management. OTM-16r.m connectivity failure (TIM) reports will be computed from the individual OTUk reports by means of failure correlation in fault management. 2. OTM-0.m Interface The OTM-0.m supports a single wavelength optical channel on a single optical fiber with 3R regeneration at each end. Three OTM-0.m interface signals are defined (with m = 1, 2, 3), each carrying a single channel optical signal containing one OTUk (with k = 1, 2, 3) signal. There is neither OSC defined nor OOS for OTM-0.m. 4.4 ODUk Mapping and Multiplexing Since G.709 defines at the Optical Channel layer three distinct client payload bit rates, an Optical Channel Data Unit (ODU) frame has been defined for each of these bit rates. An ODUk refers to a bit rate k framing signal, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps) or 3 (for 40 Gbps). ODUk Multiplexing will be included in the future release of G.709 [ITUT-G709] while ODUk Mapping can be considered as the basic mechanism underlying the Digital Transport Hierarchy layered D.Papadimitriou - Internet Draft û Expires December 2001 11 draft-bellato-ccamp-g709-framework-00.txt June 2001 structure. Note that ODUk and OTUk layers still remain in the electrical domain and are referred to as Digital Path and Digital Section in the ITU-T G.709 recommendation. 4.4.1 ODUk Mapping By definition in ODUk mapping, the client signal is mapped into the OPUk. The OPUk is mapped into an ODUk and the ODUk is mapped into an OTUk. The OTUk is mapped into an OChr and the OChr is then modulated onto an OCCr. The ODUk mapping is described by the following figure: x1 x1 OTU3 <---- ODU3 <---- OPU3 <--------------------------- Client PDU x1 x1 OTU2 <--------------- ODU2 <---- OPU2 <---------------- Client PDU x1 x1 OTU1 <-------------------------- ODU1 <---- OPU1 ------ Client PDU 4.4.2 ODUk Multiplexing By definition of ODUk multiplexing, an ODUk (or ODUk Tributary Unit Group) is mapped into the OPU[k+1] if k = 1 or 2 or OPU[k+2] if k = 1. The resulting OPUk is mapped into an ODUk and the ODUk is mapped into an OTUk. The OTUk is mapped into an OChr and the OChr is then modulated onto an OCCr. Therefore, two levels of ODUk multiplexing can be defined: - ODU1 multiplexing: . four ODU1 are multiplexed into one OPU2 which is mapped into one ODU2 . sixteen ODU1 are multiplexed into one OPU3 which is mapped into one ODU3 - ODU2 multiplexing: . four ODU2 are multiplexed into one OPU3 which is mapped into one ODU3 For instance, when multiplexing four ODU1 signals into an ODU2. The ODU1 signals including the Frame Alignment OH and an all-0's pattern in the OTUk Overhead locations are scrambled and then adapted to the ODU2 clock via justification (asynchronous mapping). These adapted ODU1 signals are byte interleaved into the OPU2 Payload area, and their justification control and opportunity signals are frame interleaved into the OPU2 Overhead area. ODU2 Overhead is added after which the ODU2 is mapped into the OTU2. OTU2 Overhead and Frame Alignment Overhead are added to complete the signal for transport via an OTM signal. D.Papadimitriou - Internet Draft û Expires December 2001 12 draft-bellato-ccamp-g709-framework-00.txt June 2001 The ODUk multiplexing is described by the following figure: x1 x1 OTU3 <---- ODU3 <---- OPU3 <---------------------------- Client PDU | <-- x4| |x16 x1 | | OTU2 <--------------- ODU2 <----- OPU2 <---------------- Client PDU | | | |x4 x1 -- | x1 OTU1 <--------------------------- ODU1 <---- OPU1 ------ Client PDU 4.4.3 ODUk Inverse Multiplexing Inverse multiplexing is currently under specification at the ITU-T. It should be implemented by means of virtual concatenation of two or more than two ODUk signals (defined as ODUk-Xv). The ODUk-Xv signal can transport a non-OTN client signal (for instance, an ODU2-4v may transport an STM-256). The characteristic information of a virtual concatenated ODUk (ODUk- Xv) layer network is transported via a set of X ODUk LSP, each LSP having its own transfer delay. The egress LSR terminating the ODUk- Xv LSP has to compensate this differential delay in order to provide a contiguous payload at the output. 4.5 Wavelength Division Multiplexing With reduced stack functionality: up to n (n >= 1) OCCr are multiplexed into an OCG-nr.m using wavelength division multiplexing. The OCCr tributary slots of the OCG-nr.m can be of different size. The OCG-nr.m is transported via the OTM-nr.m. x1 x1 -------- OCCr <-------- OChr <-------- OTU3 | |xi x1 | xj x1 x1 OTM-nr.m <------- OCG-nr.m <----- OCCr <-------- OChr <-------- OTU2 | |xk | x1 x1 -------- OCCr <-------- OChr <-------- OTU1 with 1 =< i + j + k =< n With full stack functionality: up to n (n >= 1) OCC are multiplexed into an OCG-n.m using wavelength division multiplexing. The OCC tributary slots of the OCG-n.m can be of different size. The OCG-n.m is transported via the OTM-n.m. D.Papadimitriou - Internet Draft û Expires December 2001 13 draft-bellato-ccamp-g709-framework-00.txt June 2001 x1 x1 --------- OCC <-------- OCh <-------- OTU3 | |xi x1 | xj x1 x1 OTM-n.m <------- OCG-n.m <------ OCC <-------- OCh <-------- OTU2 | | | |xk | | x1 x1 | --------- OCC <-------- OCh <-------- OTU1 | | x1 -------------- OSC <------ OOS (OTS, OMS, OCh OH) with 1 =< i + j + k =< n For the case of the full functionality OTM-n.m interfaces the OSC is multiplexed into the OTM-n.m using wavelength division multiplexing. 4.6 Client Signal Mapping The specification of the Client-layer signal encapsulation in the OPU layer has been provided through the definition of different solutions depending upon the type of Client-layer signal. IP and Ethernet packet mapping is defined by the G.709 specification through the use of the Generic Framing Procedure (GFP). This (new) framing has been specified in order to avoid the use of Ethernet framing or SDH/Sonet in order to encapsulate IP packets and other types of packet (such as ESCON, Fiber Channel, etc.). GFP is defined as a generic mechanism to transport any client layer over a fixed data-rate optical channels (specifically, the so-called OTN ODU of unit-k). This means that GFP idle frames must be generated when the client layer does not send data packet. Consequently the service offered to the client packet layer is strictly equivalent to the one offered in SDH. The Generic Framing Procedure (GFP) frame format is defined as: +----------+--------------------------------------------+----------+ | Header | Payload | FCS | | 4 bytes | 4 û 65535 bytes | Optional | +----------+--------------------------------------------+----------+ The header (4-bytes) is composed by a PDU Length Indicator (PLI) of 2 bytes and a HEC (Header Error Control) of 2 bytes. The GFP Idle frame format, which includes a NULL PLI and a HEC of 2 bytes, is defined as: D.Papadimitriou - Internet Draft û Expires December 2001 14 draft-bellato-ccamp-g709-framework-00.txt June 2001 +----------+ |Idle Frame| | 4bytes | +----------+ GFP defines also two basic frame-oriented mechanisms: 1. GFP Frame Multiplexing: the GFP frame multiplexing is performed on a frame-by-frame basis. When no frames are waiting, idle frames are inserted. 2. GFP Frame Delineation Algorithm: as defined for cell delineation, GFP frame delineation is based on the detection of correct HEC. PLI is used to find the start of the next frame. The GFP frames constitute the OPUk payload. The corresponding OPUk overhead is defined as follows by the Payload Structure Identifier (PSI) which includes the following fields: - PT: Payload Type (1-byte) - RES: Reserved (254-bytes) The GFP OPUk (k = 1, 2, 3) capacity are defined such that they can include the following client bit rates: - GFP (OPU1): 2 488 320 kbit/s - GFP (OPU2): 9 995 276 kbit/s - GFP (OPU3): 40 150 519 kbit/s Aligning the byte structure of every GFP frame with the byte structure of the OPUk Payload performs the mapping of GFP frames. Since the GFP frames are of variable length (the mapping does not impose any restrictions on the maximum frame length), a frame may cross the OPUk frame boundary. GFP frames arrive as a continuous bit stream (Idle frames when no client packets) with a capacity that is identical to the OPUk payload area, due to the insertion of Idle frames at the GFP encapsulation stage. Note that here, the GFP frame stream is scrambled during encapsulation. As currently defined in [ITUT-G709], GFP provides also ATM Constant Bit Rate (CBR) û by using ATM cell multiplexing - and TDM Circuits Encapsulation and mapping into the OPUk payload area. 5. GMPLS Extensions for G.709 Adapting GMPLS to control G.709 can be achieved by considering that G.709 defines two transport hierarchies: a digital hierarchy (also known as the ôDigital Wrapperö) and an optical transport hierarchy. First, within the digital hierarchy (the previously defined ôDigital Wrapperö), a Digital Path Layer is defined. Then, within the optical transport hierarchy, an Optical Channel layer or Optical Path layer including a digital OTM Overhead Signal (OOS), i.e. a non-associated overhead, is defined. D.Papadimitriou - Internet Draft û Expires December 2001 15 draft-bellato-ccamp-g709-framework-00.txt June 2001 GMPLS extensions for G.709 need to cover the Generalized Label Request, the Generalized Label as well as specific technology dependent fields such as those currently assigned to the SDH/Sonet labels [GMPLS-SSS]. Since the multiplexing in the electrical domain (such as ODUk multiplexing) will be added very soon into the next version of the G.709 recommendation, we can already specify a label space definition suitable for that purpose. As implicitly specified in GMPLS control for SDH/SONET Networks [GMPLS-SSS], since GFP is only used as a framing protocol we donÆt consider this framing layer to be included into the G.709 label space. Rather, we directly use the G.709 digital and optical transport hierarchies in order to define the corresponding label spaces. 5.1 G.709 Label Request Considerations The Generalized Label Request as defined in [GMPLS-SIG], includes a technology independent part and a technology dependent part (i.e. the traffic parameters). 5.1.1 Technology Independent Part As defined in [GMPLS-SIG], the LSP Encoding Type and the Generalized Protocol Identifier (G-PID) constitute the technology independent part. As mentioned here above, we suggest here to adapt the LSP Encoding Type and the G-PID (Generalized-PID) to accommodate G.709 recommendation [ITUT-G709]. 1. LSP Encoding Type Since G.709 defines two networking layers (ODUk layers and OCh layer), the LSP Encoding Type can reflect these two layers or be considered as a common layer: - If an LSP Encoding Type is specified per networking layer or more precisely per group of functional networking layer (i.e. ODUk and OCh), then the Signal Type must not reflect these layers. This means that two LSP Encoding Types have to defined: . one reflecting the digital hierarchy (also referred to as the ôDigital Wrapperö layer) through the definition of the digital path layer i.e. the ODUk layers . the other reflecting the Optical Transport Hierarchy through the definition of the optical path layer i.e. the OCh layer - If the LSP Encoding Type is considered as a common space for G.709 meaning that the LSP Encoding Type doesnÆt reflect the two G.709 hierarchies, then the Signal Type must reflect these layers. This means that at least four Signal types must be defined: one for each ODUk signal and one for the OCh signal D.Papadimitriou - Internet Draft û Expires December 2001 16 draft-bellato-ccamp-g709-framework-00.txt June 2001 In the latter case only one new code-point has to be defined for the LSP Encoding Type while in the former case, two new code-points must be defined. Therefore, the current "Digital Wrapper" code defined in [GMPLS-SIG], could be replaced by two separated codes: - code for the G.709 Digital Path layer - code for the non-standard Digital Wrapper layer In the same way, two separated code points could replace the current defined ôLambdaö code: - code for the G.709 Optical Channel layer - code for the non-standard Lambda layer (also simply referred to as Lambda layer) which the pre-OTN Optical Channel layer Moreover, the code for the G.709 Optical Channel (OCh) layer will indicate the capability of an end-system to use the G.709 non- associated overhead (naOH) i.e. the OTM Overhead Signal (OOS) multiplexed into the OTM-n.m interface signal. 2. Generalized-PID The Generalized-PID (G-PID) as defined in [GMPLS-SIG], identifies the payload carried by an LSP. The G-PID, which defines the client layer of that LSP, is used by the G.709 endpoints of the LSP. As described in [ITUT-G709], the G-PID could take one of the following values at the Digital Path layer, in addition to the payload identifiers already defined in [GMPLS-SIG]: - CBRa: asynchronous Constant Bit Rate i.e. STM-16/OC-48, STM- 64/OC-192 and STM-256/OC-768 - CBRb: bit synchronous Constant Bit Rate i.e. STM-16/OC-48, STM- 64/OC-192 and STM-256/OC-768 - ATM: Constant Bit Rate at 2.5, 10 and 40 Gbps - BSOT: non-specific client Bit Stream with Octet Timing at 2.5, 10 and 40 Gbps - BSNT: non-specific client Bit Stream without Octet Timing at 2.5, 10 and 40 Gbps The G-PID defined in [GMPLS-SIG] are then used when the client payloads are encapsulated through the GFP mapping procedure: Ethernet, ATM Mapping and Packets (translated by PoS). Other G-PID values not defined in [GMPLS-SIG] such as Escon and Fiber Channel could complete in the near future the list of payload mapped by using GFP mapping procedure. In order to include pre-OTN developments, the G-PID at the Optical Channel Layer can in addition to the G.709 Digital Path Layer (at 2.5 Gbps i.e. ODU1, 10 Gbps i.e. ODU2 and 40 Gbps i.e. ODU3) take one of the values currently defined in [GMPLS-SIG], in particular: - SDH: STM-16, STM-64 and STM-256 - Sonet: OC-48, OC-192 and OC-768 - Ethernet: 1 Gbps and 10 Gbps 5.1.2 Technology Dependent Part D.Papadimitriou - Internet Draft û Expires December 2001 17 draft-bellato-ccamp-g709-framework-00.txt June 2001 The technology dependent of the Generalized Label Request also referred to as traffic-parameters must reflect the following G.709 features: ODUk mapping, ODUk multiplexing, OCh multiplexing, OTM Overhead signal (OOS) and Transparency (only for pre-OTN). 1. Signal Type As defined in [GMPLS-SSS], the traffic-parameters must include the technology specific G.709 networking Signal Types i.e. the signals processed by the GMPLS control-plane. The corresponding identifiers reflect the signal types requested during the LSP setup. As described in section 5.1, the following signal types must be considered: ODU1, ODU2, ODU3 and (at least one) OCh. Obviously, pre- OTN developments support only one OCh Signal Type value. Note: Additional Signal Type code-points such as ODU4 (currently under definition at the ITU-T) could also be reserved for future considerations. 2. Multiplexing A second field must indicate the type of multiplexing being requested for ODUk LSP or OCh LSP. As defined in section 4.4, two kinds of multiplexing are currently defined: flexible multiplexing (or simply multiplexing) and inverse multiplexing. At the ODUk layer (i.e. digital path layer), flexible multiplexing as described in Section 4.4, refers to the mapping of an ODU2 into four arbitrary OPU3 tributary slots (i.e. each slot containing one ODU1) arbitrarily selected. Inverse multiplexing currently under definition at ITU-T should also be considered. The requested multiplexing type must include a default value indicating that neither ODUk flexible multiplexing nor ODUk inverse multiplexing is requested. At the Optical Channel layer, flexible multiplexing is not defined today while inverse multiplexing means that the requested composed signal constitutes a waveband (i.e. an optical channel multiplex). A waveband, denoted as OCh[j.k] (j >= 1) is defined as a non- contiguous set of identical optical channels j x OCh, each of them is associated to an OTM-x.m (x = nr or n) sub-interface signal. The bit rate of each OCh constituting the waveband (i.e. the composed L- LSP) must be identical, k is unique per OCh multiplex. Note: today both OTN and Pre-OTN specifications do not define the optical channel multiplex. Therefore, in this context, any waveband switching development as defined in this specification is purely vendor specific. Consequently, since the number of identical components included in an ODU multiplex or an OCh multiplex is arbitrary, a dedicated field indicating the requested number of components must also be defined D.Papadimitriou - Internet Draft û Expires December 2001 18 draft-bellato-ccamp-g709-framework-00.txt June 2001 in order to reflect individual signals constituting the requested LSP. 3. OTM Overhead Signal (OOS) A dedicated field should indicate whether or not the non-associated overhead is supported at the G.709 Optical Channel layer. This feature is irrelevant at the G.709 Digital Path layer and the pre- OTN Optical Channel layer if the latter does not support non associated overhead (naOH). This field should also not restrict the transport mechanism of the OTM Overhead Signal (OOS) since in-fiber/out-of-band OSC and out-of- fiber/out-of-band transport mechanisms are allowed. This field must ideally support the following options: - With OTM-0r.m and OTM-nr.m interfaces (reduced functionality stack), OTM Overhead Signal (OOS) is not supported. Therefore with these types of interface signals, non-associated OTM overhead indication is not required. - With OTM-n.m interfaces (full functionality stack), the OOS is supported and mapped into the Optical Supervisory Channel (OSC) which is multiplexed into the OTM-n.m using wavelength division multiplexing. - With OTM-n.m interfaces or even with OTM-0.m and OTM-nr.m interfaces, ônon-standardö OOS can be defined to allow for instance interoperability with pre-OTN based devices or with any optical devices which does not support G.709 OOS specification. This specific OOS enables the use of any proprietary monitoring signal exchange through any kind of supervisory channel (it can be transport by using any kind of IP-based control channel). 4. Transparency Transparency is only defined for pre-OTN developments since by definition any signal transported over an OTN is fully transparent. This feature is used to request a pre-OTN LSP (i.e. a non-standard Lambda-LSP) including transparency support. It may also be used to setup the transparency process to be applied in each intermediate LSR. As it is commonly the case today with pre-OTN capable interfaces, three kinds of transparency levels are currently defined: - SONET/SDH Pre-OTN interfaces with RS/Section and MS/Line overhead transparency: the pre-OTN network is capable to transport transparently STM-N/OC-N signals. - SONET/SDH Pre-OTN interfaces terminating RS/Section overhead with MS/Line overhead transparency: the pre-OTN network is capable to transport transparently MSn signals D.Papadimitriou - Internet Draft û Expires December 2001 19 draft-bellato-ccamp-g709-framework-00.txt June 2001 - SONET/SDH Pre-OTN interfaces terminating RS/Section and MS/Line overhead: the pre-OTN network is capable to transport transparently HOVC/STS-SPE signals. Consequently, for pre-OTN Optical Channels a specific field (in the Generalized Label Request) must indicate the transparency level requested during the L-LSP setup. However, this field is only relevant when the LSP Encoding Type value corresponds to the Non- standard Lambda layer. 5.2 G.709 Label Space The G.709 label space must include two sub-spaces: the first reflecting the digital path layer (i.e. the ODUk layers) and the second, the optical path layer (i.e. the OCh layer). 5.2.1 ODUk Label Space At the Digital Path layer (i.e. ODUk layers), G.709 defines three different client payload bit rates. An Optical Data Unit (ODU) frame has been defined for each of these bit rates. ODUk refers to the frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps) or 3 (for 40 Gbps). In addition to the support of ODUk mapping into OTUk, the G.709 label space must support the sub-levels of ODUk flexible multiplexing (or simply ODUk multiplexing): - ODU2 multiplexing: . The mapping of an ODU2 into four arbitrary OPU3 tributary slots selected arbitrarily (i.e. each slot containing one ODU1) - ODU3 multiplexing: . Not applicable today since higher order OPU tributary slots are not defined in the current [ITUT-G709] recommendation Defining three fields (k1, k2 and k3) self-consistently specifies the ODUk label space. The value space of the k1, k2 and k3 fields are defined as follows: - k1: indicates a particular ODU1 in one ODU2 (k1 = 1,..,4), ODU3 (k1 = 5,..,20); k1 values from 21 to 84 are reserved for future use - k2: indicates a particular ODU2 in one ODU3 (k2 = 1,..,4); k2 values from 5 to 20 are reserved for future use - k3: k3 values (k3 = 1,..,4) are reserved for future use If k1, k2 and k3 values are equal to zero, the corresponding ODUk are not structured, i.e. k[i]=0 (i=1,2,3) indicates that the ODU[i] is not structured and the ODU[i] is simply mapped into the OTU[i] as described in Section 4.4. D.Papadimitriou - Internet Draft û Expires December 2001 20 draft-bellato-ccamp-g709-framework-00.txt June 2001 Since k3 usage is not yet fully specified, k3 value always equals zero, k2 valid interval is [0,4] and k1 valid interval is [0,20]. Thus, when used in a G.709 Generalized Label: - k1: indicates a particular ODU1 in one ODU2 (k1 = 1,..,4) or in one ODU3 (k1 = 5,..,20) - k2: indicates a particular ODU2 in one ODU3 (k2 = 1,..,4) If k1 and k2 values are equal to zero means non-significant: a particular ODUk is not structured, i.e. ki=0 indicates that the ODUi in not structured. Examples: - k2=0, k1=0 indicates a full ODU3 (full 40 Gbps). - k2=0, k1=3 indicates the third unstructured ODU1 in the ODU2. - k2=2, k1=0 indicates the second unstructured ODU2 in the ODU3. - k2=0, k1=8 indicates the fourth unstructured ODU1 in the ODU3. - k2=4, k1=2 indicates the second ODU1 of the fourth ODU2 in the ODU3. 5.2.2 OCh Label Space The OCh label space should be consistently defined as a flat value space whose values reflect the local assignment of OCh identifiers corresponding to the OTM-x.m sub-interface signals (m = 1, 2 or 3 and x = 0r, nr or n). The OCh identifiers could be defined as specified in [GMPLS-SIG] either with absolute values: channel identifiers (Channel ID) also referred to as wavelength identifiers or relative values: channel spacing also referred to as inter- wavelength spacing. The latter is strictly confined to a per-port label space while the latter could be defined as a local or a global label space. Such an OCh label space is applicable to the OTN Optical Channel layer and the pre-OTN Optical Channel layer. 5.3 Applications GMPLS extensions for G.709 must support the following applications: 1. When one ODU1 (ODU2 or ODU3) non-structured signal is transported into one OTU1 (OTU2 or OTU3) payload, the upstream node requests in a non-structured ODU1 (ODU2 or ODU3) signal. In such conditions, the downstream node has to return a unique label since the ODU1 (ODU2 or ODU3) is directly mapped into the corresponding OTU1 (OTU2 or OTU3). When a single ODUk signal is requested the downstream node has to return a single ODUk label. 2. When one ODU2 signal is transported into an ODU3 payload, which is sub-divided into 16 ODU1 tributary slots, the ODU1 tributary slots (here, denoted A, B, C and D with A < B < C < D) can be arbitrary selected. For instance, one ODU2 can be transported in ODU1 tributary slots 5, 12, 13 and 18. Therefore, when the upstream D.Papadimitriou - Internet Draft û Expires December 2001 21 draft-bellato-ccamp-g709-framework-00.txt June 2001 node requests in such conditions a composed ODU2 signal, the downstream node returns four labels each of them representing a pointer to an ODU1 tributary slot. 3. When a single OCh signal of 40Gbps is requested, the downstream node has to return a single wavelength label to the requestor node. 4. When a composed OCh[4.2] signal is requested i.e. a waveband or optical channel multiplex composed by four bit-rate identical OCh signal of 10Gbps, the downstream node has to return four wavelength labels to the requesting upstream node since the optical channels constituting the optical multiplex are not necessarily contiguously multiplexed. 5. When requesting multiple LSP, more than one label is returned to the requestor node. For instance, when the downstream node receives a 4 x ODU1 Generalized Label Request, it returns four labels to the upstream node: the first ODU1 label corresponding to the first signal of the LSP, the second ODU1 label corresponding to the second signal of the LSP, etc. 6. GMPLS Signalling Transport for G.709 Furthermore, standardization is further required within ITU-T to define an in-fiber/in-band signaling transport mechanism through an OTN. Here, we propose the allocation of a General Communication Channel (GCC), particularly GCC(0) at the OTUk layer and GCC(1), GCC(2) at the ODUk layer, within the optical layer overhead to transport the GMPLS signalling. Notice that [ITUT-G.709] foresees also the possibility to provide transport in-fiber/out-of-band signalling (through the use of communication channels). 6.1 ODUk General Communication Channel As defined in the [ITUT-G.709] recommendation, two fields of two bytes are allocated in the ODUk Overhead to support two General Communications Channels between any two network elements with access to the ODUk frame structure (i.e. at 3-R regeneration points). The bytes for GCC(1) are located in row 4, columns 1 and 2, and the bytes for GCC(2) are located in bytes row 4, columns 3 and 4 of the ODUk overhead. These bytes are defined as clear channels so that the format specification and their content can be defined for the purpose of in-fiber/in-band signalling transport mechanism. 6.2 OTUk General Communication Channel Similarly, one field of two bytes is allocated in the OTUk Overhead to support two General Communications Channels between any couple of network elements with access to the OTUk frame structure (i.e. D.Papadimitriou - Internet Draft û Expires December 2001 22 draft-bellato-ccamp-g709-framework-00.txt June 2001 between OTUk termination points). These GCC(0) bytes are located in row 1, columns 11 and 12 of the OTUk overhead. 7. Security Considerations Security considerations for OTN networks are not defined in this document. 8. References 1. [ITUT-G707] æNetwork node interface for the synchronous digital hierarchy (SDH)Æ, ITU-T Recommendation, March 1996. 2. [ITUT-G709] æInterface for the Optical Transport Network (OTN)Æ, ITU-T draft version, February 2001. 3. [ITUT-G872] æArchitecture of Optical Transport NetworkÆ, ITU-T draft version, February 2001. 4. [ITUT-G962] æOptical interfaces for multi-channel systems with optical amplifiersÆ, ITU-T Recommendation, October 1998. 5. [ITUT-GASTN] æAutomated Switched Transport NetworkÆ, ITU-T draft version, May 2001. 6. [ITUT-GASON] æAutomated Switched Optical NetworkÆ, ITU-T draft version, May 2001. 7. [GMPLS-ARCH] E. Mannie et al., æGeneralized Multi-Protocol Label Switching (GMPLS) ArchitectureÆ, Internet Draft, Work in progress, draft-many-gmpls-architecture-00.txt, February 2001. 8. [GMPLS-LDP] P. Ashwood-Smith et al., æGeneralized MPLS Signaling - CR-LDP ExtensionsÆ, Internet Draft, Work in progress, draft-ietf- mpls-generalized-cr-ldp-03.txt, May 2001. 9. [GMPLS-RSVP] P. Ashwood-Smith et al., æGeneralized MPLS Signaling - RSVP-TE ExtensionsÆ, Internet Draft, draft-ietf-mpls-generalized- rsvp-te-03.txt, May 2001. 10. [GMPLS-SIG] P. Ashwood-Smith et al., æGeneralized MPLS - Signaling Functional DescriptionÆ, Internet Draft, Work in progress, draft-ietf-mpls-generalized-signaling-04.txt, May 2001. 11. [GMPLS-SSS] S. Ansorge et al., æGeneralized MPLS û SDH/Sonet SpecificsÆ, Internet Draft, Work in progress, draft-ietf-ccamp-gmpls- sonet-sdh-00.txt, May 2001. 9. Acknowledgments The authors would like to be thank Bernard Sales, Emmanuel Desmet, Jean-Loup Ferrant, Mathieu Garnot and Massimo Canali for their constructive comments and inputs. D.Papadimitriou - Internet Draft û Expires December 2001 23 draft-bellato-ccamp-g709-framework-00.txt June 2001 This draft incorporates material and ideas from draft-lin-ccamp-ipo- common-label-request-00.txt. 10. Author's Addresses Michele Fontana Alcatel TND-Vimercate Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-7053 Email: michele.fontana@netit.alcatel.it Germano Gasparini Alcatel TND-Vimercate Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-7670 Email: germano.gasparini@netit.alcatel.it Alberto Bellato Alcatel TND-Vimercate Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-7215 Email: alberto.bellato@netit.alcatel.it Gert Grammel Alcatel TND-Vimercate Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-7060 Email: gert.grammel@netit.alcatel.it Jim Jones Alcatel TND-USA 3400 W. Plano Parkway, Plano, TX 75075, USA Phone: +1 972 519-2744 Email: Jim.D.Jones1@usa.alcatel.com Dimitri Papadimitriou (Editor) Senior R&D Engineer û Optical Networking Alcatel IPO-NSG Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: Dimitri.Papadimitriou@alcatel.be Eric Mannie EBone (GTS) Terhulpsesteenweg, 6A 1560 Hoeilaart, Belgium D.Papadimitriou - Internet Draft û Expires December 2001 24 draft-bellato-ccamp-g709-framework-00.txt June 2001 Phone: +32 2 658-5652 Email: eric.mannie@ebone.com Zhi-Wei Lin Lucent Technologies 101 Crawfords Corner Rd, Rm 3C-512 Holmdel, New Jersey 07733-3030, USA Tel: +1 732 949-5141 Email: zwlin@lucent.com Appendix 1 û Abbreviations 1R Re-amplification 2R Re-amplification and Re-shaping 3R Re-amplification, Re-shaping and Re-timing AI Adapted information AIS Alarm Indication Signal APS Automatic Protection Switching BDI Backward Defect Indication BEI Backward Error Indication BI Backward Indication BIP Bit Interleaved Parity CBR Constant Bit Rate CI Characteristic information CM Connection Monitoring EDC Error Detection Code EXP Experimental ExTI Expected Trace Identifier FAS Frame Alignment Signal FDI Forward Defect Indication FEC Forward Error Correction GCC General Communication Channel IaDI Intra-Domain Interface IAE Incoming Alignment Error IrDI Inter-Domain Interface MFAS MultiFrame Alignment Signal MS Maintenance Signal naOH non-associated Overhead NNI Network-to-Network interface OCC Optical Channel Carrier OCG Optical Carrier Group OCI Open Connection Indication OCh Optical Channel (with full functionality) OChr Optical Channel (with reduced functionality) ODU Optical Channel Data Unit OH Overhead OMS Optical Multiplex Section OMU Optical Multiplex Unit OOS OTM Overhead Signal OPS Optical Physical Section OPU Optical Channel Payload Unit OSC Optical Supervisory Channel D.Papadimitriou - Internet Draft û Expires December 2001 25 draft-bellato-ccamp-g709-framework-00.txt June 2001 OTH Optical transport hierarchy OTM Optical transport module OTN Optical transport network OTS Optical transmission section OTU Optical Channel Transport Unit PCC Protection Communication Channel PLD Payload PM Path Monitoring PMI Payload Missing Indication PRBS Pseudo Random Binary Sequence PSI Payload Structure Identifier PT Payload Type RES Reserved RS Reed-Solomon SM Section Monitoring TC Tandem Connection TCM Tandem Connection Monitoring UNI User-to-Network Interface Appendix 2 û G.709 Indexes - Index k: The index "k" is used to represent a supported bit rate and the different versions of OPUk, ODUk and OTUk. k=1 represents an approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate bit rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s and k = 4 an approximate bit rate of 160 Gbit/s (under definition). The exact bit-rate values are in kbits/s: . OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322 . ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983 . OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559 - Index m: The index "m" is used to represent the bit rate or set of bit rates supported on the interface. This is a one or more digit ôkö, where each ôkö represents a particular bit rate. The valid values for m are (1, 2, 3, 12, 23, 123). - Index n: The index "n" is used to represent the order of the OTM, OTS, OMS, OPS, OCG and OMU. This index represents the maximum number of wavelengths that can be supported at the lowest bit rate supported on the wavelength. It is possible that a reduced number of higher bit rate wavelengths are supported. The case n=0 represents a single channel without a specific wavelength assigned to the channel. - Index r: The index "r", if present, is used to indicate a reduced functionality OTM, OCG, OCC and OCh (non-associated overhead is not supported). Note that for n=0 the index r is not required as it implies always reduced functionality. D.Papadimitriou - Internet Draft û Expires December 2001 26 draft-bellato-ccamp-g709-framework-00.txt June 2001 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." D.Papadimitriou - Internet Draft û Expires December 2001 27