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

Versions: 00 01                                                         
CCAMP Working Group                           Alberto Bellato (Alcatel)
Category: Internet Draft                      Michele Fontana (Alcatel)
Expiration Date: December 2001              Germano Gasparini (Alcatel)
                                                 Gert Grammel (Alcatel)
                                                    Jim Jones (Alcatel)
                                                   Zhi-Wei Lin (Lucent)
                                                    Eric Mannie (Ebone)
                                        Dimitri Papadimitriou (Alcatel)
                                         Siva Sankaranarayanan (Lucent)
                                               Maarten Vissers (Lucent)

                                                              June 2001



        G.709 Optical Transport Networks GMPLS Control Framework

                 draft-bellato-ccamp-g709-framework-00.txt



Status of this Memo

   This document is an Internet-Draft and is in full conformance with
      all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or obsoleted by other
   documents at any time. It is inappropriate to use Internet- Drafts
   as reference material or to cite them other than as "work in
   progress."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt
   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   Conventions used in this document:
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
   this document are to be interpreted as described in RFC-2119 [2].












D.Papadimitriou - Internet Draft û Expires December 2001             1

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


Abstract

   Along with the current development of packet over lambda switching
   (referred to as MPLambdaS), there are considerable developments in
   optical transport systems based on the ITU-T G.872 [ITUT-G872] and
   G.709 [ITUT-G709] specification. The Optical Transport Network (OTN)
   defined in G.872 and G.709 enables ultra-long-haul transmission of
   various client signal types through the use of Forward Error
   Correction (FEC) bytes. G.709 specifies the data plane transport
   structure and allocates overhead bytes for the OTN control plane.

   In this document, we describe the G.709 Digital and Optical
   Transport Hierarchies (OTH) defined at the ITU-T and the
   relationships with the current GMPLS specification [GMPLS-ARCH].
   This in order to specify how current GMPLS Signalling specification
   [GMPLS-SIG] can be accommodated in order to encompass these
   hierarchies to extend GMPLS signalling for OTN.

1. Introduction

   Recently, the ITU-T finalized the first version of the Optical
   Transport Networks (OTN) standardization [ITUT-G709] to provide the
   transparent digital pipe (digital wrapper) to be transported into
   optical channels.

   The OTN provides two fundamental degrees of flexibility: in terms of
   wavelength and in terms of bandwidth transmission optimization
   without losing the integrity of the lower bit rates pipes filled by
   the access network. From that perspective, the OTN specification
   enables as well the control of all-optical sub-networks.

   However, the OTN architecture has today no explicit association with
   any IP-based control plane, without which the future deployment of
   OTN equipment is clearly uncertain. Therefore, [ITUT-G709] foresees
   a strong requirement for future evolutions that can provide explicit
   support for the OTN control layer. Requirements for the definition
   of the OTN control plane (also referred to as Automatic Switched
   Transport Network û ASON) are currently under definition at the ITU-
   T.

   Consequently, Generalized MPLS (GMPLS) as specified in [GMPLS-SIG],
   can more than certainly provide the efficient "control-plane
   service" needed by the OTN specifications. Moreover, GMPLS can give
   fundamental indications in terms of how OTN can be controlled and
   where some additional features have to added (if needed) at the
   optical transmission layer level, in order to hit the goal of
   intelligent optical networks.

   Today, GMPLS efforts are directed in extending IP well known
   technology to control and manage lower non-packet based layered
   networks. Using the same framework and the same kinds of signalling
   and routing protocols suite to control multiple layers will not only
   reduce the overall complexity of designing, deploying and

D.Papadimitriou - Internet Draft û Expires December 2001             2

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   maintaining OTN networks but also allow potentially two contiguous
   layers to inter-operate when using either an overlay, an augmented
   or a peer model. In the mean time, GMPLS is very suitable for
   controlling each layer completely independently.

   Moreover, GMPLS can provide new capabilities and features for OTN
   such as flexible and distributed LSP establishment (today performed
   through the use of centralized Network Management Systems - NMS),
   multi-layer circuit establishment and GMPLS-based restoration
   methods that are of paramount importance for operators and carriers.

2. Current Solutions

   In this section, we describe the G.709 specification foundations.

2.1 Pre-OTN DWDM Development

   ITU-T G.709 describes also pre-OTN WDM development for backward
   compatibility with state of the art equipmentÆs. Pre-OTN development
   has generated the current OTN development at the ITU-T but also the
   current MPLambdaS and All-optical developments at the IETF for the
   next generation optical networks.

   Pre-OTN DWDM has been developed during the last years in order to
   overcome the bandwidth limitations and increase the bit-rate per
   fiber until several Tbps per fiber. Tomorrow, pre-OTN DWDM systems
   will provide up to 1000 wavelengths at 2.5 Gbps (or 500 x 10 Gbps or
   250 x 40 Gbps) per fiber. This development includes the definition
   of point-to-point DWDM optical channels on top of a mesh optical
   topology including Optical Cross-Connects (OXC) or Photonic Cross-
   Connects (PXC). A PXC is defined as an all-optical device (i.e. no
   O/E) and an OXC as a bit-rate transparent device (i.e. it provides
   O/E/O conversion at each interface).

   The signalling paradigm developed for Lambda-switched LSP-capable
   networks has been included of the MPLS signalling paradigm. The MPLS
   generalization for fiber (space switching) lambda (wavelength
   switching), TDM (circuit switching) and packet LSPs (packet
   switching) is referred to as Generalized MPLS [GMPLS-SIG].

   The current bandwidth bottleneck is overcome by the use of DWDM
   systems. DWDM systems allow the multiplexing of more than 160
   wavelengths of 10 Gbps (1.6 Tbps per fiber with a 25 GHz spacing) by
   using simultaneously both the C-band and the L-band. Today, some
   vendors are proposing a lambda spacing of 12.5 GHz. Consequently, it
   will be possible to house 320 wavelengths of 10 Gbps in a single
   fiber (for a total throughput of 3.2 Terabits per fiber).

   A complementary method for increasing the effective capacity of a
   DWDM system is to include the 1480nm (S-Band) and 1650nm (U-Band)
   together with the deployment of fibers covering an ultra-wide
   waveband from 1460 to 1675nm (i.e. from the S-Band to the U-Band).


D.Papadimitriou - Internet Draft û Expires December 2001             3

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   Nevertheless, the ITU-T currently refers to 50 GHz spacing within
   the so-called ITU-T Grid, and in order to guarantee line interface
   interoperability, [ITUT-G.962] recommends 200 GHz wavelength
   spacing.

   In the pre-OTN application, client signals (STM-N, STS-N, GbE, IP,
   etc.) are directly mapped on wavelength through the use of a
   mapping-framing variable-length layer. This means that this
   development does not include G.709 client-signal mapping
   specification through the definition of a dedicated framing
   protocol.

   Moreover, additional standard Transparency levels to the one defined
   for SONET/SDH networks are defined for pre-OTN networks.

