[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

CCAMP Working Group                           Alberto Bellato (Alcatel)
Category: Internet Draft                    Sudheer Dharanikota (Nayna)
Expiration Date: May 2002                     Michele Fontana (Alcatel)
                                                    James Fu (Sorrento)
                                            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)
                                        Dimitri Papadimitriou (Alcatel)
                                         Siva Sankaranarayanan (Lucent)
                                               Maarten Vissers (Lucent)
                                                  Yangguang Xu (Lucent)
                                                    Yong Xue (WorldCom)

                                                          November 2001



                      GMPLS Signalling Extensions
              for G.709 Optical Transport Networks Control

                   draft-fontana-ccamp-gmpls-g709-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 et al. - Internet Draft û Expires May 2002           1

draft-fontana-ccamp-gmpls-g709-01.txt                    November 2001


Abstract

   This document is a companion to the Generalized MPLS (GMPLS)
   signalling documents [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It
   describes the G.709 technology specific information needed to
   extend GMPLS signalling to control Optical Transport Networks
   (OTN) including the so-called pre-OTN developments both described
   in [G709-FRM].

1. Introduction

   Generalized MPLS extends MPLS from supporting Packet Switching
   Capable (PSC) interfaces and switching to include support of three
   new classes of interfaces and switching: Time-Division Multiplex
   (TDM), Lambda Switch (LSC) and Fiber-Switch (FSC). A functional
   description of the extensions to MPLS signaling needed to support
   this new classes of interfaces and switching is provided in
   [GMPLS-SIG]. [GMPLS-RSVP] describes RSVP-TE specific formats and
   mechanisms needed to support all four classes of interfaces, and
   CR-LDP extensions can be found in [GMPLS-LDP].

   This document presents the technology details that are specific to
   G.709 Optical Transport Networks (OTN) as specified in the ITU-T
   G.709 recommendation [ITUT-G709] including pre-OTN developments.
   Per [GMPLS-SIG], G.709 specific parameters are carried through the
   signaling protocol in traffic parameter specific objects.

   Note: by pre-OTN developments, one refers to 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

   The other kinds of ôoptical SDH/Sonetö semi-transparent switching
   are respectively covered in [GMPLS-SSS-EXT] and [GMPLS-SSS]:
   - SONET/SDH interfaces terminating RS/Section and MS/Line
     overhead: the 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
   - 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 with RS/Section and MS/Line
     overhead transparency: the pre-OTN network is capable to
     transport transparently RSn STM-N/STS-N signals

2. GMPLS Extensions for G.709

   Although G.709 defines several networking layers (OTS, OMS, OPS,
   OCh, OChr constituting the optical transport hierarchy and OTUk,
   ODUk constituting the digital transport hierarchy) only the OCh

D.Papadimitriou et al. - Internet Draft û Expires May 2002           2

draft-fontana-ccamp-gmpls-g709-01.txt                    November 2001


   (Optical Channel) and the ODUk (Optical Channel Data Unit) layer are
   defined as switching layers. Both OCh (but not OChr) and ODUk layers
   include the overhead for supervision and management. The OCh
   overhead is transported in a non-associated manner (so also referred
   to as non-associated overhead û naOH) in the OTM Overhead Signal
   (OOS), together with the OTS and OMS non-associated overhead. The
   OOS is transported via a dedicated wavelength referred to as the
   Optical Supervisory Channel (OSC). It should be noticed that the
   naOH is only functionally specified and as such open to vendor
   specific solutions. The ODUk overhead is transported in an
   associated manner as part of the digital ODUk frame.

   Therefore, 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 to cover the Generalized Label
   Request, the Generalized Label as well as the specific technology
   dependent fields equivalent to the one currently specified for
   SDH/SONET in [GMPLS-SSS]. 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 we directly use the G.709 ODUk (i.e. Digital Path)
   and OCh layers in order to define the corresponding label spaces.

3. Generalized Label Request

   The Generalized Label Request as defined in [GMPLS-SIG], includes a
   technology independent part and a technology dependent part (i.e.
   the traffic parameters). In this section, we suggest to adapt both
   parts in order to accommodate the GMPLS Signalling to the G.709
   recommendation [ITUT-G709].

3.1 Technology Independent Part

   As defined in [GMPLS-SIG], the LSP Encoding Type and the Generalized
   Protocol Identifier (Generalized-PID) constitute the technology
   independent part of the Generalized Label Request.

   The information carried in the technology independent part of the
   Generalized Label Request is defined as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | LSP Enc. Type |Switching Type |             G-PID             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



D.Papadimitriou et al. - Internet Draft û Expires May 2002           3

draft-fontana-ccamp-gmpls-g709-01.txt                    November 2001


   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].

