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

Versions: 00 01 02 03

CCAMP Working Group                 D. Papadimitriou (Alcatel) - Editor
Category: Internet Draft
Expiration Date: August 2002                 Alberto Bellato  (Alcatel)
                                         Sudheer Dharanikota    (Nayna)
                                             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)
                                         S. Sankaranarayanan   (Lucent)
                                             Maarten Vissers   (Lucent)
                                                Yangguang Xu   (Lucent)
                                                    Yong Xue (WorldCom)

                                                          February 2002


                      GMPLS Signalling Extensions
              for G.709 Optical Transport Networks Control

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

   (*) Current edition reproduces same set of co-authors as the
       previous version (this list might change based on the new
       publication rules: http://www.rfc-editor.org/policy.html)
       See also acknowledgements section.


D.Papadimitriou et al. - Internet Draft û Expires August 2002        1

draft-fontana-ccamp-gmpls-g709-03.txt                       February 2002



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

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 [ITUT-G709] technology specific information
   needed to extend GMPLS signalling to control Optical Transport
   Networks (OTN); it also includes the so-called pre-OTN
   developments.

DISCLAIMER

   In this document, the presented views on ITU-T G.709 OTN
   Recommendation (and referenced) are intentionally restricted as
   needed from the GMPLS perspective within the IETF CCAMP WG context.

   Hence, the objective of this document is not to replicate the
   content of the ITU-T OTN recommendations. Therefore, the reader
   interested in going into more details concerning the corresponding
   technologies is strongly invited to consult the corresponding ITU-
   T documents (also referenced in this memo).

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) Capable. A
   functional description of the extensions to MPLS signaling needed
   to support these 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] (and referenced documents),
   including pre-OTN developments. Per [GMPLS-SIG], G.709 specific
   parameters are carried through the signaling protocol in traffic
   parameter specific objects.

   Note: in the context of this memo, by pre-OTN developments, one
   refers to Optical Channel, Digital Wrapper and Forward Error
   Correction (FEC) solutions that are not G.709 compliant. Details
   concerning pre-OTN SONET/SDH based solutions including Optical
   Sections (OS), Regenerator Section(RS)/Section and Multiplex


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

draft-fontana-ccamp-gmpls-g709-03.txt                      February 2002


   Section(MS)/ Line overhead transparency are covered in [GMLS-SSS]
   and [GMPLS-SSS-EXT].


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
   (Optical Channel) and the ODUk (Optical Channel Data Unit) layers
   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 the 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.

   As described in [ITUT-G709], in addition to the support of ODUk
   mapping into OTUk (k = 1, 2, 3), [ITUT-G.709] supports ODUk
   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

   Therefore, adapting GMPLS to control G.709 OTN, can be achieved by
   considering that:
      - a Digital Path layer by extending the previously defined
        ôDigital Wrapperö in [GMPLS-SIG] corresponding to the ODUk
        (digital) path layer.
      - an Optical Path layer by extending the ôLambdaö concept defined
        in [GMPLS-SIG] to the OCh (optical) path layer.
      - a label space structure by considering a tree whose root is an
        OTUk signal and leaves the ODUj signals (k >= j); enabling to
        identify the exact position of a particular ODUj signal in an
        ODUk multiplexing structure.

   Thus, 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 also
   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


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

draft-fontana-ccamp-gmpls-g709-03.txt                      February 2002



   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             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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

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

draft-fontana-ccamp-gmpls-g709-03.txt                       February 2002


        -----           ----
         12             G.709 ODUk (Digital Path)
         13             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 (see [GMPLS-RTG]).

   Here, no additional values are to be considered in order to
   accommodate G.709 switching types since an ODUk switching (and so
   LSPs) belongs to the TDM class while an OCh switching (and so LSPs)
   to the Lambda class (i.e. LSC).

   Moreover, 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
   - ODUk: transport of Digital Path at 2.5, 10 and 40 Gbps

   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
   - OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps



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

