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

Versions: (draft-fontana-ccamp-gmpls-g709) 00 01 02 03 04 05 06 07 08 09 RFC 4328

CCAMP Working Group                           D. Papadimitriou - Editor
Internet Draft                                                (Alcatel)
Category: Standard Track

Expiration Date: June 2004                                 January 2004



                 Generalized MPLS Signalling Extensions
              for G.709 Optical Transport Networks Control

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

Abstract

   This document is a companion to the Generalized MPLS (GMPLS)
   signalling documents. It describes the 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).

D.Papadimitriou (Editor) et al. - Expires June 2004                  1

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


Table of Content

   Status of this Memo ............................................. 1
   Abstract ........................................................ 1
   Table of Content ................................................ 2
   1. Introduction ................................................. 2
   2. GMPLS Extensions for G.709 - Overview ........................ 3
   3. Generalized Label Request .................................... 4
   3.1 Technology Independent Part ................................. 4
   3.1.1. LSP Encoding Type ........................................ 5
   3.1.2. Switching-Type ........................................... 5
   3.1.3. Generalized-PID (G-PID) .................................. 6
   3.2. G.709 Traffic-Parameters ................................... 7
   3.2.1. Signal Type (ST).......................................... 7
   3.2.2. Number of Multiplexed Components (NMC) ................... 8
   3.2.3. Number of Virtual Components (NVC) ....................... 9
   3.2.4. Multiplier (MT) .......................................... 9
   3.2.5. Reserved Fields .......................................... 9
   4. Generalized Label ............................................ 9
   4.1. ODUk Label Space .......................................... 10
   4.2. Label Distribution Rules .................................. 11
   4.3. OCh Label Space ........................................... 12
   5. Examples .................................................... 12
   6. Signalling Protocol Extensions .............................. 13
   6.1. RSVP-TE Details ........................................... 13
   6.2. CR-LDP Details ............................................ 14
   7. Security Considerations ..................................... 15
   8. IANA Considerations ......................................... 15
   9. Acknowledgments ............................................. 15
   10. Intellectual Property Notice ............................... 16
   11. References ................................................. 16
   11.1 Normative References ...................................... 16
   12. Contributors ............................................... 17
   13. Author's Address ........................................... 18
   Appendix 1 - Abbreviations ..................................... 19
   Appendix 2 - G.709 Indexes ..................................... 19
   Full Copyright Statement ....................................... 21

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.

   In addition, the reader is assumed to be familiar with the
   terminology used in ITU-T [ITUT-G709] as well as [RFC3471],
   [RFC3473] and [RFC3472]. Abbreviations used in this document are
   detailed in Appendix 1.






D.Papadimitriou (Editor) et al. - Expires June 2004                  2

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


1. Introduction

   Generalized MPLS (GMPLS) 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 [RFC3471]. [RFC3473] describes RSVP-TE
   specific formats and mechanisms needed to support all four classes
   of interfaces, and CR-LDP extensions can be found in [RFC3472].

   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 [RFC3471], G.709 technology
   specific parameters are carried through the signaling protocol in
   dedicated traffic parameter objects.

   The G.709 traffic parameters defined hereafter (see Section 3.2)
   MUST be used when the label is encoded as defined in this
   document. Moreover, the label MUST be encoded as defined in
   Section 4 when these G.709 traffic parameters are used.

   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 fully G.709 compliant.
   Details concerning pre-OTN Synchronous Optical Network (SONET)/
   Synchronous Digital Hierarchy (SDH) based solutions including
   Optical Sections (OS), Regenerator Section (RS)/Section and
   Multiplex Section (MS)/ Line overhead transparency are covered in
   [GMPLS-SONET-SDH].

2. GMPLS Extensions for G.709 - Overview

   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


D.Papadimitriou (Editor) et al. - Expires June 2004                  3

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


   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, the GMPLS signalling extensions for G.709 need to cover the
   Generalized Label Request, the Generalized Label as well as the
   specific technology dependent objects included in the so-called
   traffic parameters as specified in [GMPLS-SONET-SDH] for SONET/SDH
   networks. Moreover, since the multiplexing in the digital domain
   (such as ODUk multiplexing) has been specified in the amended
   version of the G.709 ITU-T recommendation (October 2001), this
   document also proposes a label space definition suitable for that
   purpose. Notice also that one directly uses the G.709 ODUk (i.e.
   Digital Path) and OCh (i.e. Optical Path) layers in order to define
   the corresponding label spaces.