2.2 OTN Standard

   Optical networks include a set of functionality providing transport,
   multiplexing, routing, supervision and survivability of client
   signals that are processed predominantly in the optical domain.
   Optical signals are characterized by wavelength and may be processed
   per wavelength or as a wavelength division multiplexed group.

   The OTN model is decomposed into independent (transport) network
   layers where each layer can be separately partitioned in a way that
   reflects its internal structure. So that the OTN model refers to a
   layered structure comprising a Digital and an Optical Transport
   Hierarchy (OTH). The latter is constituted by the following network
   layers:

   - Optical Transmission Section (OTS) layer: This network layer
     provides functionality for transmission of optical signals on
     optical media of various types. This layer ensures the integrity
     and maintenance of the optical transmitted signal by overhead
     processing

   - Optical Multiplex Section (OMS) layer: This network layer provides
     functionality for networking of a multi-wavelength optical signal.
     A "multi-wavelength" signal includes the case of just one optical
     channel. This layer ensures the integrity and maintenance of the
     multi-wavelength signal by overhead processing.

   - Optical Channel (OCh) layer: this network layer provides end-to-
     end networking of optical channels for transparently conveying
     client information of various formats (e.g. SDH STM-N, Sonet OC-N,
     ATM, IP, etc.). The capabilities of this network layer concern
     With connection rearrangement for flexible routing, overhead
     processing, administration and maintenance functions.

   For the three layers specified above, non-associated overhead is
   transported via the Optical Supervisory Channel (OSC) in order to
   manage the optical connectivity. It has to be noted that these three
   layers are common to both pre-OTN and OTN applications.

D.Papadimitriou - Internet Draft û Expires December 2001             4

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   As far as the client signal handling is concerned, the Digital
   Wrapper layer is further layered as follows:
   - The Optical Channel Transport Unit (OTUk) provides FEC
     capabilities and optical section protection and monitoring
     capabilities.
   - The Optical Channel Data Unit (ODUk) layer provides client
     independent connectivity, connection protection and monitoring
     (also without the need to terminate the overhead information,
     the ODUk overhead may be monitored non-intrusively).
   - Clients signals i.e. STM-N signals, IP packets, ATM cells and
     Ethernet frames are mapped (meaning digitally wrapped) into a new
     structured frame defined as Optical Channel Payload Unit (OPUk).

   For each of the three layers specified above, an associated (in-
   band) overhead carrying the management information is added inside
   the framed structure itself. Notice, that only the ODUk (k= 1, 2, 3)
   and OCh are defined today as networking layers. The OTN layered
   transport structure can be schematically represented as follows:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========================
      | OCh Payload Unit (OPUk)           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------------------
      | OCh Data Unit (ODUk)              | Digital Path Layer
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---------------------------
      | OCh Transport Unit (OTUk)         | Digital Section Layer
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========================
      | Optical Channel Layer (OCh)       |
      +-----------------------------------+ Optical Channel Layer
      | Optical Channel Multiplexing      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========================
      | Optical Multiplex Section OMS     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Physical Section
      | Optical Transmission Section OTS  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ===========================

   The OPUk, ODUk and OTUk layers constitute the Digital Transport
   Hierarchy also referred to as Digital Wrapper Layer.

   The development of a digital and an optical transport hierarchy
   (i.e. networking layer) is required for the following reasons:
   - It is the next step (after TDM - SDH/SONET) to support ever
     growing data driven needs for bandwidth and emergence of new
     broadband services
   - To support next generation Terabit/second per fiber via DWDM lines
     at the transport level as well as optical channels at 2.5 Gbps, 10
     Gbps and 40 Gbps bit rates at wire speed level (and in the future
     160 Gbps currently under definition)
   - To provide network operational management, planning,
     administration, survivability, and finally cost of maintenance
     limited only to the OTUk/ODUk rates of transmission without caring
     about the granularity of the client signal.

   The OTN Specification is described in details in the next section.

D.Papadimitriou - Internet Draft û Expires December 2001             5

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


4. Optical Transport Networks Specification


   The OTN specifies an Optical Transport Hierarchy (OTH) supporting
   the operation and management aspects of optical networks of various
   architectures such as point-to-point, ring and mesh architectures.

   The G.709 specification defines the interfaces of the OTN to be used
   within and between sub-networks of the optical network, in terms of:
   - Optical Transport Hierarchy (OTH)
   - functionality of the overhead in support of multi-wavelength
     optical sub-networks
   - frame structures
   - bit rates
   - formats for mapping client signals

   The OTN interfaces specifications can be applied at User to Network
   Interfaces (UNI) and Network Node Interfaces (NNI) of the OTN. The
   overhead functionality necessary for operations and management of
   optical sub-networks is also defined. For interfaces used within
   optical sub-networks, the aspects related to the interface depend on
   the optical technology progress and so are not covered by G.709
   recommendation. This is within the scope of other ITU-T
   recommendations [ITUT-G959.1].

4.1 Optical Transport Hierarchy (OTH)

   The Optical Transport Hierarchy (OTH) structure is defined as
   specified in [ITUT-G.872] that defines the Optical Channel (OCH)
   layer. The OTH further sub-structured the OCh layer in sub-layer
   networks in order to support the network management and supervision
   functions such as:

   - The Optical Channel with full (OCh) or reduced functionality
     (OChr), provides transparent network connections between 3R
     regeneration points in the OTN.

   - The fully standardized Optical Channel Transport Unit-k (OTUk)
     which provides supervision and conditions the signal for transport
     between regeneration points in the OTN (1R, 2R and for pre-OTN
     only, 3R).

   - The Optical Channel Data Unit (ODUk) which provides
        . tandem connection monitoring (ODUk-TCM),
        . end-to-end path monitoring (ODUk-PM)

  - The Optical Channel Payload Unit (OPUk) which provides adaptation
    of client signals

   The Optical Transport Module-n (OTM-n) is the information structure
   used to support OTN interfaces. Two OTM-n structures are defined:
   - OTM interfaces with full functionality (OTM-n.m)
   - OTM interfaces with reduced functionality (OTM-0.m, OTM-nr.m)


D.Papadimitriou - Internet Draft û Expires December 2001             6

draft-bellato-ccamp-g709-framework-00.txt                    June 2001



   The reduced functionality OTM interfaces are defined with 3R
   processing at each end of the OTN.

4.1.1 Full Functional Stack: OTM-n.m

   With a full functional stack (OTM-n.m), up to n OCC are multiplexed
   into an OCG-n.m using wavelength division multiplexing. The OCC
   tributary slots of the OCG-n.m can be of different size depending on
   the value of the index m (m = 1, 2, 3, 12, 23 or 123). The OCG-n.m
   is transported via the OTM-n.m.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OCh Payload Unit OPUk               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OCh Data Unit ODUk                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OCh Transport Unit OTUk             | ----------------------------
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Boundary
   | Optical Channel Layer OCh           | ----------------------------
   +-------------------------------------+
   | Optical Channel Carrier (OCC)       | ^
   +-------------------------------------+ | Wavelength Multiplexing
   | Optical Carrier Group (OCG-n.m)     | v
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Optical Multiplex Section OMSn      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Optical Transmission Section OTSn   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                 OTM-n.m (n > 1)


   For the case of the full functional OTM-n.m interfaces, the OSC is
   multiplexed into the OTM-n.m using wavelength division multiplexing.

4.1.2 Reduced Functionality Stack: OTM-0.r and OTM-nr.m

   The OTM with reduced functionality could be either
   - OTM-0: consists of a single optical channel without a specific
     wavelength assigned (see Figure)
   - OTM-nr.m: consists of up to n multiplexed optical channels. Non
     associated overhead is not supported (see Figure)

   The OTM-nr.m/OTM-0.m is the information structure used to support
   Optical Physical Section (OPS) layer connections in the OTN.

   The order of an OTM-nr is defined by the order of the OCG-nr that it
   supports. Note that the first version of G.709, only includes
   reduced functionality for standardized inter-domain interfaces
   (IrDI).

   1. OTM-nr.m


