path: root/doc/rfc/rfc4328.txt

Network Working Group                              D. Papadimitriou, Ed.
Request for Comments: 4328                                       Alcatel
Updates: 3471                                               January 2006
Category: Standards Track


           Generalized Multi-Protocol Label Switching (GMPLS)
   Signaling Extensions for G.709 Optical Transport Networks Control

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).

Abstract

   This document is a companion to the Generalized Multi-Protocol Label
   Switching (GMPLS) signaling documents.  It describes the technology-
   specific information needed to extend GMPLS signaling to control
   Optical Transport Networks (OTN); it also includes the so-called
   pre-OTN developments.

Table of Contents

   1. Introduction ....................................................2
      1.1. Conventions Used in This Document ..........................3
   2. GMPLS Extensions for G.709 - Overview ...........................3
   3. Generalized Label Request .......................................4
      3.1. Common Part ................................................5
           3.1.1. LSP Encoding Type ...................................5
           3.1.2. Switching Type ......................................6
           3.1.3. Generalized-PID (G-PID) .............................6
      3.2. G.709 Traffic Parameters ...................................8
           3.2.1. Signal Type (ST) ....................................8
           3.2.2. Number of Multiplexed Components (NMC) ..............9
           3.2.3. Number of Virtual Components (NVC) .................10
           3.2.4. Multiplier (MT) ....................................10
           3.2.5. Reserved Fields ....................................10
   4. Generalized Label ..............................................10
      4.1. ODUk Label Space ..........................................11
      4.2. Label Distribution Rules ..................................13



Papadimitriou               Standards Track                     [Page 1]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


      4.3. Optical Channel Label Space ...............................14
   5. Examples .......................................................14
   6. RSVP-TE Signaling Protocol Extensions ..........................16
   7. Security Considerations ........................................16
   8. IANA Considerations ............................................16
   9. Acknowledgements ...............................................18
   10. References ....................................................18
      10.1. Normative References .....................................18
      10.2. Informative References ...................................19
   11. Contributors ..................................................19
   Appendix A. Abbreviations .........................................21
   Appendix B. G.709 Indexes .........................................22

1.  Introduction

   Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends
   MPLS from supporting Packet Switching Capable (PSC) interfaces and
   switching to include support of four new classes of interfaces and
   switching: Layer-2 Switching (L2SC), Time-Division Multiplex (TDM),
   Lambda Switch (LSC), and Fiber-Switch (FSC) Capable.  A functional
   description of the extensions to MPLS signaling that are needed to
   support these new classes of interfaces and switching is provided in
   [RFC3471].  [RFC3473] describes the RSVP-TE-specific formats and
   mechanisms needed to support all four classes of interfaces.

   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.

   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 Section/Regenerator Section
   overhead (SOH/RSOH) and Line/Multiplex Section overhead (LOH/MSOH)
   transparency are covered in [RFC3946].







Papadimitriou               Standards Track                     [Page 2]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


   *** Note on ITU-T G.709 Recommendation ***

   The views on the ITU-T G.709 OTN Recommendation presented in this
   document are intentionally restricted to 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, readers interested in more details concerning the
   corresponding technologies are strongly invited to consult the
   corresponding ITU-T documents (also referenced in this memo).

1.1.  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 [RFC2119].

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

2.  GMPLS Extensions for G.709 - Overview

   [ITUT-G709] defines several networking layers constituting the
   optical transport hierarchy:

   - with full functionality:
     . Optical Transmission Section (OTS)
     . Optical Multiplex Section (OMS)
     . Optical Channel (OCh)
   - with reduced functionality:
     . Optical Physical Section (OPS)
     . Optical Channel with reduced functionality (OChr)

   It also defines two layers constituting the digital transport
   hierarchy:

   - Optical Channel Transport Unit (OTUk)
   - Optical Channel Data Unit (ODUk)

   However, only the OCh and the ODUk 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 (also referred to as the non-associated
   overhead naOH) in the Optical Transport Module (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



Papadimitriou               Standards Track                     [Page 3]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


   naOH is only functionally specified and as such, it is 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), 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

   Adapting GMPLS to control G.709 OTN can be achieved by creating:

     - a Digital Path layer, by extending the previously defined
       "Digital Wrapper" in [RFC3471] corresponding to the ODUk
       (digital) path layer.
     - an Optical Path layer, by extending the "Lambda" concept (defined
       in [RFC3471]) 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 the
       identification of the exact position of a particular ODUj signal
       in an ODUk multiplexing structure.

   Thus, the GMPLS signaling 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 [RFC3946] for SONET/SDH networks.
   Moreover, because 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 uses the G.709 ODUk (i.e., Digital Path) and OCh (i.e., Optical
   Path) layers directly in order to define the corresponding label
   spaces.