3. Generalized Label Request

   The Generalized Label Request as defined in [RFC3471], includes a
   technology independent part and a technology dependent part (i.e.
   the traffic parameters). In this section, both parts are extended to
   accommodate the GMPLS Signalling to the G.709 transport plane
   recommendation (see [ITUT-G709]).

3.1 Technology Independent Part

   As defined in [RFC3471], the LSP Encoding Type, the Switching Type
   and the Generalized Protocol Identifier (Generalized-PID) constitute
   the technology independent part of the Generalized Label Request.
   The encoding of the corresponding RSVP-TE object and CR-LDP TLV is
   specified in [RFC3473] Section 2.1 and [RFC3472] Section 2.1,
   respectively.

   As mentioned here above, this document extends the LSP Encoding
   Type, Switching Type and G-PID (Generalized-PID) values to
   accommodate G.709 recommendation [ITUT-G709].




D.Papadimitriou (Editor) et al. - Expires June 2004                  4

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


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 [RFC3471] 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
   [RFC3471] 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, the following additional code-points for the LSP
   Encoding Type are defined:

        Value           Type
        -----           ----
         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, when a downstream node
   receives a Generalized Label Request including one of these values
   for the Switching Type field, this value SHOULD be ignored.



D.Papadimitriou (Editor) et al. - Expires June 2004                  5

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


3.1.3 Generalized-PID (G-PID)

   The G-PID (16 bits field) as defined in [RFC3471], 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 defined in [RFC3471]:

   - 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 Paths at 2.5, 10 and 40 Gbps
   - ESCON: Enterprise Systems Connection
   - FICON: Fiber Connection

   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 defined in [RFC3471]:

   - 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

   Also, when client payloads such as Ethernet MAC/PHY and IP/PPP are
   encapsulated through the Generic Framing Procedure (GFP) as
   described in ITU-T G.7041, dedicated G-PID values are defined.

   In order to include pre-OTN developments, the G-PID field can take
   one of the values (currently defined in [RFC3471]) when the
   following client payloads are transported over a so-called lambda
   LSP:

   - Ethernet PHY (1 Gbps and 10 Gbps)
   - Fiber Channel

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

   Value     G-PID Type                       LSP Encoding Type
   -----     ----------                       -----------------
    47       G.709 ODUj                       G.709 ODUk (with k > j)
    48       G.709 OTUk(v)                    G.709 OCh
                                              ODUk mapped into OTUk(v)
    49       CBR/CBRa                         G.709 ODUk, G.709 OCh
    50       CBRb                             G.709 ODUk

D.Papadimitriou (Editor) et al. - Expires June 2004                  6

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


    51       BSOT                             G.709 ODUk
    52       BSNT                             G.709 ODUk
    53       IP/PPP (GFP)                     G.709 ODUk (and SDH)
    54       Ethernet MAC (framed GFP)        G.709 ODUk (and SDH)
    55       Ethernet PHY (transparent GFP)   G.709 ODUk (and SDH)
    56       ESCON                            G.709 ODUk, Lambda, Fiber
    57       FICON                            G.709 ODUk, Lambda, Fiber
    58       Fiber Channel                    G.709 ODUk, Lambda, Fiber

   Note: Value 49 and 50 includes mapping of SDH

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

   Value     G-PID Type                 LSP Encoding Type
   -----     ----------                 -----------------
    32       ATM Mapping                SDH, G.709 ODUk
    33       Ethernet PHY               SDH, G.709 OCh, Lambda, Fiber
    34       Sonet/SDH                  G.709 OCh, Lambda, Fiber
    35       Reserved (SONET Dep.)      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              |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |              NVC              |        Multiplier (MT)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                           Reserved                            |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   In this frame, NMC stands for Number of Multiplexed Components, NVC
   for Number of Virtual Components and MT for Multiplier. Each of
   these fields is tailored to support G.709 LSP requests.

3.2.1 Signal Type (ST)

   This field (8 bits) indicates the type of G.709 Elementary Signal
   that comprises the requested LSP. The permitted values are:

      Value     Type
      -----     ----
        0       Irrelevant
        1       ODU1 (i.e. 2.5 Gbps)
        2       ODU2 (i.e. 10  Gbps)