D.Papadimitriou - Internet Draft û Expires December 2001             7

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   Up to n OCCr are multiplexed into an OCG-nr.m using wavelength
   division multiplexing. The OCCr tributary slots of the OCG-r.m can
   be of different size (m = 1, 2, 3, 12, 23 or 123). The OCG-nr.m is
   transported via the OTM-nr.m.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OCh Payload Unit (OPUk)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OCh Data Unit (ODUk)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OCh Transport Unit (OTUk)           | ----------------------------
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Boundary
   | Optical Channel Layer (OChr)        | ----------------------------
   +-------------------------------------+
   | Optical Channel Carrier (OCCr)      | ^
   +-------------------------------------+ | Wavelength Multiplexing
   | Optical Carrier Group (OCG-nr.m)    | v
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                     |
   | Optical Physical Section (OPSn)     |
   |                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              OTM-nr.m (n > 1)


   2. OTM-0r.m (OTM-0.m)

   Only one OCCr tributary slot is provided so that the OCG-0r.m is not
   defined. Consequently, reduced functionality OTM-0r.m stack does not
   support wavelength division multiplexing functionality. The OCCr
   tributary slot can be of different size (m = 1, 2 or 3). The OCCr is
   transported via the OTM-0.m.

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OCh Payload Unit (OPUk)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OCh Data Unit (ODUk)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | OCh Transport Unit (OTUk)           | ----------------------------
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Optical Boundary
   | Optical Channel Layer (OChr)        | ----------------------------
   +-------------------------------------+
   | Optical Channel Carrier (OCCr)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                     |
   | Optical Physical Section (OPS0)     |
   |                                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
              OTM-0.m (n = 0)

4.2 Optical Channel Encapsulation



D.Papadimitriou - Internet Draft û Expires December 2001             8

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   An overhead is associated to the OPUk, the ODUk and the OTUk
   signals. Moreover, the OTUk signal can include a tailer FEC.

   As not indicated in the following figure, the control non-associated
   overhead at the lower OCh level is multiplexed within the OTM
   Overhead Signal (OOS) and then inserted to the OSC. The OOS is the
   information structure used for transport of OTM non-associated
   overhead over the OSC. The non-associated overhead consists of the
   Optical Transmission Section (OTS) overhead, Optical Multiplex
   Section (OMS) overhead and Optical Channel (OCh) non-associated
   overhead; it is characterized by its frame structure, bit rate and
   bandwidth.

               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               | Client PDU                        |
               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
               .                                   .
               .                                   .
               .                                   .
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |OH | OCh Payload Unit Payload (OPUk)   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |OH |     OCh Data Unit Payload (ODUk)      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |OH |         OCh Transport Unit Payload (OTUk) | FEC |
   +===============================================+=====+
   .                                                     .
   .                                                     .
   .                                                     .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |              Optical Channel Layer                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                     /
   .         --------------------------------------------
   .        /
   +-------+ +-------+ +-------+ +-------+    +-------+
   |  OCC  | |  OCC  | |  OCC  | |  OCC  |    |  OCC  |
   +-------+ +-------+ +-------+ +-------+    +-------+
   .       . .       . .       . .       .    .       .
   .       . .       . .       . .       .    .       .
   .       . .       . .       . .       .    .       .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    +-+-+-+-+
   | Optical Multiplex Section OMSn      |    |       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    |  OPS  |
   | Optical Transport Section OTSn      |    |       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    +-+-+-+-+

   The optical channel network-layer overhead bytes defined in [ITUT-
   G.709] support the following capabilities:
   - Forward Error Correction (FEC)
   - Performance Monitoring (PM)
   - Network Fault localization
   - Network Restoration Signaling

D.Papadimitriou - Internet Draft û Expires December 2001             9

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   - Network General Communications Channels (GCC)
   - Manufacturer-Specific Communications Channel

4.3 Signal Types

   Signal types defined by the [ITUT-G709] specification can be divided
   in Optical Channel Unit layer and Optical Transport Module (OTM).
   The Payload Unit layer can itself be sub-divided in OCh Payload
   Unit, OCh Data Unit and OCh Transport Unit. The Appendix 2 describes
   the indexes used within the [ITUT-G709] terminology.

4.3.1 OPUk Signal

   Optical channel Payload Unit (OPU) is defined as a structured signal
   of order k (k = 1, 2, 3) and referred to as OPUk signal. The OPUk
   frame structure is organized in an octet based block frame structure
   with 4 rows and 3810 columns. The two main areas of the OPUk frame
   (4 x 3810 Bytes) are the OPUk Overhead area (column 15 and 16) and
   OPUk Payload area (columns 17 to 3824).

4.3.2 ODUk Signal

   Optical channel Data Unit (ODU) is defined as a structured signal of
   order k (k = 1, 2, 3) and referred to as ODUk signal. The ODUk frame
   structure is organized in an octet based block frame structure with
   4 rows and 3824 columns. The two main areas of the ODUk frame are
   ODUk Overhead area (columns 1 to 14 with column 1 dedicated to FA
   and OTUk specific alignment) and OPUk area (Columns 15 to 3824 which
   are dedicated to the OPUk area).

4.3.3 OTUk Signal

   Optical channel Transport Unit (OTU) of order k (k = 1, 2, 3)
   defines the conditioning for transport over an Optical Channel
   network connection. This signal is referred to as OTUk signal. The
   OTUk (k=1,2,3) frame structure is based on the ODUk frame structure
   and extends it with a forward error correction (FEC). Scrambling is
   performed after FEC computation and insertion into the OTUk signal.

   In the OTUk signal, 256 columns are added to the ODUk frame for the
   FEC and the reserved overhead bytes in row 1, columns 9 to 14 of the
   ODUk overhead are used for OTUk specific overhead, resulting in an
   octet based block frame structure with 4 rows and 4080 columns (4 x
   4080 bytes).

4.3.4 OTM Interface Signal

   The OTM-n interface signal supports n optical channels on a single
   fiber with 3R regeneration and termination of the OTUk signal on
   each end. As 3R regeneration is performed on both sides of the OTM-
   0.m and OTM-nr.m interfaces access to OTUk overhead is available and
   maintenance as well as supervision of the interface is provided via
   this overhead. Therefore non-associated OTM overhead is not required

