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
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].
*** 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
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]).
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.
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)
- 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.
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)
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
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
[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