3.1.1 LSP Encoding Type

   Since G.709 defines two networking layers (ODUk layers and OCh
   layer), the LSP Encoding Type code-points can reflect these two
   layers currently defined in [GMPLS-SIG] as ôDigital Wrapperö and
   ôLambdaö code.

   The LSP Encoding Type is specified per networking layer or more
   precisely per group of functional networking layer: the ODUk layers
   and the OCh layer.

   Therefore, the current ôDigital Wrapperö code-point defined in
   [GMPLS-SIG] can be replaced by two separated code-points:
       - code-point for the G.709 Digital Path layer
       - code-point for the non-standard Digital Wrapper layer

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

   Consequently, we have the following additional code-points for the
   LSP Encoding Type:

        Value           Type
        -----           ----
         11             G.709 ODUk (Digital Path)
         12             G.709 Optical Channel

   Moreover, the code-point 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.

3.1.2 Switching Type

   The Switching Type indicates the type of switching that should be
   performed at the termination of a particular link. This field is
   only needed for links that advertise more than one type of switching
   capability.

   No additional values are to be considered in order to accommodate
   G.709 switching types since an ODUk switching belongs to the TDM
   class while an OCh switching to the Lambda class.




D.Papadimitriou et al. - Internet Draft û Expires May 2002           4

draft-fontana-ccamp-gmpls-g709-01.txt                    November 2001


   However, in a strict layered G.709 network architecture, when a
   downstream node receives a Generalized Label Request with one of
   these values as Switching Type, this value is ignored.

3.1.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.

   The G-PID can take one of the following values when the client
   payload is transported over the Digital Path layer, in addition to
   the payload identifiers already defined in [GMPLS-SIG]:
   - CBRa: asynchronous Constant Bit Rate i.e. mapping of STM-16/OC-48,
     STM-64/OC-192 and STM-256/OC-768
   - CBRb: bit synchronous Constant Bit Rate 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
   - BSOT: non-specific client Bit Stream with Octet Timing i.e.
     Mapping of 2.5, 10 and 40 Gbps Bit Stream
   - BSNT: non-specific client Bit Stream without Octet Timing i.e.
     Mapping of 2.5, 10 and 40 Gbps Bit Stream

   The G-PID can take one of the following values when the client
   payload is transported over the Optical Channel layer, in addition
   to the payload identifiers already defined in [GMPLS-SIG]:
   - CBR: Constant Bit Rate i.e. mapping of STM-16/OC-48, STM-64/OC-192
     and STM-256/OC-768
   - ODUk: transport of Digital Path at 2.5, 10 and 40 Gbps

   When the client payloads such as Ethernet, ATM or PPP over SONET/SDH
   (RFC 2615), are encapsulated through the Generic Framing Procedure
   (GFP), 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

   The following table summarizes the G-PID with respect to the LSP
   Encoding Type:

   Value        G-PID Type      LSP Encoding Type
   -----        ----------      -----------------
    44          G.709 ODUk      G.709 ODUk, G.709 OCh
    45          CBR/CBRa        G.709 ODUk, G.709 OCh
    46          CBRb            G.709 ODUk
    47          BSOT            G.709 ODUk
    48          BSNT            G.709 ODUk

D.Papadimitriou et al. - Internet Draft û Expires May 2002           5

draft-fontana-ccamp-gmpls-g709-01.txt                    November 2001


    49          PoS (GFP)       G.709 ODUk
    50          Ethernet (GFP)  G.709 ODUk

   The following table summarizes the update of the G-PID values
   defined in [GMPLS-SIG]:

   Value        G-PID Type      LSP Encoding Type
   -----        ----------      -----------------
    32          ATM Mapping     SONET, SDH, G.709 ODUk
    33          Ethernet (GbE)  G.709 ODUk, G.709 OCh, Lambda, Fiber
    34          SDH             G.709 ODUk, G.709 OCh, Lambda, Fiber
    35          SONET           G.709 ODUk, G.709 OCh, Lambda, Fiber