D.Papadimitriou - Internet Draft û Expires December 2001            10

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   across the OTM-0.m and OTM-nr.m interfaces. Consequently, Optical
   Supervisory Channel (OSC) and OTM Overhead Signal (OOS) are not
   supported.

   In the first G.709 version, only two OTM interfaces classes with
   reduced functionality are defined: OTM-0.m and OTM-16r.m.

   1. OTM-16r.m Interface

   The OTM-16r.m interface supports 16 Optical Channels (n = 16) on a
   single optical span with 3R regeneration at each end. Six OTM-16r.m
   interface signals are currently defined (m = 1, 2, 3, 12, 23, 123).

   The OTM-16r.m signal is an OTM-nr.m signal with 16 Optical Channel
   Carriers (OCCr) numbered OCCr #0 to OCCr #15. An Optical OSC is not
   present and there is no OOS either.

   For instance, the OTM16 can be separated in several cases:
   - the OTM-16r.1 (with up to 16 wavelengths only at 2.5 Gbps)
   - the OTM-16r.2 (with up to 16 wavelengths only at 10 Gbps)
   - the OTM-16r.3 (with up to 16 wavelengths only at 40 Gbps)
   - the OTM-16r.m (with up to 16 wavelengths mixing possibly bit-
    rates)

   At least one of the OCCr is in service during normal operation and
   transporting an OTUk. However, there is no predefined order in which
   the OCCrÆs are taken into service.

   Note: OTM-16r.m OPS overhead is not defined. The interface will use
   the OTUk SMOH in this multi-wavelength interface for supervision and
   management. OTM-16r.m connectivity failure (TIM) reports will be
   computed from the individual OTUk reports by means of failure
   correlation in fault management.

   2. OTM-0.m Interface

   The OTM-0.m supports a single wavelength optical channel on a single
   optical fiber with 3R regeneration at each end. Three OTM-0.m
   interface signals are defined (with m = 1, 2, 3), each carrying a
   single channel optical signal containing one OTUk (with k = 1, 2, 3)
   signal. There is neither OSC defined nor OOS for OTM-0.m.

4.4 ODUk Mapping and Multiplexing

   Since G.709 defines at the Optical Channel layer three distinct
   client payload bit rates, an Optical Channel Data Unit (ODU) frame
   has been defined for each of these bit rates. An ODUk refers to a
   bit rate k framing signal, where k = 1 (for 2.5 Gbps), 2 (for 10
   Gbps) or 3 (for 40 Gbps).

   ODUk Multiplexing will be included in the future release of G.709
   [ITUT-G709] while ODUk Mapping can be considered as the basic
   mechanism underlying the Digital Transport Hierarchy layered

D.Papadimitriou - Internet Draft û Expires December 2001            11

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   structure. Note that ODUk and OTUk layers still remain in the
   electrical domain and are referred to as Digital Path and Digital
   Section in the ITU-T G.709 recommendation.

4.4.1 ODUk Mapping

   By definition in ODUk mapping, the client signal is mapped into the
   OPUk. The OPUk is mapped into an ODUk and the ODUk is mapped into an
   OTUk. The OTUk is mapped into an OChr and the OChr is then modulated
   onto an OCCr.

   The ODUk mapping is described by the following figure:

          x1         x1
   OTU3 <---- ODU3 <---- OPU3 <--------------------------- Client PDU


                x1              x1
   OTU2 <--------------- ODU2 <---- OPU2 <---------------- Client PDU


                     x1                    x1
   OTU1 <-------------------------- ODU1 <---- OPU1 ------ Client PDU


4.4.2 ODUk Multiplexing

   By definition of ODUk multiplexing, an ODUk (or ODUk Tributary Unit
   Group) is mapped into the OPU[k+1] if k = 1 or 2 or OPU[k+2] if k =
   1. The resulting OPUk is mapped into an ODUk and the ODUk is mapped
   into an OTUk. The OTUk is mapped into an OChr and the OChr is then
   modulated onto an OCCr.

   Therefore, two levels of ODUk multiplexing can be defined:
   - ODU1 multiplexing:
     . four ODU1 are multiplexed into one OPU2 which is mapped into one
       ODU2
     . sixteen ODU1 are multiplexed into one OPU3 which is mapped into
       one ODU3
   - ODU2 multiplexing:
     . four ODU2 are multiplexed into one OPU3 which is mapped into
       one ODU3

   For instance, when multiplexing four ODU1 signals into an ODU2. The
   ODU1 signals including the Frame Alignment OH and an all-0's pattern
   in the OTUk Overhead locations are scrambled and then adapted to the
   ODU2 clock via justification (asynchronous mapping). These adapted
   ODU1 signals are byte interleaved into the OPU2 Payload area, and
   their justification control and opportunity signals are frame
   interleaved into the OPU2 Overhead area. ODU2 Overhead is added
   after which the ODU2 is mapped into the OTU2. OTU2 Overhead and
   Frame Alignment Overhead are added to complete the signal for
   transport via an OTM signal.

D.Papadimitriou - Internet Draft û Expires December 2001            12

draft-bellato-ccamp-g709-framework-00.txt                    June 2001



   The ODUk multiplexing is described by the following figure:

          x1         x1
   OTU3 <---- ODU3 <---- OPU3 <---------------------------- Client PDU
                           |  <--
                         x4|     |x16
                x1         |     |
   OTU2 <--------------- ODU2 <----- OPU2 <---------------- Client PDU
                                 |     |
                                 |     |x4
                     x1           --   |    x1
   OTU1 <--------------------------- ODU1 <---- OPU1 ------ Client PDU


4.4.3 ODUk Inverse Multiplexing

   Inverse multiplexing is currently under specification at the ITU-T.
   It should be implemented by means of virtual concatenation of two or
   more than two ODUk signals (defined as ODUk-Xv). The ODUk-Xv signal
   can transport a non-OTN client signal (for instance, an ODU2-4v may
   transport an STM-256).

   The characteristic information of a virtual concatenated ODUk (ODUk-
   Xv) layer network is transported via a set of X ODUk LSP, each LSP
   having its own transfer delay. The egress LSR terminating the ODUk-
   Xv LSP has to compensate this differential delay in order to provide
   a contiguous payload at the output.

4.5 Wavelength Division Multiplexing

   With reduced stack functionality: up to n (n >= 1) OCCr are
   multiplexed into an OCG-nr.m using wavelength division multiplexing.
   The OCCr tributary slots of the OCG-nr.m can be of different size.
   The OCG-nr.m is transported via the OTM-nr.m.

                                              x1             x1
                            -------- OCCr <-------- OChr <-------- OTU3
                           |
                           |xi
                x1         |     xj           x1             x1
   OTM-nr.m <------- OCG-nr.m <----- OCCr <-------- OChr <-------- OTU2
                           |
                           |xk
                           |                  x1             x1
                            -------- OCCr <-------- OChr <-------- OTU1

   with 1 =< i + j + k =< n

   With full stack functionality: up to n (n >= 1) OCC are multiplexed
   into an OCG-n.m using wavelength division multiplexing. The OCC
   tributary slots of the OCG-n.m can be of different size. The OCG-n.m
   is transported via the OTM-n.m.

D.Papadimitriou - Internet Draft û Expires December 2001            13

draft-bellato-ccamp-g709-framework-00.txt                    June 2001




                                             x1             x1
                           --------- OCC <-------- OCh <-------- OTU3
                          |
                          |xi
                x1        |     xj           x1             x1
    OTM-n.m <------- OCG-n.m <------ OCC <-------- OCh <-------- OTU2
         |                |
         |                |xk
         |                |                  x1             x1
         |                 --------- OCC <-------- OCh <-------- OTU1
         |
         |      x1
          -------------- OSC <------ OOS (OTS, OMS, OCh OH)

   with 1 =< i + j + k =< n

   For the case of the full functionality OTM-n.m interfaces the OSC is
   multiplexed into the OTM-n.m using wavelength division multiplexing.

