CCAMP Working Group Alberto Bellato (Alcatel) Category: Informational Draft Sudheer Dharanikota (Nayna) Expiration Date: May 2002 Michele Fontana (Alcatel) Germano Gasparini (Alcatel) Nasir Ghani (Sorrento) Gert Grammel (Alcatel) Dan Guo (Turin) Juergen Heiles (Siemens) Jim Jones (Alcatel) Zhi-Wei Lin (Lucent) Eric Mannie (Ebone) D. Papadimitriou (Alcatel) S. Sankaranarayanan (Lucent) Maarten Vissers (Lucent) Yong Xue (WorldCom) November 2001 Enabling GMPLS control of G.709 Optical Transport Networks - Architectural Framework - draft-bellato-ccamp-g709-framework-01.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 May 2002 1 draft-bellato-ccamp-g709-framework-01.txt November 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 Optical Transport Hierarchy (OTH) defined at the ITU-T and the relationships with the current GMPLS specification [GMPLS-ARCH]. The purpose is to determine how the current GMPLS protocol suite can be accommodated in order to encompass G.709-based optical networks. DISCLAIMER The scope of this memo is to provide basic information about ITU-T G.709 recommendation by keeping in mind the IETF CCAMP context aka Ÿhow GMPLS shall be extended in order to provide a control plane supporting G.709 OTN networks÷. Consequently, the presented view of G.709 is restricted intentionally as needed from the GMPLS perspective. Hence, the objective of this document is not to replicate the content of the ITU-T OTN recommendations. Therefore, the reader interested in going into more details is kindly invited to consult the corresponding ITU-T documents (referenced in this memo). 1. Introduction The ITU-T recommendations "Optical Transport Networks (OTN) Architecture" [ITU-T G.872] and "Interfaces for the OTN" [ITU-T G.709] specify in detail the Optical Transport Hierarchy (OTH) and corresponding functions of the interfaces for (all-)optical networks. These include the transport of transparent digital pipes, carried into optical channels by using the so-called digital wrapper layer. The OTN recommendations provide an additional degree of flexibility compared to the current pre-OTN approach (also referred to as MPLambdaS due to the similarity between Label and Lambda Switching when using MPLS for control plane purposes) as they enable the multiplexing of lower bit-rate optical channel with digital wrapper sub-structure. Consequently, the OTN provides two fundamental levels of flexibility. First in terms of optical channels (i.e. wavelengths) and second, in terms of bandwidth transmission optimization by using re-grooming capabilities without losing the integrity of the lower bit rates pipes, filled by the access network devices since the transport of the client signal is fully transparent. D.Papadimitriou - Internet Draft “ Expires May 2002 2 draft-bellato-ccamp-g709-framework-01.txt November 2001 Today, Generalized MPLS (GMPLS) efforts are directed in extending IP/MPLS well known technologies and protocols to control and manage lower non-packet based networks, in particular layered networks. Using the same framework and the same kinds of signaling and routing protocols suite to control multiple layers will not only reduce the overall complexity of designing, deploying and 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 perfectly suited for controlling each layer completely independently. Moreover, GMPLS can provide new capabilities and features for OTN such as distributed, flexible and scalable connection i.e. LSP establishment (today performed through the use of centralized Network Management Systems - NMS), multi-layer circuit establishment and distributed restoration, all methods that are of paramount importance for operators and carriers. Consequently, the Generalized MPLS (GMPLS) protocol suite (see [GMPLS-ARCH]) can undoubtedly be used as the distributed "control- plane architecture÷ requested by OTN. In this memo, we introduce the additional signalling and traffic- engineering routing extensions required to provide GMPLS control for OTNs. For this purpose, we analyze the differences between Lambda (pre-OTN) and G.709 OTN Label Switched Paths (LSP) as well as GMPLS- based control-plane implementation aspects for such networks. G.709 connectivity and GMPLS control plane integration for (all-)optical backbone networks are addressed through several illustrative and detailed examples. 2. Current Solutions In this section, we describe the G.709 OTN specification foundations as the evolution from point-to-point Dense WDM (DWDM) link through the pre-OTN developments(s). 2.1 Pre-OTN DWDM Development ITU-T describes pre-OTN WDM development for backward compatibility with state of the art equipmentËs. Pre-OTN development constitutes the early foundation of the current OTN recommendation(s) at the ITU-T (see ITU-T G.872, G.798 and G.709), but also the MPLambdaS developments at the IETF for the next generation optical networks. MPLambdaS has evolved in two ways since end 90Ës, first to the current GMPLS control plane protocol suite at the CCAMP Working Group and second to the so-called all-optical approach developed at the IPO Working Group. The next paragraphs detail the key drivers for the current pre-OTN developments. Pre-OTN DWDM has been developed during the last years in order to overcome the bandwidth limitations and increase the bit-rate per D.Papadimitriou - Internet Draft “ Expires May 2002 3 draft-bellato-ccamp-g709-framework-01.txt November 2001 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 meshed topology including Optical Cross-Connects (OXC) or Photonic Cross- Connects (PXC). Note: the following terminology is used in the next sections of this document, a PXC is defined as an all-optical device (i.e. no O/E) and an OXC as a non-transparent device (i.e. it provides O/E/O conversion at each interface) so at least bit-rate dependent. The current bandwidth bottleneck is overcome by the use of DWDM technology enabling systems. These systems allow the multiplexing of more than 160 wavelengths at 10 Gbps (i.e. 1.6 Tbps per fiber with 25 GHz spacing) by using simultaneously both the C-band and the L- band. Today, some DWDM equipment reduces the channel spacing to 12.5 GHz or/and improves the bit-rate per wavelength up to 160 Gbps. Consequently, it will be possible for instance 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). Nevertheless, the ITU-T currently refers to 50 GHz spacing within the ITU-T Grid, and in order to guarantee line interface interoperability, [ITUT-G.962] currently 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 (also referred to as a digital wrapper layer). Moreover, additional standard Transparency levels to the one defined for SONET (ANSI T1.105) and SDH (ITU-T G.707) 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 D.Papadimitriou - Internet Draft “ Expires May 2002 4 draft-bellato-ccamp-g709-framework-01.txt November 2001 layered structure defining an Optical Transport Hierarchy (OTH) comprising an optical and a digital part (or entity). The former is composed by the following layers: - Optical Transmission Section (OTS) layer: this networking 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 networking 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 switching layer provides end-to- end networking of optical channels for transparently conveying client information of various formats (e.g. SDH STM-N, Sonet STS- N, ATM, IP, etc.). The capabilities of this network layer concern With connection rearrangement for flexible routing, overhead processing, administration and maintenance functions. Note: OCh is defined as a switching layer since a connection function (OCh-CF) for this layer exists. For the three layers specified above, non-associated overhead (naOH) is transported via the Optical Supervisory Channel (OSC) in order to supervise and manage the connectivity in the optical domain. It has to be noticed that these three layers are common to both pre-OTN and OTN applications. For applications with only a single optical link and no flexibility between two 3R regenerators reduced functionality layers are defined: - Optical Physical Section (OPS): this layer represents a optical single- or multi-wavelength signal on optical media of various types with 3-R regeneration on both sides. - Reduced functionality Optical Channel (OChr): this layer represents a single optical channel over a single optical span between two 3-R regenerators. OPS and OChr have no overhead assigned. All supervision and management functions that rely on overhead are performed at the OTU layer (see below) which is also terminated at 3-R regenerators. Above the OCh/OChr layer, the G.709 Digital part is further subdivided as follows: - The Optical Channel Transport Unit (OTUk): this networking layer provides FEC capabilities and optical section protection and monitoring capabilities; it also referred to as the Digital Section layer - The Optical Channel Data Unit (ODUk): this switching layer D.Papadimitriou - Internet Draft “ Expires May 2002 5 draft-bellato-ccamp-g709-framework-01.txt November 2001 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); it also referred to the Digital Path layer - Clients signals i.e. STM-N signals, IP packets, ATM cells and Ethernet frames are mapped (meaning digitally wrapped) into the Optical Channel Payload Unit (OPUk). For each of these digital entities specified above (the OPUk mapping and ODUk/OTUk networking layers), 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 switching layers. The OTN layered transport structure (with full functionality) can be schematically represented as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== | OCh Payload Unit (OPUk) | Client Signal Adaptation +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- | OCh Data Unit (ODUk) | Digital Path Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- | OCh Transport Unit (OTUk) | Digital Section Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== | Optical Channel Layer (OCh) | Optical Channel Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- | Optical Multiplex Section OMS | Optical Multiplex Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- | Optical Transmission Section OTS | Optical Transmission Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== Note: the OPUk, ODUk and OTUk constitute the Digital Transport Hierarchy also referred to as Digital Wrapper Layer. The OTN specification supports also layered transport structure with reduced functionality that can be schematically represented as follows: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== | OCh Payload Unit (OPUk) | Client Signal Adaptation +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- | OCh Data Unit (ODUk) | Digital Path Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- | OCh Transport Unit (OTUk) | Digital Section Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== | Reduced functionality | | Optical Channel Layer (OChr) | Optical Channel Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ --------------------------- | Optical Physical Section (OPS) | Optical Multiplex | | and Physical Layer +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ =========================== In this context, the main features the optical transport hierarchy (i.e. networking layer) can be summarized as follows: D.Papadimitriou - Internet Draft “ Expires May 2002 6 draft-bellato-ccamp-g709-framework-01.txt November 2001 - It is the next step (after SDH/SONET) to support ever growing data driven needs for bandwidth and emergence of new broadband services - It provides the transparent transport for any kind of client signals including full STM-N/STS-N signals, and ODUk TDM for higher channel bit rates - It supports 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) - It enables network supervision and 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 more details in Section 4. We first give an overview of the relationship between ITU-T G.872 and G.709 recommendations. 3. Relationship between G.872 and G.709 The ITU-T G.872 recommendation is restricted to the functional description of optical transport networks that support digital signals. It defines optical networks as comprising a set of functionality providing transport, multiplexing, routing, supervision and survivability of client signals that are processed predominantly in the optical domain. This set of functionality for optical networks is described from a network level viewpoint using the generic principles defined ITU-T G.805. It provides the specific aspects concerning the optical transport network layered structure, characteristic information, client/server layer associations, network topology, and layer network functionality. In accordance with ITU-T G.805 recommendation (see [ITUT-G805]), the optical transport network is decomposed into independent transport layer networks where each layer network can be separately partitioned in a way which reflects the internal structure of that layer network. In the following functional description, optical signals are characterized by wavelength (or central frequency) and may be processed per wavelength or as a wavelength division multiplexed group of wavelengths. Latest release of ITU-T G.872 also includes the description of OTN Time Division Multiplexing (TDM) in the digital domain also referred to as ODUk multiplexing (see Section 5.2). In this context, ITU-T G.872 defines the architectural and functional aspects of OTNs while ITU-T G.709 recommendation specifies the Optical Transport Module of order n (OTM-n) interface signals required within and between OTN sub-networks. Using ITU-T terminology, the interfaces defined in the G.709 recommendation are applicable at the User to Network Interface (UNI) and Network Node Interface (NNI) if the OTN. Both interface functions are currently D.Papadimitriou - Internet Draft “ Expires May 2002 7 draft-bellato-ccamp-g709-framework-01.txt November 2001 (more than) covered by the GMPLS protocol suite and in particular by the current signalling subset of specifications (see [GMPLS-SIG]). In fact both interfaces perfectly fit within specific GMPLS profiles (out of the scope of this document). 4. Optical Transport Networks Specification 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 only functionally covered by ITU-T G.709 recommendation without limiting the implementation to a specific technology. 4.1 Optical Transport Module (OTM) The Optical Transport Hierarchy (OTH) structure is defined as specified in [ITUT-G.872] which, specifies the Optical Channel (OCh) layer. The OTH is further structured in the digital domain by sub- dividing the OCh layer which provides transparent network connections between 3R regeneration points in the OTN, in order to support multiplexing, management and supervision functions: - The fully standardized Optical Channel Transport Unit-k (OTUk) which provides supervision and conditions the signal for transport between regeneration points in the OTN (1-R, 2-R and for pre-OTN only, 3-R). - The Optical Channel Data Unit (ODUk) which provides . time division multiplexing (ODUk-TDM) . tandem connection monitoring (ODUk-TCM), . end-to-end path monitoring (ODUk-PM) - The Optical Channel Payload Unit (OPUk) which provides adaptation of client signals and thus defined as an adaptation layer The Optical Transport Module-n (OTM-n) is the information structure used to support OTN interfaces. Two OTM-n structure classes are currently 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 May 2002 8 draft-bellato-ccamp-g709-framework-01.txt November 2001 The reduced functionality OTM interfaces are defined with 3R processing at each end of the OTN. However, the full and reduced functionality interfaces are identical in the digital domain including OPUk, ODUk and OTUk. The only differ in the optical domain. The full functionality interface supports non-associated overhead for the optical layers while reduced functionality interface doesnËt. The optical layer non-associated overhead currently supports the following capabilities: - Backward and Forward Defect Indication (BDI and FDI, resp.) - Open Connection Indication (OCI) at OCh - Payload Missing Indication (PMI) at OMS and OTS - Tracing using the Trail Trace Identifier (TTI) at OTS Note: G.709 indexes k, m, n and r are described in Appendix 2. 4.1.1 Full Functional Stack: OTM-n.m With a full functional stack (OTM-n.m), the digital structure is transported by the OCh. The latter has its own overhead transported in a non-associated manner in the OTM Overhead Signal (OOS). The OCh is modulated into a wavelength to form the Optical Channel Carrier (OCC). Up to n OCC are multiplexed into an OCG-n.m using wavelength division multiplexing. Together with the OMS and the OCh non- associated overhead (OMSOH and OCHOH, respectively), the OCG-n.m constitutes the OMS layer. In a last step, the OTS non-associated overhead (OTSOH) is added to the OOS which is then transported on a dedicated optical channel also referred to as the Optical Supervisory Channel (OSC). Both OCG-n.m and OSC are transported in the OTM-n.m interface signal. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | OCh Payload Unit OPUk |A| | +-------------------------------------+-+ | Digital | OCh Data Unit ODUk |S| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v | OCh Transport Unit OTUk |N| ------------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical (Analog) Boundary | Optical Channel Layer OCh |S| ------------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optical Channel Carrier (OCC) |A| ------------------------- +-------------------------------------+-+ OCh Multiplexing | Optical Carrier Group (OCG-n.m) |A| ------------------------- +-------------------------------------+-+ | Optical Multiplex Section OMSn |N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optical Transmission Section OTSn |N| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OTM-n.m (n > 1) Where A: Adaptation “ N: Networking “ S: Switching layer D.Papadimitriou - Internet Draft “ Expires May 2002 9 draft-bellato-ccamp-g709-framework-01.txt November 2001 The order of an OTM-n is defined by the order of the OCG-n that it supports. 4.1.2 Reduced Functionality Stack: OTM-0r.m and OTM-nr.m The OTM with reduced functionality could be either - OTM-0r.m: consists of a single optical channel without a specific assigned wavelength. Non associated overhead is not supported (see Figure) - OTM-nr.m: consists of up to n multiplexed optical channels. Non associated overhead is not supported (see Figure) Note that the first version of G.709, only defines reduced functionality stack for standardized inter-domain interfaces. 1. OTM-nr.m The digital signal structure is transported by the reduced functionality Optical Channel OChr (OCh without non-associated overhead). The OChr is then modulated into a wavelength to form the reduced functionality Optical Channel Carrier (OCCr). Up to n OCCr can be multiplexed into an OCG-nr.m using wavelength division multiplexing. The OCG-nr.m is transported via the OTM-nr.m interface signal. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | OCh Payload Unit (OPUk) |A| | +-------------------------------------+-+ | Digital Domain | OCh Data Unit (ODUk) |S| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v | OCh Transport Unit (OTUk) |N| -------------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical (Analog) Boundary | Optical Channel Layer (OChr) |S| -------------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Optical Channel Carrier (OCCr) |A| -------------------------- +-------------------------------------+-+ OCh Multiplexing | Optical Carrier Group (OCG-nr.m) |A| -------------------------- +-------------------------------------+-+ | | | | Optical Physical Section (OPSn) |N| | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OTM-nr.m (n > 1) Where A: Adaptation “ N: Networking “ S: Switching layer The order of an OTM-nr is defined by the order of the OCG-nr that it supports. 2. OTM-0r.m (OTM-0.m) The digital signal structure is transported by one single reduced functionality Optical Channel (OChr) without non-associated D.Papadimitriou - Internet Draft “ Expires May 2002 10 draft-bellato-ccamp-g709-framework-01.txt November 2001 overhead. The OChr is modulated into a non-colored wavelength to form the reduced functionality Optical Channel Carrier (OCCr). Consequently, reduced functionality OTM-0r.m interface does not support wavelength division multiplexing functionality. The OCCr is transported via the OTM-0r.m (or simply OTM-0.m) interface. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | OCh Payload Unit (OPUk) |A| | +-------------------------------------+-+ | Digital Domain | OCh Data Unit (ODUk) |S| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v | OCh Transport Unit (OTUk) |N| -------------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical (Analog) Boundary | Optical Channel Layer (OChr) |S| -------------------------- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ^ | Optical Channel Carrier (OCCr) |A| | +-------------------------------------+-+ | | | | | Optical Domain | Optical Physical Section (OPS0) |N| | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ v OTM-0r.m Where A: Adaptation “ N: Networking “ S: Switching layer 4.2 Standardized OTM Interfaces In the current ITU-T G.709 version, only two sub-classes of the OTM- nr.m interfaces with reduced functionality are currently defined: OTM-0.m and OTM-16r.m. These interfaces are only defined for inter- domain interoperability purposes (while not strictly restricted to this usage). The OTM-nr.m 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-nr.m (and OTM-0r.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 across the OTM-nr.m (and OTM-0r.m) interfaces and consequently, Optical Supervisory Channel (OSC) and OTM Overhead Signal (OOS) are not supported. 4.2.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 with respect to the index m values (m = 1, 2, 3, 12, 23, 123). Notice that m = 13 bit-rate is not defined. D.Papadimitriou - Internet Draft “ Expires May 2002 11 draft-bellato-ccamp-g709-framework-01.txt November 2001 The OTM-16r.m signal is an OTM-nr.m signal with 16 Optical Channel Carriers (OCCr) numbered from OCCr #0 to OCCr #15. Moreover, the optical OSC is not present and there is no OOS either. For instance, the OTM-16r can be separated in several cases depending on the m index value: - OTM-16r.1 with up to 16 wavelengths only at 2.5 Gbps - OTM-16r.2 with up to 16 wavelengths only at 10 Gbps - OTM-16r.3 with up to 16 wavelengths only at 40 Gbps - OTM-16r.m with up to 16 wavelengths mixing all possible 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: As OPS and OChr overhead is not currently defined. The interface will use the OTUk Supervision and Management OverHead (SMOH) in this multi-wavelength interface for supervision and management. OTM-16r.m connectivity failure reports (using TIM “ Trace Identifier Mismatch) will be computed from the individual OTUk reports by means of failure correlation in fault management process. 4.2.2 OTM-0.m Interface The OTM-0.m supports a single wavelength optical channel on a single optical fiber with 3-R regeneration at each end. Three OTM-0.m interface signals are defined with respect to the index m values 1, 2 and 3; each these of them 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. Note: As OPS and OChr overhead is not currently defined. The interface will use the OTUk Supervision and Management OverHead (SMOH) in this multi-wavelength interface for supervision and management. OTM-0r.m connectivity failure reports (using TIM “ Trace Identifier Mismatch) will be computed from the individual OTUk reports by means of failure correlation in fault management process. 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 (OPU), OCh Data Unit (ODU) and OCh Transport Unit (OTU). 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 D.Papadimitriou - Internet Draft “ Expires May 2002 12 draft-bellato-ccamp-g709-framework-01.txt November 2001 (4 x 3810 Bytes) are the OPUk Overhead area (column 15 and 16) and OPUk Payload area (columns 17 to 3824). OPUk overhead includes payload type information, multiplex structure information in case of ODU multiplexing, concatenation information in case of ODU virtual concatenation and mapping specific information (e.g. justification/stuffing information and data) if needed. 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 row 1 dedicated to FA and OTUk specific alignment) and OPUk area (Columns 15 to 3824). The ODUk overhead includes connectivity supervision (trace), signal quality supervision (bit interleaved parity BIP), backward information (for single ended maintenance) and status information (e.g. alarm indication signal, open connection) for the end-to-end path and 6 levels of tandem connection monitoring. Furthermore overhead for automatic protection switching/protection control, generic communication channels (e.g. for network management communication or signaling), fault type and fault location indication and experimental use. 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 includes overhead for supervision and management purposes, frame alignment information and scrambling/line coding for clock recovery. The fully standardized OTUk (k = 1, 2, 3) frame structure is based on the ODUk frame structure and extends it with a forward error correction (FEC). The ODUk frame structure is organized in an octet based block frame structure with 4 rows and 4080 columns. Columns 1 to 3824 are the ODUk frame and columns 3825 to 4080 contain the FEC code. The OTUk overhead and frame alignment is contained in columns 1 to 14 of row 1. The ODUk overhead includes connectivity supervision (trace), signal quality supervision (bit interleaved parity BIP), backward information (for single ended maintenance) and status information (e.g. alarm indication signal, open connection). Furthermore overhead for generic communication channels also referred to as GCC (e.g. for network management communication or signaling). For frame and multi-frame alignment AIX frame alignment bytes and a multi- frame counter (for a 256 frame multi-frame) are used. D.Papadimitriou - Internet Draft “ Expires May 2002 13 draft-bellato-ccamp-g709-framework-01.txt November 2001 The whole OTUk signal including the FEC code, excluding the six frame alignment bytes is scrambled. Note: In addition to the standard OTUk, non-standardized, vendor specific OTUk formats OTUkV are allowed for intra-domain interfaces. An OTUkV has to support the same overhead as the standard OTUk, but it can use different (and enhanced) FEC schemes. 4.3.4 OCh Signal The OCh consists of the single channel payload signal and non-OCh associated overhead. The overhead includes signal status information: forward defect information for payload and overhead, and open connection indication. 4.3.5 OMS Signal The OMS consists of the multi-channel payload signal and non- associated OMS overhead. The overhead includes signal status information: forward defect information for payload and overhead, backward defect information for payload and overhead, payload missing indication. 4.3.6 OTS Signal The OTS consists of the multi-channel payload signal and non- associated OTS overhead (OTSOH). This overhead includes signal status information: backward defect information for payload and overhead, payload missing indication, and connectivity supervision information (e.g. optical section trace). 4.3.7 OTM Overhead Signal (OOS) The OOS is the digital structure that transports the OCh, OMS and OTS non-associated overhead. In addition it provides overhead for generic communication channels (e.g. network management communication, signaling, engineering order wire). The specific frame format of the OOS and overhead coding is not defined. The OOS is transported on the OSC. The OSC wavelength is not defined. 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 May 2002 14 draft-bellato-ccamp-g709-framework-01.txt November 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 OCh/OChr and the OCh/OChr is then modulated onto an OCC/OCCr. The ODUk mapping is depicted 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 In addition to the support of ODUk mapping into OTUk, the G.709 recommendation defines ODUk flexible multiplexing (or simply ODUk multiplexing). By definition, when multiplexing ODUj into ODUk (k > j) an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an ODTUG constituted by ODU tributary slots) is mapped into an OPUk. The resulting OPUk is then mapped into an ODUk. The ODUk follows then the rules defined ODUk mapping as described in the Section 4.4.1. 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 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 can be mapped into the OTU2. OTU2 Overhead and Frame Alignment Overhead and FEC are added to complete the signal for transport via an OTM signal. In brief, ODUk multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk (k > j), and in particular: - ODU1 into ODU2 multiplexing - ODU1 into ODU3 multiplexing - ODU2 into ODU3 multiplexing - ODU1 and ODU2 into ODU3 multiplexing D.Papadimitriou - Internet Draft “ Expires May 2002 15 draft-bellato-ccamp-g709-framework-01.txt November 2001 And, two levels of ODUk multiplexing are currently defined: - ODU1 multiplexing: . four ODU1 are multiplexed into one ODTUG2 mapped into one OPU2 which is then mapped into one ODU2 . sixteen ODU1 are multiplexed into one ODTUG3 mapped into one OPU3 which is then mapped into one ODU3 - ODU2 multiplexing: . four ODU2 are multiplexed into one ODTUG3 mapped into one OPU3 which is then mapped into one ODU3 The ODUk multiplexing (and mapping) is described by the following figure (where Client means Client Signal): x1 x1 OTU3 <---- ODU3 <---- OPU3 <--------------------------------- Client <--ODTUG3- | | | | |x4 |x16 x1 | | OTU2 <----------------------- ODU2 <--- OPU2 <--------------- Client | <-ODTUG2 | | | |x4 x1 -------- | OTU1 <---------------------------------------- ODU1 <- OPU1 - Client 4.4.3 ODUk Inverse Multiplexing (Virtual Concatenation) Inverse multiplexing is implemented by means of virtual concatenation of two (or more than two) ODUk signals resulting into an ODUk-Xv signal. The resulting ODUk-Xv signal can then 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 the set of X ODUk signals constituting a single connection (i.e. a single LSP), each of the X ODUk signal 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 D.Papadimitriou - Internet Draft “ Expires May 2002 16 draft-bellato-ccamp-g709-framework-01.txt November 2001 | |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. 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 OH, OMS OH, 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 payload area has been provided through the definition of different solutions depending upon the type of Client-layer signal. ITU-T G.709 defines a bit synchronous and asynchronous mapping for constant bit rate (CBR) at 2.5, 10 and 40 Gbps into OPU1, OPU2 and OPU3, respectively. The CBR signals could be for instance SDH/Sonet or 10 GbE WAN. IP and Ethernet packet mapping is defined by the G.709 specification through the use of the Generic Framing Procedure (GFP) as defined in ITU-T G.7041 recommendation. This framing procedure 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.). As such, GFP provides a generic framing for client signals. D.Papadimitriou - Internet Draft “ Expires May 2002 17 draft-bellato-ccamp-g709-framework-01.txt November 2001 Details concerning GFP are covered in Appendix 3. 5. GMPLS Signalling Extensions for G.709 Adapting the GMPLS protocol suite to control G.709 can be achieved by considering that G.709 defines an optical transport hierarchy subdivided into a digital part (also known as the ŸDigital Wrapper÷) and an optical part. In this context, adapting GMPLS to control G.709 OTN, can be achieved by considering: - a Digital Path layer by extending the previously defined ŸDigital Wrapper÷ in [GMPLS-SIG] corresponding to the ODUk switching layer. - an Optical Path layer by extending the ŸLambda÷ concept defined in [GMPLS-SIG] to the OCh switching layer. GMPLS extensions for G.709 need also to be covered by the Generalized Label Request, the Generalized Label as well as specific technology dependent fields (also referred to as traffic parameters) such as those currently assigned to the SDH/Sonet labels [GMPLS- SSS]. Moreover, since the multiplexing in the digital domain (such as ODUk multiplexing) has been considered in the updated version of the G.709 recommendation (October 2001), we can already propose a label space definition suitable for that purpose. Notice also that directly consider the usage of the G.709 ODUk (i.e. Digital Path) and OCh layers in order to define the corresponding label spaces. 5.1 G.709 Label Request Considerations A label request as defined in [GMPLS-SIG], includes a technology independent part i.e. the Generalized Label Request and a technology dependent part also referred to as the traffic parameters. 5.1.1 Technology Independent Part As defined in [GMPLS-SIG], the Generalized Label Request includes the LSP Encoding Type, Switching Type and the Generalized Protocol Identifier (G-PID) which constitutes the technology independent part of the label request. As mentioned here above, we suggest here to adapt the LSP Encoding Type, the Switching Type and the Generalized-PID (G-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: D.Papadimitriou - Internet Draft “ Expires May 2002 18 draft-bellato-ccamp-g709-framework-01.txt November 2001 - 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 without distinguishing between LSPs. 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 The fundamental point is not related to whether or not we have to introduce one or two code-points but to the fact that a single LSP Encoding Type will preclude ODUk switching when using reduced functionality point-to-point optical channels (i.e. OChr). This because the latter networking layer does not support any connection function (i.e. OChr-CF is not defined by ITU-T G.709 recommendation). Remember also here that the LSP encoding type represents the nature of the links that LSP traverses, for the sake of clarity, one assumes that when used with Ÿlayer model÷ based technologies such as G.709 OTN, the LSP Encoding type simply refers to the networking layer which determines the LSP definition. Consequently, a G.709 OCh LSP Encoding Type translates a G.709 OCh LSP request while a G.709 ODUk LSP Encoding Type a G.709 ODUk LSP request. 2. Switching Type The Switching Type indicates the type of switching that should be performed on a particular link. This field should only be used for links that advertise more than one type of switching capability. Noticed that in the context of layered networks the usage of this field is strictly optional and should not impact the processing of the other fields included in the Generalized Label Request. D.Papadimitriou - Internet Draft “ Expires May 2002 19 draft-bellato-ccamp-g709-framework-01.txt November 2001 Moreover, no additional values are to be considered in order to accommodate G.709 switching since an ODUk switching belongs to the TDM Class while OCh switching to the OCh Class. Consequently, we have a 1:1 mapping between the LSP Encoding Type and the Switching Type making this field optional for G.709 LSP requests. 3. Generalized-PID (G-PID) The G-PID (16 bits field) as defined in [GMPLS-SIG], identifies the payload carried by an LSP, i.e. an identifier of the client layer of that LSP. This identifier is used by the endpoints of the G.709 LSP. When the client payload is transported over the Digital Path layer, in addition to the payload identifiers already defined in [GMPLS- SIG], the G-PID can be defined as one of the following: - Asynchronous Constant Bit Rate (CBRa) i.e. mapping of STM-16/OC- 48, STM-64/OC-192 and STM-256/OC-768 - Bit synchronous Constant Bit Rate (CBRb) i.e. mapping of STM- 16/OC-48, STM-64/OC-192 and STM-256/OC-768 - ATM: mapping at 2.5, 10 and 40 Gbps - Non-specific client Bit Stream with Octet Timing (BSOT) i.e. Mapping of 2.5, 10 and 40 Gbps Bit Stream - Non-specific client Bit Stream without Octet Timing (BSNT) i.e. Mapping of 2.5, 10 and 40 Gbps Bit Stream - ODUj into ODUk (k > j) when performing ODU multiplexing before mapping into OTUk/OTUkV In addition, the G-PID can take one of the following definitions when the client payload is transported over the Optical Channel layer, in addition to the payload identifiers already defined in [GMPLS-SIG]: - Constant Bit Rate (CBR) i.e. mapping of STM-16/OC-48, STM-64/OC- 192 and STM-256/OC-768 - (ODUk mapped into) OTUk/OTUkV into OCh at 2.5, 10 or 40 Gbps When the client payloads such as Ethernet/MAC and IP/PPP are encapsulated through the Generic Framing Procedure (GFP) (ITU-T Rec. G.7042), we use dedicated G-PID values. Notice that additional G-PID values not defined in [GMPLS-SIG] such as ESCON, FICON and Fiber Channel could complete this list in the near future. In order to include pre-OTN developments, the G-PID can take one of the values currently defined in [GMPLS-SIG], when the client payload is transported over an Optical Channel (i.e. a lambda): - SDH: STM-16, STM-64 and STM-256 - Sonet: OC-48, OC-192 and OC-768 - Gigabit Ethernet: 1 Gbps and 10 Gbps 5.1.2 Technology Dependent Part The technology dependent of the label request also referred to as the traffic-parameters must reflect the following G.709 features: ODUk mapping, ODUk multiplexing, OCh multiplexing and Multiple D.Papadimitriou - Internet Draft “ Expires May 2002 20 draft-bellato-ccamp-g709-framework-01.txt November 2001 simultaneous requests. We also consider the support of the OTM Overhead Signal (OOS) for informational purposes only. 1. Signal Type As defined in [GMPLS-SSS], the traffic-parameters must include the technology specific G.709 Signal Types i.e. the signals processed by the GMPLS control-plane. The corresponding identifiers reflect the Signal Types requested during the LSP setup. For each G.709 switching layers specific Signal Types must be considered: ODU1, ODU2, ODU3 for the Digital Path layer and (at least one) OCh for the Optical Channel layer. In the pre-OTN case, only one Signal Type value would be needed. Note: Additional Signal Type code-points such as ODU4 (currently under definition at the ITU-T) or ODU5 could also be reserved for future considerations. 2. Multiplexing Type As defined in section 4.4, ODUk multiplexing is currently defined in the digital domain. Consequently, a dedicated field must indicate the type of multiplexing being requested during the ODUk LSP setup. The application of this field to an ODUk elementary signal results in an ODUk multiplexed signal. This multiplexing field specifies the type of multiplexing being requested for ODUk LSP. Each value of this field refers to a particular ODUk multiplexing type. Therefore we refer to this field as the Requested Multiplexing Type (RMT). This field is set to zero to indicate that no multiplexing is requested at all. This field can then allow an upstream node to indicate to a downstream node the different types of multiplexing that it supports. However, the downstream node decides which one to use according to its own rules. Several values could be set simultaneously to indicate a particular choice. Notice that this field (under the current version of the ITU-T G.709 recommendation) is not applicable. Therefore, when requesting an OCh LSP, this field is set to its default value. 3. ODUk Multiplexing A dedicated field must be considered which indicates the number of ODU tributary slots used by an ODUj when multiplexed into an ODUk (k > j) for the requested LSP, as specified by the RMT field. We refer to this field as the Number of Multiplexed Components (NMC). This field is thus irrelevant if no ODUk multiplexed signal is requested and in particular at the Optical Channel layer. D.Papadimitriou - Internet Draft “ Expires May 2002 21 draft-bellato-ccamp-g709-framework-01.txt November 2001 When applied at the Digital Path layer and requesting flexible multiplexing, in particular for ODU2 connections multiplexed into an ODU3 payload, the NMC field specifies the number of individual tributary slots constituting the requested connection. These components are still processed within the context of a single connection entity. 4. ODUk Virtual Concatenation A dedicated field must be considered to indicate the number of ODUk elementary signals to be inversely multiplexed (i.e. virtually concatenated) for the requested. We refer to this field as the Number of Virtual Components (NVC). This field is thus irrelevant if no ODUk virtually concatenated signal is requested and in particular at the Optical Channel layer. The NVC field indicates the number of ODU1, ODU2 or ODU3 elementary signals that are requested to be virtually concatenated to form a composed ODUk-Xv signal. These elementary signals must be of the same type by definition while being co-routed since belonging to a given LSP. This because GMPLS signalling implies today that all the components of a composed signal must be part of the same LSP. 5. OTM Overhead Signal (OOS) A dedicated field could optionally be provided to indicate whether or not the non-associated overhead is supported at the G.709 Optical Channel layer. This feature is thus irrelevant for the G.709 Digital Path layer by definition and for the pre-OTN Optical Channel layer since the latter does not support non-associated overhead. 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-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). D.Papadimitriou - Internet Draft “ Expires May 2002 22 draft-bellato-ccamp-g709-framework-01.txt November 2001 6. Multiplication Multiplication is the operation allowing the simultaneous setup of more than one composed signal connection using a unique LSP request. A composed signal is the resulting signal from the application of the RMT, NMC and NVC fields to an elementary Signal Type. Therefore, a dedicated field simply referred to as Multiplier must be considered in order to specify the number of identical composed signals requested for the multiplied LSP. Consequently, the multiplier field will be set to one (default value) to indicate that exactly one composed signal is being requested. Notice that current GMPLS signalling implies today that all the composed signals must be part of the same LSP. 7. Transparency Transparency could be considered for pre-OTN developments since by definition any signal transported over an OTN is fully transparent. This feature through its corresponding field referred to as Transparency is used when requesting 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 RSn STM-N/STS-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 STM-N/STS-N signals - 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 and STM-N/STS-N signals limited to a single contiguously concatenated VC-4-Nc/STS-Nc SPE 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. With pre-OTN interfaces terminating RS/Section and MS/Line overhead, the optical network must be capable to transport transparently HOVC/STS-SPE signals. This transparency type is defined as the default transparency for pre-OTN LSP and is specified value by D.Papadimitriou - Internet Draft “ Expires May 2002 23 draft-bellato-ccamp-g709-framework-01.txt November 2001 zeroing all flags (default Transport OH (TOH) transparency). We refer to [GMPLS-SSS] for an extended set of transparency flags. Pre-OTN developments also include the following cases which applies when the client signal is Gigabit Ethernet, ESCON, FICON or Fiber Channel (FC): - pre-OTN digital wrapper frame terminated; service signal is bit stream oriented and transparently passed throughout the network - pre-OTN case FEC frame terminated; service signal is bit stream oriented and transparently passed through Notice that in such a case Transparency feature is not considered in the scope of this document. 5.2 G.709 Label Space This section describes the Generalized Label space for the Digital Path and the Optical Channel Layer. 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 Channel layer (i.e. the OCh layer). The label distribution rules follows the ones defined in [GMPLS-SSS] as detailed in Section 4.2. 5.2.1 ODUk Label 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 supports the sub-levels of ODUk flexible multiplexing (or simply ODUk multiplexing). ODUk multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk (k > j), in particular: - ODU1 into ODU2 multiplexing - ODU1 into ODU3 multiplexing - ODU2 into ODU3 multiplexing - ODU1 and ODU2 into ODU3 multiplexing More precisely, ODUj into ODUk multiplexing (k > j) is defined when an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an ODTUG constituted by ODU tributary slots) which is mapped into an OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is mapped into an OTUk. Therefore, the corresponding label space structure can be defined as a tree whose root is an OTUk signal and leaves the ODUj signals (k >= j) that can be transported via the tributary slots and switched between these slots. A G.709 Digital Path layer label identifies the exact position of a particular ODUj signal in an ODUk multiplexing structure. D.Papadimitriou - Internet Draft “ Expires May 2002 24 draft-bellato-ccamp-g709-framework-01.txt November 2001 The G.709 Digital Path Layer label or ODUk label is based on definition of the three fields: k1, k2 and k3. The value of these fields self-consistently characterizes the ODUk label space. The value space of the k1, k2 and k3 fields is defined as follows: 1. k1 (1-bit) indicates: - an unstructured client signal mapped into an ODU1 (k1 = 1) via OPU1 2. k2 (3-bit) indicates: - an unstructured client signal mapped into an ODU2 (k2 = 1) via OPU2 - or the position of an ODU1 tributary slot in an ODTUG2 (k2 = 2,..,5) mapped into an ODU2 (via OPU2) 3. k3 (6-bit) indicates: - an unstructured client signal mapped into an ODU3 (k3 = 1) via OPU3 - or the position of an ODU1 tributary slot in an ODTUG3 (k3 = 2,..,17) mapped into an ODU3 (via OPU3) - or the position of an ODU2 tributary slot in an ODTUG3 (k3 = 18,..,33) mapped into an ODU3 (via OPU3) If label k[i]=1 (i = 1, 2 or 3) and labels k[j]=0 (j = 1, 2 and 3 with j=/=i), the corresponding ODUk signal ODU[i] is not structured and therefore simply mapped into the corresponding OTU[i]. We refer to this as the mapping of an ODUk into an OTUk. Therefore, the numbering starts at 1, zero is used to indicate a non-significant field. A label field equal to zero is an invalid value. Examples: - k3=0, k2=0, k1=1 indicated an ODU1 mapped into an OTU1 - k3=0, k2=1, k1=0 indicated an ODU2 mapped into an OTU2 - k3=1, k2=0, k1=0 indicates an ODU3 mapped into an OTU3 - k3=0, k2=3, k1=0 indicates the second ODU1 into an ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2 - k3=5, k2=0, k1=0 indicates the fourth ODU1 into an ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3 5.2.2 Label Distribution Rules In case of ODUk in OTUk mapping, only one of label can appear in the Label field of a Generalized Label. In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered list of the labels in the multiplex is given (this list can be restricted to only one label when needed). Each label indicates a component (ODUj tributary slot) of the multiplexed signal. The order of the labels must reflect the order of the ODUj into the multiplex (not the physical order of tributary slots). In case of ODUk virtual concatenation, the explicit ordered list of all labels in the concatenation is given. Each label indicates a D.Papadimitriou - Internet Draft “ Expires May 2002 25 draft-bellato-ccamp-g709-framework-01.txt November 2001 component of the virtually concatenated signal. The order of the labels must reflect the order of the ODUk to concatenate (not the physical order of time-slots). This representation limits virtual concatenation to remain within a single (component) link. In case of multiplication (i.e. when using the MT field), the explicit ordered list of all labels taking part in the composed signal is given. In case of multiplication of multiplexed/virtually concatenated signals, the first set of labels indicates the first multiplexed/virtually concatenated signal, the second set of labels indicates the second multiplexed/virtually concatenated signal, and so on. The above representation limits multiplication to remain within a single (component) link. 5.2.3 Optical Channel Label At the Optical Channel layer, the label space should be consistently defined as a flat space whose values reflect the local assignment of OCh identifiers corresponding to the OTM-n.m sub-interface signals (m = 1, 2 or 3). Notice that these identifiers do not cover OChr since the corresponding Connection Function (OChr-CF) between OTM- nr.m/OTM-0r.m is not yet defined in [ITUT-G798]. The OCh identifiers could be defined as specified in [GMPLS-SIG] either with absolute values: (optical) 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 former could be defined as a local or a global label space. Such an OCh label space is applicable to both OTN Optical Channel layer and pre-OTN Optical Channel layer. For this layer, label distribution rules are defined in [GMPSL-SIG]. 5.3 Applications GMPLS extensions for G.709 OTN must support the following applications: 1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) non- structured signal is transported into the payload of an OTU1 (OTU2 or OTU3), the upstream node requests results in a non- structured ODU1 (ODU2 or ODU3) signal request. 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). Since a single ODUk mapped signal is requested, the downstream node has to return a single ODUk label which can be for instance one of the following when the Signal Type = 1: - k3=0, k2=0, k1=1 indicating a single ODU1 mapped into an OTU1 - k3=0, k2=1, k1=0 indicating a single ODU2 mapped into an OTU2 - k3=1, k2=0, k1=0 indicating a single ODU3 mapped into an OTU3 D.Papadimitriou - Internet Draft “ Expires May 2002 26 draft-bellato-ccamp-g709-framework-01.txt November 2001 2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed into the payload of a structured ODU2 (or ODU3), the upstream node requests results in a multiplexed ODU1 signal request (RMT = 1). In such conditions, the downstream node has to return a unique label since the ODU1 is multiplexed into one ODTUG2 (or ODTUG3). The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or OPU3) and then mapped into the corresponding OTU2 (or OTU3). Since a single ODU1 multiplexed signal is requested the downstream node has to return a single ODU1 label which can take for instance one of the following values: - k3=0, k2=4, k1=0 indicates the third ODU1 TS into ODTUG2 - k3=2, k2=0, k1=0 indicates the first ODU1 TS into ODTUG3 - k3=7, k2=0, k1=0 indicates the sixth ODU1 TS into ODTUG3 3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is multiplexed into the payload of a structured ODU3, the upstream node requests results in a multiplexed ODU2 signal request. In such conditions, the downstream node has to return four labels since the ODU2 is multiplexed into one ODTUG3. The latter is mapped into an ODU3 (via OPU3) and then mapped into an OTU3. Since an ODU2 multiplexed signal is requested, the downstream node has to return four ODU label which can take for instance the following values: - k3=18, k2=0, k1=0 (first ODU TS into ODTUG3) - k3=22, k2=0, k1=0 (fifth ODU TS into ODTUG3) - k3=23, k2=0, k1=0 (sixth ODU TS into ODTUG3) - k3=26, k2=0, k1=0 (ninth ODU TS into ODTUG3) 4. When a single OCh signal of 40 Gbps is requested, the downstream node must return a single wavelength label as specified in [GMPLS-SIG]. 5. When requesting multiple ODUk LSP, an explicit list of labels is returned to the requestor node. When the downstream node receives a request for a 4 x ODU1 signal, it returns an ordered list of 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. For instance, the corresponding labels can take the following values: - First ODU1: k3=2, k2=0, k1=0 (first ODU1 TS into ODTUG3) - Second ODU1: k3=6, k2=0, k1=0 (fifth ODU1 TS into ODTUG3) - Third ODU1: k3=7, k2=0, k1=0 (sixth ODU1 TS into ODTUG3) - Fourth ODU1: k3=10, k2=0, k1=0 (ninth ODU1 TS into ODTUG3) 6. GMPLS Signalling Transport for G.709 Furthermore, ITU-T defines an in-fiber/in-band signaling transport mechanism through an OTN by propose the allocation of a General D.Papadimitriou - Internet Draft “ Expires May 2002 27 draft-bellato-ccamp-g709-framework-01.txt November 2001 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 in-fiber/out-of-band signalling transport mechanisms (through the use of dedicated communication channels) at the OCh layer. 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 (GCC) between any pair of 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 (GCC) between any couple of network elements with access to the OTUk frame structure (i.e. between OTUk termination points). These GCC(0) bytes are located in row 1, columns 11 and 12 of the OTUk overhead. 7. GMPLS TE-Routing Extensions for G.709 OTN TE extensions are defined for OSPF and ISIS in [OSPF-TE] and [ISIS- TE], respectively. They have been extended for GMPLS purposes in [GMPLS-OSPF-TE] and [GMPLS-ISIS-TE]. [MPLS-HIER] introduces the notion of Forwarding Adjacency (FA) while support of Link Bundling is defined in [MPLS-BDL]. The scope of the TE-Routing Extensions is restricted here to intra- domain routing. Routing information is transported by OSPF in Link State Advertisements (LSAs) grouped in OSPF PDUs, and is transported by IS-IS in Link State PDUs (LSPs). As specified in [LMP], a set of data bearing links between two adjacent LSRs is defined as a TE link (which is identified by a link ID). GMPLS integrates the TE-link notion by defining the following concepts: - links that are not Packet Switch Capable (PSC) may have TE properties; however, a Routing Adjacency (RA) cannot be brought up directly on such links - LSP can be advertised as a point-to-point TE-links in IGP routing protocol, i.e. as a Forwarding Adjacency (FA); thus, an advertised TE-link need no longer be between two direct neighbors (Forwarding D.Papadimitriou - Internet Draft “ Expires May 2002 28 draft-bellato-ccamp-g709-framework-01.txt November 2001 Adjacencies (FA) are more extensively considered in [MPLS-HIER]). - several links having the same Traffic Engineering (TE) capabilities (i.e. same TE metric, same set of Resource Class and same Link Multiplexing capability) can be advertised as a single TE-link, such TE-links are referred to as link bundles whose individual link (or data bearing links) are referred to as component links; so there is no longer a one-to-one association between a regular routing adjacency and a TE-link. G.709 defines a digital hierarchy and an optical transport hierarchy. As described in Section 2, the first one includes the Digital Path Layer (i.e. the ODUk layers) while the OTH one includes the Optical Channel Layer (i.e. the OCh layer). Consequently we can define for of each of these hierarchies a separated set of specific TLV. We refer to the first set as LD (Link Digital) and to the second as LO (Link Optical). However, we do not foresee additional extensions from the one defined in [GMPLS-OSPF-TE] and [GMPLS-ISIS- TE] for pre-OTN routing domains. Moreover for each of these sets, two specific sub-sets of information must be transported by an extended routing protocol to enable Traffic-Engineering of the G.709 LSPs (ODUk and OCh LSPs) in OTN. First, a set of information describing the TE-link capabilities (i.e. the OTM-n.m/OTM-nr.m/OTM-0.m interface capabilities) independently of their usage must be defined. Then a set of information describing the resources utilization (also referred to as ODUk or OCh component allocation) used on each TE-link, i.e. the operational status of a link. This in turn (using fine-tuned parameter configuration) will reduce the amount of static information (changes are less frequent when considering TE-link capabilities) flooded throughout the routing domain. For more dynamic TE-attributes implying more frequent changes (consider for instance the TE-link component allocation), the information flooding will be confined to the layer to which this information is relevant. Therefore, for each of these sets, new TLV are defined: 1. G.709 TE-link capabilities: - Link ODUk Mapping Capability TLV - Link ODUk Multiplexing Capability TLV - Link ODUk Virtual Concatenation Capability TLV - Link OCh Multiplexing Capability TLV 2. G.709 TE-link allocation: - Link ODUk Component Allocation TLV - Link OCh Component Allocation TLV It results from the TE-link definition (see [MPLS-BDL]) that each component link of a bundled link must have the same G.709 multiplexing and concatenation capabilities as defined hereafter. The corresponding TLVs (LD-MT, LO-MT and LD-VC) are specified once, D.Papadimitriou - Internet Draft “ Expires May 2002 29 draft-bellato-ccamp-g709-framework-01.txt November 2001 and apply to each component link. No per component information or identification is required for these TLVs. 8. Security Considerations Security considerations for OTN networks are not defined in this document. 9. 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 and Revision October 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, G.807, October 2001. 6. [ITUT-GASON] †Automated Switched Optical NetworkË, ITU-T draft version, G.8080, October 2001. 7. [GMPLS-ARCH] E. Mannie et al., †Generalized Multi-Protocol Label Switching (GMPLS) ArchitectureË, Internet Draft, Work in progress, draft-ietf-ccamp-gmpls-architecture-01.txt, July 2001. 8. [GMPLS-ISIS-TE] K. Kompella et al., †IS-IS Extensions in Support of Generalized MPLS,Ë Internet Draft, Work in progress, draft- ietf-isis-gmpls-extensions-04.txt, September 2001. 9. [GMPLS-LDP] P. Ashwood-Smith, L. Berger et al., †Generalized MPLS Signaling -CR-LDP ExtensionsË, Internet Draft, Work in progress, draft-ietf-mpls-generalized-cr-ldp-04.txt, July 2001. 10. [GMPLS-OSPF-TE] K. Kompella et al., †OSPF Extensions in Support of Generalized MPLS,Ë Internet Draft, Work in progress, draft- ietf-ccamp-ospf-gmpls-extensions-00.txt, September 2001. 11. [GMPLS-RSVP] P. Ashwood-Smith, L. Berger et al., †Generalized MPLS Signaling - RSVP-TE ExtensionsË, Internet Draft, Work in progress, draft-ietf-mpls-generalized-rsvp-te-05.txt, October 2001. 12. [GMPLS-SIG] P. Ashwood-Smith, L. Berger et al., †Generalized MPLS - Signaling Functional DescriptionË, Internet Draft, Work in progress, draft-ietf-mpls-generalized-signaling-06.txt, October 2001. D.Papadimitriou - Internet Draft “ Expires May 2002 30 draft-bellato-ccamp-g709-framework-01.txt November 2001 13. [GMPLS-SSS] E. Mannie et al., †Generalized MPLS “ SDH/Sonet SpecificsË, Internet Draft, Work in progress, draft-ietf-ccamp- gmpls-sonet-sdh-02.txt, October 2001. 14. [ISIS-TE] T. Li et al.,†IS-IS Extensions for Traffic EngineeringË, draft-ietf-isis-traffic-04.txt, Internet Draft, Work in Progress, August 2001. 15. [MPLS-BDL] K. Kompella et al., †Link Bundling in MPLS Traffic Engineering,Ë Internet Draft, draft-kompella-mpls-bundle-05.txt, March 2001. 16. [OSPF-TE] D. Katz et al., "Traffic Engineering Extensions to OSPF", draft-katz-yeung-ospf-traffic-06.txt, Internet Draft, Work in progress, September 2001. 10. 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. This draft incorporates material and ideas from draft-lin-ccamp-ipo- common-label-request-00.txt. 11. Author's Addresses Alberto Bellato Alcatel Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-7215 Email: alberto.bellato@netit.alcatel.it Michele Fontana Alcatel Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-7053 Email: michele.fontana@netit.alcatel.it Germano Gasparini Alcatel Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-7670 Email: germano.gasparini@netit.alcatel.it Nasir Ghani Sorrento Networks 9990 Mesa Rim Road, San Diego, CA 92121, USA D.Papadimitriou - Internet Draft “ Expires May 2002 31 draft-bellato-ccamp-g709-framework-01.txt November 2001 Phone: +1 858 646-7192 Email: nghani@sorrentonet.com Gert Grammel Alcatel Via Trento 30, I-20059 Vimercate, Italy Phone: +39 039 686-7060 Email: gert.grammel@netit.alcatel.it Dan Guo Turin Networks 1415 N. McDowell Blvd Petaluma, CA 94954, USA Phone: +1 707 665-4357 Email: dguo@turinnetworks.com Juergen Heiles Siemens AG Hofmannstr. 51 D-81379 Munich, Germany Phone: +49 89 722 - 486 64 Email: Juergen.Heiles@icn.siemens.de Jim Jones Alcatel 3400 W. Plano Parkway, Plano, TX 75075, USA Phone: +1 972 519-2744 Email: Jim.D.Jones1@usa.alcatel.com Zhi-Wei Lin Lucent 101 Crawfords Corner Rd, Rm 3C-512 Holmdel, NJ 07733-3030, USA Phone: +1 732 949-5141 Email: zwlin@lucent.com Dimitri Papadimitriou (Editor) Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: dimitri.papadimitriou@alcatel.be Siva Sankaranarayanan Lucent 101 Crawfords Corner Rd Holmdel, NJ 07733-3030, USA Email: siva@hotair.hobl.lucent.com Maarten Vissers Lucent D.Papadimitriou - Internet Draft “ Expires May 2002 32 draft-bellato-ccamp-g709-framework-01.txt November 2001 Boterstraat 45, PB-18 1270 AA Huizen, Netherlands Email: mvissers@lucent.com Yong Xue WorldCom 22001 Loudoun County Parkway Ashburn, VA 20147, USA Phone: +1 703 886-5358 E-mail: yong.xue@wcom.com D.Papadimitriou - Internet Draft “ Expires May 2002 33 draft-bellato-ccamp-g709-framework-01.txt November 2001 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 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 D.Papadimitriou - Internet Draft “ Expires May 2002 34 draft-bellato-ccamp-g709-framework-01.txt November 2001 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. Appendix 3 - Client Signal Mapping and GFP Generic Framing Procedure (GFP) provides a generic mechanism to adapt traffic from higher-layer client signals over SONET/SDH or OTNs. Client signals may be PDU-oriented (such as IP/PPP or Ethernet MAC), block-code-oriented such as Enterprise System Connect (ESCON), Fiber Connection (FICON), Fibre Channel (FC), or a Constant Bit Rate (CBR) stream. GFP consists of both common and client-specific aspects. Common aspects of GFP apply to all GFP-adapted traffic. Currently, two modes of client signal adaptation are defined for GFP: - a PDU-oriented adaptation mode, referred to as frame-mapped GFP - and a block-code-oriented adaptation mode, referred to as D.Papadimitriou - Internet Draft “ Expires May 2002 35 draft-bellato-ccamp-g709-framework-01.txt November 2001 transparent GFP. Client-specific mapping definitions are well underway for Ethernet/GbE frames and HDLC, with work ongoing to include other client signals including unspecified 8B/10B, ESCON, FICON, and FC. In short, GFP defines a standard framing procedure for octet- aligned, variable-length payloads for subsequent mapping into SONET/SDH synchronous payload envelopes as defined in ANSI T1.105 (v.02) or OTN G.709 OCh payloads. The GFP specification for SONET/SDH also leverages a parallel activity to standardize so-called virtual concatenation (VC) of SONET/SDH paths. In combination with VC, GFP will allow the mapping of a wide variety of data signals over SONET/SDH. Therefore 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 or simply ODUk). 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: +----------+ |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: D.Papadimitriou - Internet Draft “ Expires May 2002 36 draft-bellato-ccamp-g709-framework-01.txt November 2001 - 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. D.Papadimitriou - Internet Draft “ Expires May 2002 37 draft-bellato-ccamp-g709-framework-01.txt November 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 May 2002 38