draft-fontana-ccamp-gmpls-g709-03.txt                       February 2002


   When the client payloads such as Ethernet/MAC and IP/PPP are
   encapsulated through the Generic Framing Procedure (GFP) as
   described in ITU-T G.7041, we use dedicated G-PID values. Notice
   that additional G-PID values such as ESCON, FICON and Fiber Channel
   could complete this list in future releases.

   In order to include pre-OTN developments as defined above, 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):
   - Gigabit Ethernet: 1 Gbps and 10 Gbps
   - ESCON and FICON : left for further consideration
   - Fiber Channel   : left for further consideration

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

   Value        G-PID Type      LSP Encoding Type
   -----        ----------      -----------------
    44          G.709 ODUj      G.709 ODUk (with k > j)
    45          G.709 OTUk(v)   G.709 OCh  (ODUk mapped into OTUk(v))
    46          CBR/CBRa        G.709 ODUk, G.709 OCh
    47          CBRb            G.709 ODUk
    48          BSOT            G.709 ODUk
    49          BSNT            G.709 ODUk
    50          IP/PPP (GFP)    G.709 ODUk
    51          Ethernet (GFP)  G.709 ODUk

   Note: Value 46 and 47 includes mapping of SDH/Sonet

   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 OCh, Lambda, Fiber
    34          SDH             G.709 OCh, Lambda, Fiber
    35          SONET           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
   is carried additionally to the one included in the Generalized Label
   Request and 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  |   Reserved    |              NMC              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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

draft-ietf-ccamp-gmpls-g709-00.txt                       February 2002


     |              NVC              |          Multiplier           |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In this frame, NMC stands for Number of Multiplexed Components and
   NVC for Number of Virtual 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 at 2.5 Gbps
        7       OCh at 10 Gbps
        8       OCh at 40 Gbps
        9-255   Reserved for future use

   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 at 2.5, 10 or 40 Gbps
    - 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.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. This field is not applicable when an ODUk is mapped
   into an OTUk and irrelevant at the Optical Channel layer. In both
   cases, it MUST be set to zero (NMC = 0) when sent and should be
   ignored when received.

   When applied at the Digital Path layer, in particular for ODU2
   connections multiplexed into one 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

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

draft-fontana-ccamp-gmpls-g709-03.txt                     February 2002


   other currently defined multiplexing cases (see Section 2), the NMC
   field is set to 1.

3.2.4 Number of Virtual Components (NVC)

   The NVC field (16 bits) is dedicated to ODUk virtual concatenation
   (i.e. ODUk Inverse Multiplexing) 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. By definition,
   these signals MUST be of the same type.

   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 (MT)

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

3.2.6 Reserved Fields

   The reserved fields (8 bits and 32 bits) are 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).




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

draft-fontana-ccamp-gmpls-g709-03.txt                      February 2002


   In addition to the support of ODUk mapping into OTUk, the G.709
   label space supports the sub-levels of 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                |     t3    | t2  |t1|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The specification of the three fields t1, t2 and t3 self-
   consistently characterizes the ODUk label space. The value space of
   the t1, t2 and t3 fields is defined as follows:

   1. t1 (1-bit):
        - t1=1 indicates an ODU1 signal.
        - t1 is not significant for the other ODUk signal types (t1=0).

   2. t2 (3-bit):
        - t2=1 indicates a not further sub-divided ODU2 signal.
        - t2=2->5 indicates the tributary slot (t2th-2) used by the
          ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2).
        - t2 is not significant for an ODU3 (t2=0).

   3. t3 (6-bit):
        - t3=1 indicates a not further sub-divided ODU3 signal.
        - t3=2->17 indicates the tributary slot (t3th-1) used by the
          ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3).
        - t3=18->33 indicates the tributary slot (t3th-17) used by the
          ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3).




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