4.6 Client Signal Mapping

   The specification of the Client-layer signal encapsulation in the
   OPU layer has been provided through the definition of different
   solutions depending upon the type of Client-layer signal.

   IP and Ethernet packet mapping is defined by the G.709 specification
   through the use of the Generic Framing Procedure (GFP). This (new)
   framing has been specified in order to avoid the use of Ethernet
   framing or SDH/Sonet in order to encapsulate IP packets and other
   types of packet (such as ESCON, Fiber Channel, etc.).

   GFP is defined as a generic mechanism to transport any client layer
   over a fixed data-rate optical channels (specifically, the so-called
   OTN ODU of unit-k). This means that GFP idle frames must be
   generated when the client layer does not send data packet.
   Consequently the service offered to the client packet layer is
   strictly equivalent to the one offered in SDH.

   The Generic Framing Procedure (GFP) frame format is defined as:

   +----------+--------------------------------------------+----------+
   |  Header  |                   Payload                  |   FCS    |
   | 4 bytes  |               4 û 65535 bytes              | Optional |
   +----------+--------------------------------------------+----------+

   The header (4-bytes) is composed by a PDU Length Indicator (PLI) of
   2 bytes and a HEC (Header Error Control) of 2 bytes.

   The GFP Idle frame format, which includes a NULL PLI and a HEC of 2
   bytes, is defined as:


D.Papadimitriou - Internet Draft û Expires December 2001            14

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   +----------+
   |Idle Frame|
   |  4bytes  |
   +----------+

   GFP defines also two basic frame-oriented mechanisms:

   1. GFP Frame Multiplexing: the GFP frame multiplexing is performed
      on a frame-by-frame basis. When no frames are waiting, idle
      frames are inserted.

   2. GFP Frame Delineation Algorithm: as defined for cell delineation,
      GFP frame delineation is based on the detection of correct HEC.
      PLI is used to find the start of the next frame.

   The GFP frames constitute the OPUk payload. The corresponding OPUk
   overhead is defined as follows by the Payload Structure Identifier
   (PSI) which includes the following fields:
   - PT: Payload Type (1-byte)
   - RES: Reserved (254-bytes)

   The GFP OPUk (k = 1, 2, 3) capacity are defined such that they can
   include the following client bit rates:
   - GFP (OPU1):  2 488 320 kbit/s
   - GFP (OPU2):  9 995 276 kbit/s
   - GFP (OPU3): 40 150 519 kbit/s

   Aligning the byte structure of every GFP frame with the byte
   structure of the OPUk Payload performs the mapping of GFP frames.
   Since the GFP frames are of variable length (the mapping does not
   impose any restrictions on the maximum frame length), a frame may
   cross the OPUk frame boundary.

   GFP frames arrive as a continuous bit stream (Idle frames when no
   client packets) with a capacity that is identical to the OPUk
   payload area, due to the insertion of Idle frames at the GFP
   encapsulation stage. Note that here, the GFP frame stream is
   scrambled during encapsulation.

   As currently defined in [ITUT-G709], GFP provides also ATM Constant
   Bit Rate (CBR) û by using ATM cell multiplexing - and TDM Circuits
   Encapsulation and mapping into the OPUk payload area.

5. GMPLS Extensions for G.709

   Adapting GMPLS to control G.709 can be achieved by considering that
   G.709 defines two transport hierarchies: a digital hierarchy (also
   known as the ôDigital Wrapperö) and an optical transport hierarchy.
   First, within the digital hierarchy (the previously defined ôDigital
   Wrapperö), a Digital Path Layer is defined. Then, within the optical
   transport hierarchy, an Optical Channel layer or Optical Path layer
   including a digital OTM Overhead Signal (OOS), i.e. a non-associated
   overhead, is defined.

D.Papadimitriou - Internet Draft û Expires December 2001            15

draft-bellato-ccamp-g709-framework-00.txt                    June 2001



   GMPLS extensions for G.709 need to cover the Generalized Label
   Request, the Generalized Label as well as specific technology
   dependent fields such as those currently assigned to the SDH/Sonet
   labels [GMPLS-SSS]. Since the multiplexing in the electrical domain
   (such as ODUk multiplexing) will be added very soon into the next
   version of the G.709 recommendation, we can already specify a label
   space definition suitable for that purpose.

   As implicitly specified in GMPLS control for SDH/SONET Networks
   [GMPLS-SSS], since GFP is only used as a framing protocol we donÆt
   consider this framing layer to be included into the G.709 label
   space. Rather, we directly use the G.709 digital and optical
   transport hierarchies in order to define the corresponding label
   spaces.

5.1 G.709 Label Request Considerations

   The Generalized Label Request as defined in [GMPLS-SIG], includes a
   technology independent part and a technology dependent part (i.e.
   the traffic parameters).

5.1.1 Technology Independent Part

   As defined in [GMPLS-SIG], the LSP Encoding Type and the Generalized
   Protocol Identifier (G-PID) constitute the technology independent
   part. As mentioned here above, we suggest here to adapt the LSP
   Encoding Type and the G-PID (Generalized-PID) to accommodate G.709
   recommendation [ITUT-G709].

   1. LSP Encoding Type

   Since G.709 defines two networking layers (ODUk layers and OCh
   layer), the LSP Encoding Type can reflect these two layers or be
   considered as a common layer:

   - If an LSP Encoding Type is specified per networking layer or more
     precisely per group of functional networking layer (i.e. ODUk and
     OCh), then the Signal Type must not reflect these layers. This
     means that two LSP Encoding Types have to defined:
     . one reflecting the digital hierarchy (also referred to as the
       ôDigital Wrapperö layer) through the definition of the digital
       path layer i.e. the ODUk layers
     . the other reflecting the Optical Transport Hierarchy through the
       definition of the optical path layer i.e. the OCh layer

   - If the LSP Encoding Type is considered as a common space for G.709
     meaning that the LSP Encoding Type doesnÆt reflect the two G.709
     hierarchies, then the Signal Type must reflect these layers. This
     means that at least four Signal types must be defined: one for each
     ODUk signal and one for the OCh signal




D.Papadimitriou - Internet Draft û Expires December 2001            16

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   In the latter case only one new code-point has to be defined for the
   LSP Encoding Type while in the former case, two new code-points must
   be defined. Therefore, the current "Digital Wrapper" code defined in
   [GMPLS-SIG], could be replaced by two separated codes:
      - code for the G.709 Digital Path layer
      - code for the non-standard Digital Wrapper layer

   In the same way, two separated code points could replace the current
   defined ôLambdaö code:
      - code for the G.709 Optical Channel layer
      - code for the non-standard Lambda layer (also simply referred to
        as Lambda layer) which the pre-OTN Optical Channel layer

   Moreover, the code for the G.709 Optical Channel (OCh) layer will
   indicate the capability of an end-system to use the G.709 non-
   associated overhead (naOH) i.e. the OTM Overhead Signal (OOS)
   multiplexed into the OTM-n.m interface signal.

   2. Generalized-PID

   The Generalized-PID (G-PID) as defined in [GMPLS-SIG], identifies
   the payload carried by an LSP. The G-PID, which defines the client
   layer of that LSP, is used by the G.709 endpoints of the LSP.

   As described in [ITUT-G709], the G-PID could take one of the
   following values at the Digital Path layer, in addition to the
   payload identifiers already defined in [GMPLS-SIG]:
   - CBRa: asynchronous Constant Bit Rate i.e. STM-16/OC-48, STM-
     64/OC-192 and STM-256/OC-768
   - CBRb: bit synchronous Constant Bit Rate i.e. STM-16/OC-48, STM-
     64/OC-192 and STM-256/OC-768
   - ATM: Constant Bit Rate at 2.5, 10 and 40 Gbps
   - BSOT: non-specific client Bit Stream with Octet Timing at 2.5, 10
     and 40 Gbps
   - BSNT: non-specific client Bit Stream without Octet Timing at 2.5,
     10 and 40 Gbps

   The G-PID defined in [GMPLS-SIG] are then used when the client
   payloads are encapsulated through the GFP mapping procedure:
   Ethernet, ATM Mapping and Packets (translated by PoS). Other G-PID
   values not defined in [GMPLS-SIG] such as Escon and Fiber Channel
   could complete in the near future the list of payload mapped by
   using GFP mapping procedure.

   In order to include pre-OTN developments, the G-PID at the Optical
   Channel Layer can in addition to the G.709 Digital Path Layer (at
   2.5 Gbps i.e. ODU1, 10 Gbps i.e. ODU2 and 40 Gbps i.e. ODU3) take
   one of the values currently defined in [GMPLS-SIG], in particular:
   - SDH: STM-16, STM-64 and STM-256
   - Sonet: OC-48, OC-192 and OC-768
   - Ethernet: 1 Gbps and 10 Gbps

