[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
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