3.  Generalized Label Request

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






Papadimitriou               Standards Track                     [Page 4]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


3.1.  Common Part

   As defined in [RFC3471], the LSP Encoding Type, the Switching Type
   and the Generalized Protocol Identifier (Generalized-PID) constitute
   the common part of the Generalized Label Request.  The encoding of
   the RSVP-TE GENERALIZED_LABEL_REQUEST object is specified in
   [RFC3473] Section 2.1.

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

3.1.1.  LSP Encoding Type

   Because G.709 Recommendation defines two networking layers (ODUk
   layers and OCh layer), the LSP Encoding Type code-points can reflect
   these two layers defined in [RFC3471] Section 3.1 as "Digital
   Wrapper" and "Lambda" code.  The LSP Encoding Type is specified per
   networking layer or, more precisely, per group of functional
   networking layers: the ODUk layers and the OCh layer.

   Therefore, an additional LSP Encoding Type code-point for the G.709
   Digital Path layer is defined; it enlarges the existing "Digital
   Wrapper" code-point defined in [RFC3471].  The former MUST be
   generated when the interface or tunnel on which the traffic will be
   transmitted supports G.709 compliant Digital Path layer encoding.
   The latter MUST only be used for non-G.709 compliant Digital Wrapper
   layer(s) encoding.  A transit or an egress node (receiving a Path
   message containing a GENERALIZED_LABEL_REQUEST object) MUST generate
   a PathErr message, with a "Routing problem/Unsupported Encoding"
   indication, if the requested LSP Encoding Type cannot be supported on
   the corresponding incoming interface.

   In the same way, an additional LSP Encoding Type code-point for the
   G.709 Optical Channel layer is defined; it enlarges the existing
   "Lambda" code-point defined in [RFC3471].  The former MUST be
   generated when the interface or tunnel on which the traffic will be
   transmitted supports G.709-compliant Optical Channel layer encoding.
   The latter MUST only be used for non-G.709 compliant Lambda layer(s)
   encoding.  A transit or an egress node (receiving a Path message that
   contains a GENERALIZED_LABEL_REQUEST object) MUST generate a PathErr
   message with a "Routing problem/Unsupported Encoding" indication, if
   the requested LSP Encoding Type cannot be supported on the
   corresponding incoming interface.







Papadimitriou               Standards Track                     [Page 5]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


   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 requested 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 (see [RFC4202]).

   No additional Switching Type values are to be considered in order to
   accommodate G.709 switching types, because an ODUk switching (and
   thus LSPs) belongs to the TDM class, while an OCh switching (and thus
   LSPs) belong to the Lambda class (i.e., LSC).

   Intermediate and egress nodes MUST verify that the value indicated in
   the Switching Type field is supported on the corresponding incoming
   interface.  If the requested value can not be supported, the node
   MUST generate a PathErr message with a "Routing problem/Switching
   Type" indication.

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)



Papadimitriou               Standards Track                     [Page 6]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


   - 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
    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: Values 49 and 50 include mapping of SDH.








Papadimitriou               Standards Track                     [Page 7]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


   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 (or simply traffic parameters) is carried
   additionally to the one included in the Generalized Label Request.

   The G.709 traffic parameters are 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.

   The RSVP-TE encoding of the G.709 traffic-parameters is detailed in
   Section 6.

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       Not significant
        1       ODU1 (i.e., 2.5 Gbps)
        2       ODU2 (i.e., 10  Gbps)
        3       ODU3 (i.e., 40  Gbps)
        4       Reserved (for future use)



Papadimitriou               Standards Track                     [Page 8]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


        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 [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 that is actually requested for the
   LSP.  Each transform application is optional and must be ignored if
   zero; this does not include the Multiplier (MT), which 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) that
   constitute the requested connection.  These components are still
   processed within the context of a single connection entity.  For all