draft-fontana-ccamp-gmpls-g709-03.txt                       February 2002


   Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required
   to identify the 4 tributary slots used by the ODU2; these tributary
   time slots have to be allocated in ascending order.

   If the label sub-field value t[i]=1 (i, j = 1, 2 or 3) and t[j]=0 (j
   > i), the corresponding ODUk signal ODU[i] is directly mapped into
   the corresponding OTUk signal (k=i). We refer to this as the mapping
   of an ODUk signal into an OTUk of the same order. 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:
   - t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1
   - t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2
   - t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3
   - t3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot
     of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2
   - t3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot
     of the 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
   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
   multiplexed virtually concatenated signals, the first set of labels
   indicates the components (ODUj tributary slots) of the first
   virtually concatenated signal, the second set of labels indicates
   the components (ODUj tributary slots) of the second virtually
   concatenated signal, and so on.

   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. The above representation limits multiplication to
   remain within a single (component) link. In case of multiplication
   of multiplexed/virtually concatenated signals, the first set of
   labels indicates the components of the first multiplexed/virtually
   concatenated signal, the second set of labels indicates components
   of the second multiplexed/virtually concatenated signal, and so on.


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

draft-fontana-ccamp-gmpls-g709-03.txt                      February 2002


   Note: As defined in [GMPLS-SIG], label field values only have
   significance between two neighbors, and the receiver may need (in
   some particular cases) to convert the received value into a value
   that has local significance.

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

   The following examples are given in order to illustrate the
   processing described in the previous sections of this document.

   1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is
      directly transported in an OTU1 (OTU2 or OTU3), the upstream node
      requests results simply in an 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 signal is
      requested (Signal Type = 1, 2 or 3), the downstream node has to
      return a single ODUk label which can be for instance one of the
      following when the Signal Type = 1:

      - t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1
      - t3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2
      - t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3

   2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed
      into the payload of a structured ODU2 (or ODU3), the upstream
      node requests results simply in a ODU1 signal request.

      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

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

draft-fontana-ccamp-gmpls-g709-03.txt                      February 2002


      = 1 and NMC = 1), the downstream node has to return a single ODU1
      label which can take for instance one of the following values:

      - t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2
      - t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3
      - t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3

   3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is
      multiplexed into the payload of a structured ODU3, the upstream
      node requests results simply in a ODU2 signal request.

      In such conditions, the downstream node has to return four labels
      since the ODU2 is multiplexed into one ODTUG3. The latter is
      mapped into an ODU3 (via OPU3) and then mapped into an OTU3.
      Since an ODU2 multiplexed signal is requested (Signal Type = 2,
      and NMC = 4), the downstream node has to return four ODU labels
      which can take for instance the following values:

      - t3=18, t2=0, t1=0 (first  part of ODU2 in first TS of ODTUG3)
      - t3=22, t2=0, t1=0 (second part of ODU2 in fifth TS of ODTUG3)
      - t3=23, t2=0, t1=0 (third  part of ODU2 in sixth TS of ODTUG3)
      - t3=26, t2=0, t1=0 (fourth part of ODU2 in ninth TS of ODTUG3)

   4. When a single OCh signal of 40 Gbps is requested (Signal Type =
      8), the downstream node must return a single wavelength
      label as specified in [GMPLS-SIG].

   5. When requesting multiple ODUk LSP (i.e. with a multiplier (MT)
      value > 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, NMC = 1 and MT = 4) multiplexed into a ODU3, 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: t3=2,  t2=0, t1=0 (in first TS of ODTUG3)
      - Second ODU1: t3=10, t2=0, t1=0 (in ninth TS of ODTUG3)
      - Third  ODU1: t3=7,  t2=0, t1=0 (in sixth TS of ODTUG3)
      - Fourth ODU1: t3=6,  t2=0, t1=0 (in fifth TS of ODTUG3)

6. Signalling Protocol Extensions

   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

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

draft-fontana-ccamp-gmpls-g709-03.txt                      February 2002


   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

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

   [ITUT-G709]  ITU-T G.709 version 1.0 (+ addendum), æInterface for
                the Optical Transport Network (OTN)Æ, ITU-T, October
                2001.

   [ITUT-G798]  ITU-T G.798 version 1.0, æCharacteristics of Optical
                Transport Network Hierarchy Equipment Functional
                BlocksÆ, ITU-T, October 2001.




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