D.Papadimitriou (Editor) et al. - Expires June 2004                  7

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


        3       ODU3 (i.e. 40  Gbps)
        4       Reserved
        5       Reserved
        6       OCh at 2.5 Gbps
        7       OCh at 10 Gbps
        8       OCh at 40 Gbps
        9-255   Reserved

   The value of the Signal Type field depends on LSP Encoding Type
   value defined in Section 3.1.1 and [RFC3471]:
    - 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)

   Several transforms can be sequentially applied on the Elementary
   Signal to build the Final Signal being actually requested for the
   LSP. Each transform application is optional and must be ignored if
   zero, except the Multiplier (MT) that cannot be zero and must be
   ignored if equal to one. Transforms must be applied strictly in the
   following order:
   - First, virtual concatenation (by using the NVC field) can
     be optionally applied directly on the Elementary Signal to form a
     Composed Signal
   - Second, a multiplication (by using the Multiplier field) can be
     optionally applied either directly on the Elementary Signal, or
     on the virtually concatenated signal obtained from the first
     phase. The resulting signal is referred to as Final Signal.

3.2.2 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
   other currently defined multiplexing cases (see Section 2), the NMC
   field is set to 1.




D.Papadimitriou (Editor) et al. - Expires June 2004                  8

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


3.2.3 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 that the current usage of this field only applies for G.709
   ODUk LSP i.e. values greater than zero, are only acceptable for ODUk
   Signal Types. Therefore, it MUST be set to zero (NVC = 0) when
   requesting a G.709 OCh LSP and should be ignored when received.

3.2.4 Multiplier (MT)

   The Multiplier field (16 bits) indicates the number of identical
   Elementary Signals or Composed Signals requested for the LSP i.e.
   that form the Final Signal. A Composed Signal is the resulting
   signal from the application of the NMC and NVC fields to an
   elementary Signal Type. GMPLS signalling currently implies that all
   the Composed Signals must be part of the same LSP.

   This field is set to one (default value) to indicate that exactly
   one instance of a signal is being requested. Intermediate and egress
   nodes MUST verify that the node itself and the interfaces on which
   the LSP will be established can support the requested multiplier
   value. If the requested values can not be supported, the receiver
   node MUST generate a PathErr/NOTIFICATION message (see Section
   6.1/6.2, respectively).

   Zero is an invalid value. If received, the node MUST generate a
   PathErr/NOTIFICATION message (see Section 6.1/6.2, respectively).

3.2.5 Reserved Fields

   The reserved fields (8 bits in row 1 and 32 bits fields in row 3)
   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 value space for Digital
   Paths and Optical Channels. The Generalized Label is defined in
   [RFC3471]. The format of the corresponding RSVP-TE object and CR-LDP
   TLV is specified in [RFC3473] Section 2.2 and [RFC3472] Section 2.2,
   respectively.

   The label distribution rules detailed in Section 4.2 follow (when
   applicable) the ones defined in [GMPLS-SONET-SDH].


D.Papadimitriou (Editor) et al. - Expires June 2004                  9

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


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

   Reserved bits MUST be set to zero when sent and SHOULD be ignored
   when received.

   The specification of the fields t1, t2 and t3 self-consistently
   characterizes the ODUk label space. The value space for 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).

D.Papadimitriou (Editor) et al. - Expires June 2004                 10

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


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

   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). This is referred to 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
   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.

D.Papadimitriou (Editor) et al. - Expires June 2004                 11

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004



   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.

   Note: as defined in [RFC3471], 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). Note that these identifiers do not cover OChr since
   the corresponding Connection Function (OChr-CF) between OTM-
   nr.m/OTM-0r.m is not defined in [ITUT-G798].

   The OCh label space values are defined by either absolute values
   (i.e. channel identifiers or 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 (per node) label space. Such an OCh label
   space is applicable to both OTN Optical Channel layer and pre-OTN
   Optical Channel layer.

   Optical Channel label encoding (and distribution) rules are defined
   in [RFC3471]. They MUST be used for the Upstream Label, the
   Suggested Label and the Generalized Label.

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:


D.Papadimitriou (Editor) et al. - Expires June 2004                 12

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


      - 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
      = 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 [RFC3471].

   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)