3.2 G.709 Traffic-Parameters

   When G.709 Digital Path Layer or G.709 Optical Channel Layer is
   specified in the LSP Encoding Type field, the information referred
   to as technology dependent information or simply traffic-parameters
   and carried additionally to the one included in the Generalized
   Label Request is defined as follows:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Signal Type  |      RMT      |             NMC               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              NVC              |          Multiplier           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In this frame, RMT stands for Requested Multiplexing Type, NMC for
   Number of Multiplexed Components and NVC for Number of Virtually
   multiplexed Components. Each of these fields is tailored in order to
   support G.709 LSP.

3.2.1 Signal Type

   This field (8 bits) indicates the requested G.709 elementary Signal
   Type. The possible values are:

      Value     Type
      -----     ----
        0       irrelevant
        1       ODU1 (i.e. 2.5 Gbps)
        2       ODU2 (i.e. 10  Gbps)
        3       ODU3 (i.e. 40  Gbps)
        4       Reserved for future use
        5       Reserved for future use
        6       OCh associated to an OTM-n.1
        7       OCh associated to an OTM-n.2
        8       OCh associated to an OTM-n.3
        9-255   Reserved for future use

D.Papadimitriou et al. - Internet Draft û Expires May 2002           6

draft-fontana-ccamp-gmpls-g709-01.txt                    November 2001



   The value of the Signal Type field depends on LSP Encoding Type
   value defined in Section 3.1.1 and [GMPLS-SIG]:
    - if the LSP Encoding Type value is the G.709 Digital Path layer
      then the valid values are the ODUk signals (k = 1, 2 or 3)
    - if the LSP Encoding Type value is the G.709 Optical Channel layer
      then the valid values are the OCh associated to the OTM-n.m
      interface signals (m = 1, 2 or 3)
    - if the LSP Encoding Type is ôLambdaö (which includes the
      pre-OTN Optical Channel layer) then the valid value is irrelevant
      (Signal Type = 0)
    - if the LSP Encoding Type is ôDigital Wrapperö, then the valid
      value is irrelevant (Signal Type = 0)

3.2.2 Requested Multiplexing Type (RMT)

   The RMT field (8 bits) defined as a vector of flags indicating the
   type of multiplexing being requested for ODUk LSP. Each flag
   indicates the support of a particular type of ODU multiplexing.

   These flags 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 flags could be set simultaneously to indicate a particular
   choice.

   The entire field is set to zero to indicate that no multiplexing is
   requested at all. The possible values for these flags are defined in
   the following table:

        Flag 1 (bit 1):  Flexible multiplexing

   When used at the ODUk layer (i.e. digital path layer), application
   of flexible multiplexing to ODUk elementary signal results in so
   called ODUk-Xc signal. In particular, ODUk multiplexing allows the
   multiplexing of an ODU2 into four ODU tributary slots, which can be
   arbitrarily selected to prevent that the bandwidth gets fragmented.

   As described in [G709-FRM], in addition to the support of ODUk
   mapping into OTUk, [ITUT-G.709] supports ODUk flexible multiplexing
   (or simply multiplexing). It refers to the multiplexing of ODUj (j =
   1, 2) into an ODUk (k > j) signal, 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.


D.Papadimitriou et al. - Internet Draft û Expires May 2002           7

draft-fontana-ccamp-gmpls-g709-01.txt                    November 2001


   The RMT field is set to zero (by default) to indicate an ODUk
   mapping i.e. ODUk flexible multiplexing is not requested.

   At the Optical Channel layer, flexible multiplexing is not defined
   in [ITU-T G.709]. Therefore, the entire RMT field is set by default
   to zero when requesting an OCh G.709 LSP.

3.2.3 Number of Multiplexed Components (NMC)

   The NMC field (16 bits) indicates the number of ODU tributary slots
   used by an ODUj when multiplexed into an ODUk (k > j) for the
   requested LSP, as specified in the RMT field. This field is
   irrelevant if no multiplexing is requested (in particular at the
   Optical Channel layer). In that case, it must be set to zero (NMC =
   0) when sent and should be ignored when received. An RMT value
   different from 0 must imply a number of components greater or equal
   to 1.

   When applied at the Digital Path layer and requesting flexible
   multiplexing (RMT = 1), in particular for ODU2 connections
   multiplexed into an ODU3 payload, the NMC field specifies the number
   of individual tributary slots (NMC = 4) constituting the requested
   connection. These components are still processed within the context
   of a single connection entity. For all other currently defined
   multiplexing cases, the NMC field is set to 1.