draft-fontana-ccamp-gmpls-g709-03.txt                      February 2002


   [ITUT-G872]  ITU-T G.872 Recommendation version 1.0, revision 6,
                æArchitecture of Optical Transport NetworkÆ, ITU-T,
                August 2001.

   [ITUT-GASTN] ITU-T G.807 Recommendation version 1.0, æAutomated
                Switched Transport NetworkÆ, ITU-T, February 2001.

   [GMPLS-ARCH] E.Mannie (Editor) et al., æGeneralized Multi-Protocol
                Label Switching (GMPLS) ArchitectureÆ, Internet Draft,
                Work in progress, draft-ietf-ccamp-gmpls-architecture-
                01.txt, November 2001.

   [GMPLS-LDP]  L.Berger (Editor) et al., æGeneralized MPLS Signaling -
                CR-LDP ExtensionsÆ, Internet Draft, Work in progress,
                draft-ietf-mpls-generalized-cr-ldp-05.txt, November
                2001.

   [GMPLS-RSVP] L.Berger (Editor) et al., æGeneralized MPLS Signaling -
                RSVP-TE ExtensionsÆ, Internet Draft, Work in progress,
                draft-ietf-mpls-generalized-rsvp-te-06.txt, November
                2001.

   [GMPLS-RTG]  K. Kompella et al., ôRouting Extensions in Support of
                Generalized MPLS,ö Internet Draft, Work in Progress,
                draft-kompella-ccamp-gmpls-routing-02.txt, February
                2002.

   [GMPLS-SIG]  L.Berger (Editor) et al., æGeneralized MPLS
                - Signaling Functional DescriptionÆ, Internet Draft,
                Work in progress, draft-ietf-mpls-generalized-
                signaling-07.txt, October 2001.

   [GMPLS-SSS]  E.Mannie (Editor) et al., æGeneralized MPLS û SDH/Sonet
                SpecificsÆ, Internet Draft, Work in progress, draft-
                ietf-ccamp-gmpls-sonet-sdh-02.txt, October 2001.

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

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

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

9. Acknowledgments



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

draft-fontana-ccamp-gmpls-g709-03.txt                      February 2002


   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 (upon agreement) material and ideas from
   draft-lin-ccamp-ipo-common-label-request-00.txt resulting in the
   inclusion of its authors into the present document.

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, USA
   Phone: +1 707 665-4357
   Email: dguo@turinnetworks.com

   Juergen Heiles

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

draft-fontana-ccamp-gmpls-g709-03.txt                      February 2002


   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
   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, USA
   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


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

draft-fontana-ccamp-gmpls-g709-03.txt                       February 2002


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
















































D.Papadimitriou et al. - Internet Draft û Expires August 2002       17

draft-ietf-ccamp-gmpls-g709-00.txt                       February 2002


Appendix 1 û Abbreviations

   BSNT         Bit Stream without Octet Timing
   BSOT         Bit Stream with Octet Timing
   CBR          Constant Bit Rate
   ESCON        Enterprise Systems Connection
   FC           Fiber Channel
   FEC          Forward Error Correction
   FICON        Fiber Connector
   FSC          Fiber Switch Capable
   GFP          Generic Framing Procedure
   LSC          Lambda Switch Capable
   LSP          Label Switched Path
   MS           Multiplex Section
   naOH         non-associated Overhead
   NMC          Number of Multiplexed Components
   NNI          Network-to-Network interface
   NVC          Number of Virtual Components
   OCC          Optical Channel Carrier
   OCG          Optical Carrier Group
   OCh          Optical Channel (with full functionality)
   OChr         Optical Channel (with reduced functionality)
   ODTUG        Optical Date Tributary Unit Group
   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
   OTUkV        Functionally Standardized OTUk
   PPP          Point to Point Protocol
   PSC          Packet Switch Capable
   RES          Reserved
   RS           Regenerator Section
   TDM          Time Division Multiplex
   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

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

draft-ietf-ccamp-gmpls-g709-00.txt                       February 2002


    . 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 August 2002       19

draft-ietf-ccamp-gmpls-g709-00.txt                       February 2002


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 August 2002       20


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