D.Papadimitriou (Editor) et al. - Expires June 2004                 13

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


      - 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 [RFC3473] and [RFC3472] 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 = TBA
   - G.709 FLOWSPEC Object: Class = 9, C-Type = 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.

   Intermediate and egress nodes MUST verify that the node itself and
   the interfaces on which the LSP will be established can support
   the requested Signal Type, NMC and NVC values (as defined in
   Section 3.2). If the requested value(s) can not be supported, the
   receiver node MUST generate a PathErr message with a "Traffic
   Control Error/Service unsupported" indication (see [RFC2205]).

   In addition, if the MT field is received with a zero value, the
   node MUST generate a PathErr message with a "Traffic Control
   Error/Bad Tspec value" indication (see [RFC2205]).

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

D.Papadimitriou (Editor) et al. - Expires June 2004                 14

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004



   The type field indicates G.709 traffic parameters: 0xTBA

   Intermediate and egress nodes MUST verify that the node itself and
   the interfaces on which the LSP will be established can support
   the requested Signal Type, NMC and NVC values (as defined in
   Section 3.2). If the requested value(s) can not be supported, the
   receiver node MUST generate a NOTIFICATION message with a
   "Resource Unavailable" status code (see [RFC3212]).

   In addition, if the MT field is received with a zero value, the
   node MUST generate a NOTIFICATION message with a "Resource
   Unavailable" status code (see [RFC3212]).

7. Security Considerations

   This draft introduces no new security considerations to either
   [RFC3473] or [RFC3472]. GMPLS security is described in section 11
   of [RFC3471] and refers to [RFC3209] for RSVP-TE and to [RFC3212]
   for CR-LDP.

8. IANA Considerations

   Three values have to be defined by IANA for this document:

   Two RSVP C-Types in registry:

             http://www.iana.org/assignments/rsvp-parameters

             - A G.709 SENDER_TSPEC object: Class = 12, C-Type = TBA
               (see section 6.1).

             - A G.709 FLOWSPEC object: Class = 9, C-Type = TBA (see
               section 6.1).

   One LDP TLV Type in registry:

             http://www.iana.org/assignments/ldp-namespaces

             - A Type field value for the G.709 Traffic Parameters
               TLV (see section 6.2).

9. Acknowledgments

   The authors would like to thank Jean-Loup Ferrant, Mathieu Garnot,
   Massimo Canali, Germano Gasparini and Fong Liaw for their
   constructive comments and inputs as well as James Fu, Siva
   Sankaranarayanan and Yangguang Xu for their useful feedback.

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



D.Papadimitriou (Editor) et al. - Expires June 2004                 15

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


10. Intellectual Property Notice

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights. Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11. Copies of
   claims of rights made available for publication and any assurances
   of licenses to be made available, or the result of an attempt made
   to obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification
   can be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard. Please address the information to the IETF Executive
   Director.

11. References

11.1 Normative References

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

   [ITUT-G709]  ITU-T, "Interface for the Optical Transport Network
                (OTN)," G.709 Recommendation (and Amendment 1),
                February 2001 (October 2001).

   [ITUT-G798]  ITU-T, "Characteristics of Optical Transport Network
                Hierarchy Equipment Functional Blocks," G.798
                Recommendation, October 2001.

   [ITUT-G872]  ITU-T, version 2.0, "Architecture of Optical Transport
                Network," G.872 Recommendation, October 2001.

   [GMPLS-ARCH] Mannie, E. (Editor) et al., "Generalized Multi-Protocol
                Label Switching (GMPLS) Architecture," Internet Draft
                (work in progress), draft-ietf-ccamp-gmpls-
                architecture-07.txt, May 2003.

   [GMPLS-RTG]  Kompella, K. (Editor) et al., "Routing Extensions in
                Support of Generalized MPLS," Internet Draft (work in
                progress), draft-ietf-ccamp-gmpls-routing-09.txt,
                October 2003.

   [GMPLS-SONET-SDH] Mannie, E. and Papadimitriou, D. (Editors) et al.,
                "Generalized Multiprotocol Label Switching Extensions