5.1.2 Technology Dependent Part

D.Papadimitriou - Internet Draft û Expires December 2001            17

draft-bellato-ccamp-g709-framework-00.txt                    June 2001



   The technology dependent of the Generalized Label Request also
   referred to as traffic-parameters must reflect the following G.709
   features: ODUk mapping, ODUk multiplexing, OCh multiplexing, OTM
   Overhead signal (OOS) and Transparency (only for pre-OTN).

   1. Signal Type

   As defined in [GMPLS-SSS], the traffic-parameters must include the
   technology specific G.709 networking Signal Types i.e. the signals
   processed by the GMPLS control-plane. The corresponding identifiers
   reflect the signal types requested during the LSP setup. As
   described in section 5.1, the following signal types must be
   considered: ODU1, ODU2, ODU3 and (at least one) OCh. Obviously, pre-
   OTN developments support only one OCh Signal Type value.

   Note: Additional Signal Type code-points such as ODU4 (currently
   under definition at the ITU-T) could also be reserved for future
   considerations.

   2. Multiplexing

   A second field must indicate the type of multiplexing being
   requested for ODUk LSP or OCh LSP. As defined in section 4.4, two
   kinds of multiplexing are currently defined: flexible multiplexing
   (or simply multiplexing) and inverse multiplexing.

   At the ODUk layer (i.e. digital path layer), flexible multiplexing
   as described in Section 4.4, refers to the mapping of an ODU2 into
   four arbitrary OPU3 tributary slots (i.e. each slot containing one
   ODU1) arbitrarily selected. Inverse multiplexing currently under
   definition at ITU-T should also be considered. The requested
   multiplexing type must include a default value indicating that
   neither ODUk flexible multiplexing nor ODUk inverse multiplexing is
   requested.

   At the Optical Channel layer, flexible multiplexing is not defined
   today while inverse multiplexing means that the requested composed
   signal constitutes a waveband (i.e. an optical channel multiplex). A
   waveband, denoted as OCh[j.k] (j >= 1) is defined as a non-
   contiguous set of identical optical channels j x OCh, each of them
   is associated to an OTM-x.m (x = nr or n) sub-interface signal. The
   bit rate of each OCh constituting the waveband (i.e. the composed L-
   LSP) must be identical, k is unique per OCh multiplex.

   Note: today both OTN and Pre-OTN specifications do not define the
   optical channel multiplex. Therefore, in this context, any waveband
   switching development as defined in this specification is purely
   vendor specific.

   Consequently, since the number of identical components included in
   an ODU multiplex or an OCh multiplex is arbitrary, a dedicated field
   indicating the requested number of components must also be defined

D.Papadimitriou - Internet Draft û Expires December 2001            18

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   in order to reflect individual signals constituting the requested
   LSP.

   3. OTM Overhead Signal (OOS)

   A dedicated field should indicate whether or not the non-associated
   overhead is supported at the G.709 Optical Channel layer. This
   feature is irrelevant at the G.709 Digital Path layer and the pre-
   OTN Optical Channel layer if the latter does not support non
   associated overhead (naOH).

   This field should also not restrict the transport mechanism of the
   OTM Overhead Signal (OOS) since in-fiber/out-of-band OSC and out-of-
   fiber/out-of-band transport mechanisms are allowed. This field must
   ideally support the following options:

   - With OTM-0r.m and OTM-nr.m interfaces (reduced functionality
     stack), OTM Overhead Signal (OOS) is not supported. Therefore with
     these types of interface signals, non-associated OTM overhead
     indication is not required.

   - With OTM-n.m interfaces (full functionality stack), the OOS is
     supported and mapped into the Optical Supervisory Channel (OSC)
     which is multiplexed into the OTM-n.m using wavelength division
     multiplexing.

   - With OTM-n.m interfaces or even with OTM-0.m and OTM-nr.m
     interfaces, ônon-standardö OOS can be defined to allow for instance
     interoperability with pre-OTN based devices or with any optical
     devices which does not support G.709 OOS specification. This
     specific OOS enables the use of any proprietary monitoring signal
     exchange through any kind of supervisory channel (it can be
     transport by using any kind of IP-based control channel).

   4. Transparency

   Transparency is only defined for pre-OTN developments since by
   definition any signal transported over an OTN is fully transparent.
   This feature is used to request a pre-OTN LSP (i.e. a non-standard
   Lambda-LSP) including transparency support. It may also be used to
   setup the transparency process to be applied in each intermediate
   LSR.

   As it is commonly the case today with pre-OTN capable interfaces,
   three kinds of transparency levels are currently defined:

   - SONET/SDH Pre-OTN interfaces with RS/Section and MS/Line overhead
     transparency: the pre-OTN network is capable to transport
     transparently STM-N/OC-N signals.

   - SONET/SDH Pre-OTN interfaces terminating RS/Section overhead with
     MS/Line overhead transparency: the pre-OTN network is capable to
     transport transparently MSn signals

D.Papadimitriou - Internet Draft û Expires December 2001            19

draft-bellato-ccamp-g709-framework-00.txt                    June 2001



   - SONET/SDH Pre-OTN interfaces terminating RS/Section and MS/Line
     overhead: the pre-OTN network is capable to transport
     transparently HOVC/STS-SPE signals.

   Consequently, for pre-OTN Optical Channels a specific field (in the
   Generalized Label Request) must indicate the transparency level
   requested during the L-LSP setup. However, this field is only
   relevant when the LSP Encoding Type value corresponds to the Non-
   standard Lambda layer.

5.2 G.709 Label Space

   The G.709 label space must include two sub-spaces: the first
   reflecting the digital path layer (i.e. the ODUk layers) and the
   second, the optical path layer (i.e. the OCh layer).