3.2.4 Number of Virtually concatenated Components (NVC)

   The NVC field (16 bits) is dedicated to Inverse Multiplexing (i.e.
   ODUk virtual concatenation) purposes. It indicates the number of
   ODU1, ODU2 or ODU3 elementary signals that are requested to be
   virtually concatenated to form an ODUk-Xv signal. These signals must
   be of the same type by definition.

   This field is set to 0 (default value) to indicate that no virtual
   concatenation is requested.

   Note: the current usage of this field only applies for G.709 ODUk
   LSP. Therefore, it must be set to zero when requesting G.709 OCh
   LSP.

3.2.5 Multiplier

   The multiplier field (16 bits) indicates the number of identical
   composed signals requested for the LSP. A composed signal is the
   resulting signal from the application of the RMT, NMC and NVC fields
   to an elementary Signal Type. GMPLS signalling implies today that
   all the composed signals must be part of the same LSP.

   The multiplier field is set to one (default value) to indicate that
   exactly one base signal is being requested. Zero is an invalid
   value. When the multiplier field is greater than one, the resulting
   signal is referred to as a multiplied signal.


D.Papadimitriou et al. - Internet Draft û Expires May 2002           8

draft-fontana-ccamp-gmpls-g709-01.txt                    November 2001



3.2.6 Reserved

   The reserved field (32 bits) is dedicated for future use. Reserved
   bits should be set to zero when sent and must be ignored when
   received.

4. Generalized Label

   This section describes the Generalized Label space for the Digital
   Path and the Optical Channel Layer. The label distribution rules
   follows the ones defined in [GMPLS-SSS] and are detailed in Section
   4.2.

4.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 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 label space structure is 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.

   The G.709 Digital Path Layer label or ODUk label has the following
   format:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                   Reserved                |     k3    | k2  |k1|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



D.Papadimitriou et al. - Internet Draft û Expires May 2002           9

draft-fontana-ccamp-gmpls-g709-01.txt                    November 2001


   The specification of the three fields k1, k2 and k3 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

4.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 NMC = 1). 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
   component of the virtually concatenated signal. The order of the

D.Papadimitriou et al. - Internet Draft û Expires May 2002          10

draft-fontana-ccamp-gmpls-g709-01.txt                    November 2001


   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.

4.3 Optical Channel Label Space

   At the Optical Channel layer, the label space must 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: 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. Applications

   These applications examples are given in order to illustrate the
   processing described in the previous sections.

   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 (Signal Type = 1, 2 or 3 and RMT = 0), 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

   2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed

D.Papadimitriou et al. - Internet Draft û Expires May 2002          11

draft-fontana-ccamp-gmpls-g709-01.txt                    November 2001


      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 (Signal Type
      = 1, RMT = 1 and NMC = 1), 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 (RMT =
      1).

      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 a single ODU2 multiplexed signal is requested (Signal Type
      = 2, RMT = 1 and NMC = 4), the downstream node has to return
      four ODU1 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 (Signal Type = 8
      and RMT = 0), the downstream node must return a single wavelength
      label as specified in [GMPLS-SIG].

   5. When requesting multiple ODUk LSP (i.e. multiplier MT > 1), an
      explicit list of labels is returned to the requestor node. When
      the downstream node receives a request for a 4 x ODU1 signal
      (Signal Type = 1, RMT = 1, NMC = 1 and MT = 4), 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. Signalling Protocol Extensions



D.Papadimitriou et al. - Internet Draft û Expires May 2002          12

draft-fontana-ccamp-gmpls-g709-01.txt                    November 2001


   This section specifies the [GMPLS-RSVP] and [GMPLS-LDP] protocol
   extensions needed to accommodate G.709 traffic parameters.