D.Papadimitriou (Editor) et al. - Expires June 2004                 16

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


                for SONET and SDH Control," Internet Draft (work in
                progress), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt,
                February 2003.

   [RFC2119]    Bradner, S., "Key words for use in RFCs to Indicate
                Requirement Levels," BCP 14, RFC 2119, March 1997.

   [RFC2205]    Braden, R., et al., "Resource ReSerVation Protocol
                (RSVP) -- Version 1 Functional Specification," RFC
                2205, September 1997.

   [RFC2210]    Wroclawski, J., "The Use of RSVP with IETF Integrated
                Services," RFC 2210, September 1997

   [RFC3036]    Andersson, L. et al., "LDP Specification," RFC 3036,
                January 2001.

   [RFC3209]    Awduche, D. et al., "RSVP-TE: Extensions to RSVP for
                LSP Tunnels," RFC 3209, December 2001.

   [RFC3212]    Jamoussi, B. (Editor) et al., "Constraint-Based LSP
                Setup using LDP," RFC 3212, January 2002.

   [RFC3471]    Berger, L. (Editor) et al., "Generalized Multi-
                Protocol Label Switching (GMPLS) Signaling -
                Functional Description," RFC 3471, January 2003.

   [RFC3472]    Berger, L. (Editor) et al., "Generalized Multi-
                Protocol Label Switching (GMPLS) Signaling -
                Constraint-based Routed Label Distribution Protocol
                (CR-LDP) Extensions," RFC 3472, January 2003.

   [RFC3473]    Berger, L. (Editor) et al., "Generalized Multi-
                Protocol Label Switching (GMPLS) Signaling Resource
                ReserVation Protocol-Traffic Engineering (RSVP-TE)
                Extensions," RFC 3473, January 2003.

12. Contributors

   Alberto Bellato (Alcatel)
   Via Trento 30,
   I-20059 Vimercate, Italy
   Email: alberto.bellato@alcatel.it

   Sudheer Dharanikota (Consult)
   Email: sudheer@ieee.org

   Michele Fontana (Alcatel)
   Via Trento 30,
   I-20059 Vimercate, Italy
   Email: michele.fontana@alcatel.it

   Nasir Ghani (Sorrento Networks)

D.Papadimitriou (Editor) et al. - Expires June 2004                 17

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


   9990 Mesa Rim Road,
   San Diego, CA 92121, USA
   Email: nghani@sorrentonet.com

   Gert Grammel (Alcatel)
   Lorenzstrasse, 10,
   70435 Stuttgart, Germany
   Email: gert.grammel@alcatel.de

   Dan Guo (Turin Networks)
   1415 N. McDowell Blvd,
   Petaluma, CA 94954, USA
   Email: dguo@turinnetworks.com

   Juergen Heiles (Siemens)
   Hofmannstr. 51,
   D-81379 Munich, Germany
   Email: juergen.heiles@siemens.com

   Jim Jones (Alcatel)
   3400 W. Plano Parkway,
   Plano, TX 75075, USA
   Email: jim.d.jones@alcatel.com

   Zhi-Wei Lin (Lucent)
   101 Crawfords Corner Rd, Rm 3C-512
   Holmdel, New Jersey 07733-3030, USA
   Email: zwlin@lucent.com

   Eric Mannie (Consult)
   Email: eric_mannie@hotmail.com

   Maarten Vissers (Alcatel)
   Lorenzstrasse, 10,
   70435 Stuttgart, Germany
   Email: maarten.vissers@alcalel.de

   Yong Xue (WorldCom)
   22001 Loudoun County Parkway,
   Ashburn, VA 20147, USA
   Email: yong.xue@wcom.com

13. Author's Address

   Dimitri Papadimitriou (Alcatel)
   Francis Wellesplein 1,
   B-2018 Antwerpen, Belgium
   Phone: +32 3 240-8491
   Email: dimitri.papadimitriou@alcatel.be





D.Papadimitriou (Editor) et al. - Expires June 2004                 18

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


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 Connection
   FSC          Fiber Switch Capable
   GCC          General Communication Channel
   GFP          Generic Framing Procedure
   LSC          Lambda Switch Capable
   LSP          Label Switched Path
   MS           Multiplex Section
   naOH         non-associated Overhead
   NMC          Number of Multiplexed Components
   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
   TTI          Trail Trace Identifier
   TDM          Time Division Multiplex

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 (Editor) et al. - Expires June 2004                 19

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


    . 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 (Editor) et al. - Expires June 2004                 20

draft-ietf-ccamp-gmpls-g709-05.txt                        January 2004


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 (Editor) et al. - Expires June 2004                 21


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