Papadimitriou               Standards Track                     [Page 9]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


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

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
   LSPs, i.e., values greater than zero, are only acceptable for ODUk
   Signal Types.  Therefore, it MUST be set to zero (NVC = 0), and
   should be ignored when received, when a G.709 OCh LSP is requested.

3.2.4.  Multiplier (MT)

   The Multiplier field (16 bits) indicates the number of identical
   Elementary Signals or Composed Signals that are 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 signaling 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 cannot be supported, the receiver
   node MUST generate a PathErr message (see Section 6).

   Zero is an invalid value for the MT field.  If received, the node
   MUST generate a PathErr message (see Section 6).

3.2.5.  Reserved Fields

   The reserved fields (8 bits in row 1 and 32 bits 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



Papadimitriou               Standards Track                    [Page 10]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


   [RFC3471].  The format of the corresponding RSVP-TE GENERALIZED_LABEL
   object is specified in [RFC3473] Section 2.3.

   The label distribution rules detailed in Section 4.2 follow (when
   applicable) the ones defined in [RFC3946].

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) that 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 whose leaves are 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.




Papadimitriou               Standards Track                    [Page 11]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


   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 (i.e.,
          t1 value MUST be set to 0 and ignored).

   2. t2 (3-bit):
        - t2=1 indicates an ODU2 signal that is not further sub-
          divided.
        - 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 (i.e., t2 value MUST be
          set to 0 and ignored).

   3. t3 (6-bit):
        - t3=1 indicates an ODU3 signal that is not further sub-
          divided.
        - 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






Papadimitriou               Standards Track                    [Page 12]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


4.2.  Label Distribution Rules

   In case of ODUk in OTUk mapping, only one label can appear in the
   Generalized Label.  The unique label is encoded as a single 32-bit
   label value (as defined in Section 4.1) of the GENERALIZED_LABEL
   object (Class-Num = 16, C-Type = 2).

   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).  This ordered list of
   labels is encoded as a sequence of 32-bit label values (as defined in
   Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type
   = 2).

   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.  This ordered list of labels is
   encoded as a sequence of 32-bit label values (as defined in Section
   4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-Type = 2).
   In case of ODUk virtual concatenation, the number of label values is
   determined by the NVC value.  Multiplexed ODUk virtual concatenation
   additionally uses the NMC value to determine the number of labels per
   set (equal in size).

   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.
   This ordered list of labels is encoded as a sequence of 32-bit label
   values (as defined in Section 4.1) of the GENERALIZED_LABEL object
   (Class-Num = 16, C-Type = 2).  In case of multiplication of (equal)
   ODUk virtual concatenated signals, the number of label values per
   signal is determined by the NVC value.  Multiplication of multiplexed



Papadimitriou               Standards Track                    [Page 13]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


   (equal) ODUk virtual concatenation additionally uses the NMC value to
   determine the number of labels per set (equal in size).

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 that correspond to the OTM-n.m sub-interface signals
   (m = 1, 2 or 3).  Note that these identifiers do not cover OChr
   because 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, whereas 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 because the ODU1 (ODU2 or ODU3) is directly mapped into the
      corresponding OTU1 (OTU2 or OTU3).  Because 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 an ODU1 signal request.



Papadimitriou               Standards Track                    [Page 14]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


      In such conditions, the downstream node has to return a unique
      label because 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).
      Because 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 an 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 an ODU3, it
      returns an ordered list of four labels to the upstream node: the
      first ODU1 label corresponds to the first signal of the LSP, the
      second ODU1 label corresponds 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)



Papadimitriou               Standards Track                    [Page 15]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


6.  RSVP-TE Signaling Protocol Extensions

   This section specifies the [RFC3473] protocol extensions needed to
   accommodate G.709 traffic parameters.

   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 = 5
   - G.709 FLOWSPEC Object: Class = 9, C-Type = 5

   There is no Adspec associated with the G.709 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) cannot 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]).

7.  Security Considerations

   This document introduces no new security considerations to [RFC3473].

8.  IANA Considerations

   Two values have been defined by IANA for this document:

   Two RSVP C-Types in registry:

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