5.2.1 ODUk Label Space

   At the Digital Path layer (i.e. ODUk layers), G.709 defines three
   different client payload bit rates.  An Optical Data Unit (ODU)
   frame has been defined for each of these bit rates. ODUk refers to
   the frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps)
   or 3 (for 40 Gbps).

   In addition to the support of ODUk mapping into OTUk, the G.709
   label space must support the sub-levels of ODUk flexible
   multiplexing (or simply ODUk multiplexing):
   - ODU2 multiplexing:
        . The mapping of an ODU2 into four arbitrary OPU3 tributary
          slots selected arbitrarily (i.e. each slot containing one
          ODU1)
   - ODU3 multiplexing:
        . Not applicable today since higher order OPU tributary slots
          are not defined in the current [ITUT-G709] recommendation

   Defining three fields (k1, k2 and k3) self-consistently specifies
   the ODUk label space. The value space of the k1, k2 and k3 fields
   are defined as follows:
   - k1: indicates a particular ODU1 in one ODU2 (k1 = 1,..,4), ODU3
         (k1 = 5,..,20); k1 values from 21 to 84 are reserved for
         future use
   - k2: indicates a particular ODU2 in one ODU3 (k2 = 1,..,4); k2
         values from 5 to 20 are reserved for future use
   - k3: k3 values (k3 = 1,..,4) are reserved for future use

   If k1, k2 and k3 values are equal to zero, the corresponding ODUk
   are not structured, i.e. k[i]=0 (i=1,2,3) indicates that the ODU[i]
   is not structured and the ODU[i] is simply mapped into the OTU[i] as
   described in Section 4.4.




D.Papadimitriou - Internet Draft û Expires December 2001            20

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   Since k3 usage is not yet fully specified, k3 value always equals
   zero, k2 valid interval is [0,4] and k1 valid interval is [0,20].
   Thus, when used in a G.709 Generalized Label:
   - k1: indicates a particular ODU1 in one ODU2 (k1 = 1,..,4) or in
         one ODU3 (k1 = 5,..,20)
   - k2: indicates a particular ODU2 in one ODU3 (k2 = 1,..,4)

   If k1 and k2 values are equal to zero means non-significant: a
   particular ODUk is not structured, i.e. ki=0 indicates that the ODUi
   in not structured.

   Examples:

   - k2=0, k1=0 indicates a full ODU3 (full 40 Gbps).
   - k2=0, k1=3 indicates the third unstructured ODU1 in the ODU2.
   - k2=2, k1=0 indicates the second unstructured ODU2 in the ODU3.
   - k2=0, k1=8 indicates the fourth unstructured ODU1 in the ODU3.
   - k2=4, k1=2 indicates the second ODU1 of the fourth ODU2 in the
     ODU3.

5.2.2 OCh Label Space

   The OCh label space should be consistently defined as a flat value
   space whose values reflect the local assignment of OCh identifiers
   corresponding to the OTM-x.m sub-interface signals (m = 1, 2 or 3
   and x = 0r, nr or n). The OCh identifiers could be defined as
   specified in [GMPLS-SIG] either with absolute values: channel
   identifiers (Channel ID) also referred to as wavelength identifiers
   or relative values: channel spacing also referred to as inter-
   wavelength spacing. The latter is strictly confined to a per-port
   label space while the latter could be defined as a local or a global
   label space.

   Such an OCh label space is applicable to the OTN Optical Channel
   layer and the pre-OTN Optical Channel layer.

5.3 Applications

   GMPLS extensions for G.709 must support the following applications:

   1. When one ODU1 (ODU2 or ODU3) non-structured signal is transported
   into one OTU1 (OTU2 or OTU3) payload, the upstream node requests in
   a non-structured ODU1 (ODU2 or ODU3) signal. In such conditions, the
   downstream node has to return a unique label since the ODU1 (ODU2 or
   ODU3) is directly mapped into the corresponding OTU1 (OTU2 or OTU3).
   When a single ODUk signal is requested the downstream node has to
   return a single ODUk label.

   2. When one ODU2 signal is transported into an ODU3 payload, which
   is sub-divided into 16 ODU1 tributary slots, the ODU1 tributary
   slots (here, denoted A, B, C and D with A < B < C < D) can be
   arbitrary selected. For instance, one ODU2 can be transported in
   ODU1 tributary slots 5, 12, 13 and 18. Therefore, when the upstream

D.Papadimitriou - Internet Draft û Expires December 2001            21

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   node requests in such conditions a composed ODU2 signal, the
   downstream node returns four labels each of them representing a
   pointer to an ODU1 tributary slot.

   3. When a single OCh signal of 40Gbps is requested, the downstream
   node has to return a single wavelength label to the requestor node.

   4. When a composed OCh[4.2] signal is requested i.e. a waveband or
   optical channel multiplex composed by four bit-rate identical OCh
   signal of 10Gbps, the downstream node has to return four wavelength
   labels to the requesting upstream node since the optical channels
   constituting the optical multiplex are not necessarily contiguously
   multiplexed.

   5. When requesting multiple LSP, more than one label is returned to
   the requestor node. For instance, when the downstream node receives
   a 4 x ODU1 Generalized Label Request, it returns four labels to the
   upstream node: the first ODU1 label corresponding to the first
   signal of the LSP, the second ODU1 label corresponding to the second
   signal of the LSP, etc.

6. GMPLS Signalling Transport for G.709

   Furthermore, standardization is further required within ITU-T to
   define an in-fiber/in-band signaling transport mechanism through an
   OTN. Here, we propose the allocation of a General Communication
   Channel (GCC), particularly GCC(0) at the OTUk layer and GCC(1),
   GCC(2) at the ODUk layer, within the optical layer overhead to
   transport the GMPLS signalling.

   Notice that [ITUT-G.709] foresees also the possibility to provide
   transport in-fiber/out-of-band signalling (through the use of
   communication channels).

6.1 ODUk General Communication Channel

   As defined in the [ITUT-G.709] recommendation, two fields of two
   bytes are allocated in the ODUk Overhead to support two General
   Communications Channels between any two network elements with access
   to the ODUk frame structure (i.e. at 3-R regeneration points). The
   bytes for GCC(1) are located in row 4, columns 1 and 2, and the
   bytes for GCC(2) are located in bytes row 4, columns 3 and 4 of the
   ODUk overhead.

   These bytes are defined as clear channels so that the format
   specification and their content can be defined for the purpose of
   in-fiber/in-band signalling transport mechanism.

6.2 OTUk General Communication Channel

   Similarly, one field of two bytes is allocated in the OTUk Overhead
   to support two General Communications Channels between any couple of
   network elements with access to the OTUk frame structure (i.e.

D.Papadimitriou - Internet Draft û Expires December 2001            22

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   between OTUk termination points). These GCC(0) bytes are located in
   row 1, columns 11 and 12 of the OTUk overhead.

7. Security Considerations

   Security considerations for OTN networks are not defined in this
   document.