6.1 RSVP-TE Details

   For RSVP-TE, the G.709 traffic parameters are carried in the G.709
   SENDER_TSPEC and FLOWSPEC objects.  The same format is used both
   for SENDER_TSPEC object and FLOWSPEC objects. The content of the
   objects is defined above in Section 3.2. The objects have the
   following class and type for G.709:
   - G.709 SENDER_TSPEC Object: Class = 12, C-Type = 4 (TBA)
   - G.709 FLOWSPEC Object: Class = 9, C-Type = 4 (TBA)

   There is no Adspec associated with the SONET/SDH SENDER_TSPEC.
   Either the Adspec is omitted or an Int-serv Adspec with the
   Default General Characterization Parameters and Guaranteed Service
   fragment is used, see [RFC2210].

   For a particular sender in a session the contents of the FLOWSPEC
   object received in a Resv message SHOULD be identical to the
   contents of the SENDER_TSPEC object received in the corresponding
   Path message. If the objects do not match, a ResvErr message with
   a "Traffic Control Error/Bad Flowspec value" error SHOULD be
   generated.

6.2 CR-LDP Details

   For CR-LDP, the G.709 traffic parameters are carried in the G.709
   Traffic Parameters TLV. The content of the TLV is defined in
   Section 3.2. The header of the TLV has the following format:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |U|F|          Type             |            Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The type field indicates G.709 OTN: 0xTBA

7. Security Considerations

   This document introduces no new security considerations to either
   [GMPLS-RSVP] or [GMPLS-LDP].

8. References

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

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

   3. [ITUT-G798] æCharacteristics of Optical Transport Network

D.Papadimitriou et al. - Internet Draft û Expires May 2002          13

draft-fontana-ccamp-gmpls-g709-01.txt                    November 2001


      Hierarchy Equipment Functional BlocksÆ, ITU-T draft version 0.9,
      October 2001.

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

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

   6. [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.

   7. [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.

   8. [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.

   9. [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.

   10. [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.

   11. [GMPLS-SSS-EXT] E.Mannie et al., æGeneralized MPLS û SDH/Sonet
       Specifics ExtensionsÆ, Internet Draft, Work in progress, draft-
       ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt, July 2001.

   12. [G709-FRM] A. Bellato, D.Papadimitriou et al., æG.709 Optical
       Transport Networks GMPLS Control FrameworkÆ, Internet Draft, Work
       in progress, draft-bellato-ccamp-g709-framework-01.txt, November
       2001.

   13. [RFC-2210] J. Wroclawski, æThe Use of RSVP with IETF Integrated
       ServicesÆ, Internet RFC 2210, IETF Standard Track, September
       1997.

9. Acknowledgments

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

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


D.Papadimitriou et al. - Internet Draft û Expires May 2002          14

draft-fontana-ccamp-gmpls-g709-01.txt                    November 2001


10. 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
   Phone: +1 858 646-7192
   Email: nghani@sorrentonet.com

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

   Dan Guo
   Turin Networks
   1415 N. McDowell Blvd
   Petaluma, CA 94954
   Phone: +1 707 665-4357
   Email: dguo@turinnetworks.com

   Juergen Heiles
   Siemens AG
   Hofmannstr. 51
   D-81379 Munich, Germany
   Phone: +49 89 7 22 - 4 86 64
   Email: Juergen.Heiles@icn.siemens.de

   Jim Jones
   Alcatel

D.Papadimitriou et al. - Internet Draft û Expires May 2002          15

draft-fontana-ccamp-gmpls-g709-01.txt                    November 2001


   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, New Jersey 07733-3030, USA
   Tel: +1 732 949-5141
   Email: zwlin@lucent.com

   Eric Mannie
   EBone (GTS)
   Terhulpsesteenweg, 6A
   1560 Hoeilaart, Belgium
   Phone: +32 2 658-5652
   Email: eric.mannie@ebone.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
   Email: siva@hotair.hobl.lucent.com

   Maarten Vissers
   Lucent
   Boterstraat 45
   Postbus 18
   1270 AA Huizen, Netherlands
   Email: mvissers@lucent.com

   Yangguang Xu
   Lucent
   21-2A41, 1600 Osgood Street
   North Andover, MA 01845, USA
   Email: xuyg@lucent.com

   Yong Xue
   WorldCom
   22001 Loudoun County Parkway
   Ashburn, VA 20147, USA
   Tel: +1 703 886-5358
   E-mail: yong.xue@wcom.com



D.Papadimitriou et al. - Internet Draft û Expires May 2002          16

draft-fontana-ccamp-gmpls-g709-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 et al. - Internet Draft û Expires May 2002          17

draft-fontana-ccamp-gmpls-g709-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.
















D.Papadimitriou et al. - Internet Draft û Expires May 2002          18

draft-fontana-ccamp-gmpls-g709-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 et al. - Internet Draft û Expires May 2002          19


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/