Papadimitriou               Standards Track                    [Page 16]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


             - A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5 - see
               Section 6.

             - A G.709 FLOWSPEC object: Class = 9, C-Type = 5 - see
               Section 6.

   IANA will also track the code-point spaces extended and/or updated by
   this document.  For this purpose, the following new registry entries
   have been added in the newly requested registry entry:
   http://www.iana.org/assignments/gmpls-sig-parameters

   - LSP Encoding Type:
     Name: LSP Encoding Type
     Format: 8-bit number
     Values:
        [1..11]         defined in [RFC3471]
        12              defined in Section 3.1.1
        13              defined in Section 3.1.1
     Allocation Policy:
        [0..239]        Assigned by IANA via IETF Standards Track RFC
                        Action.
        [240..255]      Assigned temporarily for Experimental Usage.
                        These will not be registered with IANA

   - Switching Type:
     Name: Switching Type
     Format: 8-bit number
     Values: defined in [RFC3471]
     Allocation Policy:
        [0..255]        Assigned by IANA via IETF Standards Track RFC
                        Action.

   - Generalized PID (G-PID):
     Name: G-PID
     Format: 16-bit number
     Values:
        [0..31]         defined in [RFC3471]
        [32..35]        defined in [RFC3471] and updated by Section
                        3.1.3
        [36..46]        defined in [RFC3471]
        [47..58]        defined in Section 3.1.3
     Allocation Policy:
        [0..31743]      Assigned by IANA via IETF Standards Track RFC
                        Action.
        [31744..32767]  Assigned temporarily for Experimental Usage






Papadimitriou               Standards Track                    [Page 17]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


        [32768..65535]  Not assigned.  Before any assignments can be
                        made in this range, there MUST be a Standards
                        Track RFC that specifies IANA Considerations
                        that covers the range being assigned.

   Note: per [RFC3471], Section 3.1.1, standard Ethertype values are
   used as G-PIDs for packet and Ethernet LSPs.

9.  Acknowledgements

   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.  Many
   thanks to Adrian Farrel for having thoroughly reviewed this document.

   This document incorporates (upon agreement) material and ideas from a
   work in progress, "Common Label and Label Request Specification for
   Automatic Switched Transport Network", by Zhi Lin.

10.  References

10.1.  Normative References

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

   [RFC2205]    Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
                Jamin, "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.

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

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

   [RFC3946]    Mannie, E. and D. Papadimitriou, "Generalized Multi-
                Protocol Label Switching (GMPLS) Extensions for
                Synchronous Optical Network (SONET) and Synchronous
                Digital Hierarchy (SDH) Control", RFC 3946, October
                2004.



Papadimitriou               Standards Track                    [Page 18]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


   [RFC4202]    Kompella, K., Ed. and Y. Rekhter, Ed., "Routing
                Extensions in Support of Generalized Multi-Protocol
                Label Switching (GMPLS)", RFC 4202, September 2005.

10.2.  Informative References

   [RFC3945]    Mannie, E., "Generalized Multi-Protocol Label Switching
                (GMPLS) Architecture", RFC 3945, October 2004.

   For information on the availability of the following documents,
   please see http://www.itu.int

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

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







Papadimitriou               Standards Track                    [Page 19]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


   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



















Papadimitriou               Standards Track                    [Page 20]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


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








Papadimitriou               Standards Track                    [Page 21]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


Appendix B.  G.709 Indexes

   - Index k: The index "k" is used to represent a supported bit rate
   and the different versions of OPUk, ODUk and OTUk. k=1 represents an
   approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate bit
   rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s and k =
   4 an approximate bit rate of 160 Gbit/s (under definition).  The
   exact bit-rate values are in kbits/s:

    . OPU: k=1: 2 488 320.000, k=2:  9 995 276.962, k=3: 40 150 519.322

    . ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983

    . OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559

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

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

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

Editor's Address

   Dimitri Papadimitriou (Alcatel)
   Francis Wellesplein 1,
   B-2018 Antwerpen, Belgium

   Phone: +32 3 240-8491
   EMail: dimitri.papadimitriou@alcatel.be











Papadimitriou               Standards Track                    [Page 22]
^L
RFC 4328          GMPLS Signaling Extensions for G.709      January 2006


Full Copyright Statement

   Copyright (C) The Internet Society (2006).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).







Papadimitriou               Standards Track                    [Page 23]
^L