8. References

   1. [ITUT-G707] æNetwork node interface for the synchronous digital
   hierarchy (SDH)Æ, ITU-T Recommendation, March 1996.

   2. [ITUT-G709] æInterface for the Optical Transport Network (OTN)Æ,
   ITU-T draft version, February 2001.

   3. [ITUT-G872] æArchitecture of Optical Transport NetworkÆ, ITU-T
   draft version, February 2001.

   4. [ITUT-G962] æOptical interfaces for multi-channel systems with
   optical amplifiersÆ, ITU-T Recommendation, October 1998.

   5. [ITUT-GASTN] æAutomated Switched Transport NetworkÆ, ITU-T draft
   version, May 2001.

   6. [ITUT-GASON] æAutomated Switched Optical NetworkÆ, ITU-T draft
   version, May 2001.

   7. [GMPLS-ARCH] E. Mannie et al., æGeneralized Multi-Protocol Label
   Switching (GMPLS) ArchitectureÆ, Internet Draft, Work in progress,
   draft-many-gmpls-architecture-00.txt, February 2001.

   8. [GMPLS-LDP] P. Ashwood-Smith et al., æGeneralized MPLS Signaling -
   CR-LDP ExtensionsÆ, Internet Draft, Work in progress, draft-ietf-
   mpls-generalized-cr-ldp-03.txt, May 2001.

   9. [GMPLS-RSVP] P. Ashwood-Smith et al., æGeneralized MPLS Signaling
   - RSVP-TE ExtensionsÆ, Internet Draft, draft-ietf-mpls-generalized-
   rsvp-te-03.txt, May 2001.

   10. [GMPLS-SIG] P. Ashwood-Smith et al., æGeneralized MPLS -
   Signaling Functional DescriptionÆ, Internet Draft, Work in progress,
   draft-ietf-mpls-generalized-signaling-04.txt, May 2001.

   11. [GMPLS-SSS] S. Ansorge et al., æGeneralized MPLS û SDH/Sonet
   SpecificsÆ, Internet Draft, Work in progress, draft-ietf-ccamp-gmpls-
   sonet-sdh-00.txt, May 2001.

9. Acknowledgments

   The authors would like to be thank Bernard Sales, Emmanuel Desmet,
   Jean-Loup Ferrant, Mathieu Garnot and Massimo Canali for their
   constructive comments and inputs.

D.Papadimitriou - Internet Draft û Expires December 2001            23

draft-bellato-ccamp-g709-framework-00.txt                    June 2001



   This draft incorporates material and ideas from draft-lin-ccamp-ipo-
   common-label-request-00.txt.

10. Author's Addresses

   Michele Fontana
   Alcatel TND-Vimercate
   Via Trento 30,
   I-20059 Vimercate, Italy
   Phone: +39 039 686-7053
   Email: michele.fontana@netit.alcatel.it

   Germano Gasparini
   Alcatel TND-Vimercate
   Via Trento 30,
   I-20059 Vimercate, Italy
   Phone: +39 039 686-7670
   Email: germano.gasparini@netit.alcatel.it

   Alberto Bellato
   Alcatel TND-Vimercate
   Via Trento 30,
   I-20059 Vimercate, Italy
   Phone: +39 039 686-7215
   Email: alberto.bellato@netit.alcatel.it

   Gert Grammel
   Alcatel TND-Vimercate
   Via Trento 30,
   I-20059 Vimercate, Italy
   Phone: +39 039 686-7060
   Email: gert.grammel@netit.alcatel.it

   Jim Jones
   Alcatel TND-USA
   3400 W. Plano Parkway,
   Plano, TX 75075, USA
   Phone: +1 972 519-2744
   Email: Jim.D.Jones1@usa.alcatel.com

   Dimitri Papadimitriou (Editor)
   Senior R&D Engineer û Optical Networking
   Alcatel IPO-NSG
   Francis Wellesplein 1,
   B-2018 Antwerpen, Belgium
   Phone: +32 3 240-8491
   Email: Dimitri.Papadimitriou@alcatel.be

   Eric Mannie
   EBone (GTS)
   Terhulpsesteenweg, 6A
   1560 Hoeilaart, Belgium

D.Papadimitriou - Internet Draft û Expires December 2001            24

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   Phone: +32 2 658-5652
   Email: eric.mannie@ebone.com

   Zhi-Wei Lin
   Lucent Technologies
   101 Crawfords Corner Rd, Rm 3C-512
   Holmdel, New Jersey 07733-3030, USA
   Tel: +1 732 949-5141
   Email: zwlin@lucent.com


Appendix 1 û Abbreviations

   1R           Re-amplification
   2R           Re-amplification and Re-shaping
   3R           Re-amplification, Re-shaping and Re-timing
   AI           Adapted information
   AIS          Alarm Indication Signal
   APS          Automatic Protection Switching
   BDI          Backward Defect Indication
   BEI          Backward Error Indication
   BI           Backward Indication
   BIP          Bit Interleaved Parity
   CBR          Constant Bit Rate
   CI           Characteristic information
   CM           Connection Monitoring
   EDC          Error Detection Code
   EXP          Experimental
   ExTI         Expected Trace Identifier
   FAS          Frame Alignment Signal
   FDI          Forward Defect Indication
   FEC          Forward Error Correction
   GCC          General Communication Channel
   IaDI         Intra-Domain Interface
   IAE          Incoming Alignment Error
   IrDI         Inter-Domain Interface
   MFAS         MultiFrame Alignment Signal
   MS           Maintenance Signal
   naOH         non-associated Overhead
   NNI          Network-to-Network interface
   OCC          Optical Channel Carrier
   OCG          Optical Carrier Group
   OCI          Open Connection Indication
   OCh          Optical Channel (with full functionality)
   OChr         Optical Channel (with reduced functionality)
   ODU          Optical Channel Data Unit
   OH           Overhead
   OMS          Optical Multiplex Section
   OMU          Optical Multiplex Unit
   OOS          OTM Overhead Signal
   OPS          Optical Physical Section
   OPU          Optical Channel Payload Unit
   OSC          Optical Supervisory Channel

D.Papadimitriou - Internet Draft û Expires December 2001            25

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


   OTH          Optical transport hierarchy
   OTM          Optical transport module
   OTN          Optical transport network
   OTS          Optical transmission section
   OTU          Optical Channel Transport Unit
   PCC          Protection Communication Channel
   PLD          Payload
   PM           Path Monitoring
   PMI          Payload Missing Indication
   PRBS         Pseudo Random Binary Sequence
   PSI          Payload Structure Identifier
   PT           Payload Type
   RES          Reserved
   RS           Reed-Solomon
   SM           Section Monitoring
   TC           Tandem Connection
   TCM          Tandem Connection Monitoring
   UNI          User-to-Network Interface


Appendix 2 û G.709 Indexes

   - Index k: The index "k" is used to represent a supported bit rate
   and the different versions of OPUk, ODUk and OTUk. k=1 represents an
   approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate
   bit rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s
   and k = 4 an approximate bit rate of 160 Gbit/s (under definition).
   The exact bit-rate values are in kbits/s:
    . OPU: k=1: 2 488 320.000, k=2: 9 995 276.962,  k=3: 40 150 519.322
    . ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983
    . OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559

   - Index m: The index "m" is used to represent the bit rate or set of
   bit rates supported on the interface. This is a one or more digit
   ôkö, where each ôkö represents a particular bit rate. The valid
   values for m are (1, 2, 3, 12, 23, 123).

   - Index n: The index "n" is used to represent the order of the OTM,
   OTS, OMS, OPS, OCG and OMU. This index represents the maximum number
   of wavelengths that can be supported at the lowest bit rate
   supported on the wavelength. It is possible that a reduced number of
   higher bit rate wavelengths are supported. The case n=0 represents a
   single channel without a specific wavelength assigned to the
   channel.

   - Index r: The index "r", if present, is used to indicate a reduced
   functionality OTM, OCG, OCC and OCh (non-associated overhead is not
   supported). Note that for n=0 the index r is not required as it
   implies always reduced functionality.





D.Papadimitriou - Internet Draft û Expires December 2001            26

draft-bellato-ccamp-g709-framework-00.txt                    June 2001


Full Copyright Statement


   "Copyright (C) The Internet Society (date). All Rights Reserved.
   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works. However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."




























D.Papadimitriou - Internet Draft û Expires December 2001            27