CCAMP Working Group Alberto Bellato (Alcatel)
Category: Internet Draft Sudheer Dharanikota (Nayna)
Expiration Date: May 2002 Michele Fontana (Alcatel)
James Fu (Sorrento)
Germano Gasparini (Alcatel)
Nasir Ghani (Sorrento)
Gert Grammel (Alcatel)
Dan Guo (Turin)
Juergen Heiles (Siemens)
Jim Jones (Alcatel)
Zhi-Wei Lin (Lucent)
Eric Mannie (Ebone)
Dimitri Papadimitriou (Alcatel)
Siva Sankaranarayanan (Lucent)
Maarten Vissers (Lucent)
Yangguang Xu (Lucent)
Yong Xue (WorldCom)
November 2001
GMPLS Signalling Extensions
for G.709 Optical Transport Networks Control
draft-fontana-ccamp-gmpls-g709-02.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Conventions used in this document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
D.Papadimitriou et al. - Internet Draft Expires May 2002 1
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
Abstract
This document is a companion to the Generalized MPLS (GMPLS)
signalling documents [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It
describes the G.709 technology specific information needed to
extend GMPLS signalling to control Optical Transport Networks
(OTN); it also includes the so-called pre-OTN developments. Both
technologies are described in [G709-FRM].
1. Introduction
Generalized MPLS extends MPLS from supporting Packet Switching
Capable (PSC) interfaces and switching to include support of three
new classes of interfaces and switching: Time-Division Multiplex
(TDM), Lambda Switch (LSC) and Fiber-Switch (FSC). A functional
description of the extensions to MPLS signaling needed to support
this new classes of interfaces and switching is provided in
[GMPLS-SIG]. [GMPLS-RSVP] describes RSVP-TE specific formats and
mechanisms needed to support all four classes of interfaces, and
CR-LDP extensions can be found in [GMPLS-LDP].
This document presents the technology details that are specific to
G.709 Optical Transport Networks (OTN) as specified in the ITU-T
G.709 recommendation [ITUT-G709], including pre-OTN developments.
Per [GMPLS-SIG], G.709 specific parameters are carried through the
signaling protocol in traffic parameter specific objects.
Note: by pre-OTN developments, one refers to the following cases
which applies when the client signal is Gigabit Ethernet, ESCON,
FICON or Fiber Channel (FC):
- pre-OTN digital wrapper frame terminated; service signal is bit
stream oriented and transparently passed throughout the network
- pre-OTN case FEC frame terminated; service signal is bit stream
oriented and transparently passed through
Details concerning SONET/SDH LSPs including Regenerator
Section(RS)/Section and Multiplex Section(MS)/Line overhead
transparency are covered in [GMLS-SSS] and [GMPLS-SSS-EXT].
2. GMPLS Extensions for G.709
Although G.709 defines several networking layers (OTS, OMS, OPS,
OCh, OChr constituting the optical transport hierarchy and OTUk,
ODUk constituting the digital transport hierarchy) only the OCh
(Optical Channel) and the ODUk (Optical Channel Data Unit) layers
are defined as switching layers. Both OCh (but not OChr) and ODUk
layers include the overhead for supervision and management. The OCh
overhead is transported in a non-associated manner (so also referred
to as the non-associated overhead naOH) in the OTM Overhead Signal
(OOS), together with the OTS and OMS non-associated overhead. The
OOS is transported via a dedicated wavelength referred to as the
Optical Supervisory Channel (OSC). It should be noticed that the
naOH is only functionally specified and as such open to vendor
D.Papadimitriou et al. - Internet Draft Expires May 2002 2
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
specific solutions. The ODUk overhead is transported in an
associated manner as part of the digital ODUk frame.
Therefore, adapting GMPLS to control G.709 OTN, can be achieved by
considering:
- a Digital Path layer by extending the previously defined
Digital Wrapper÷ in [GMPLS-SIG] corresponding to the ODUk
switching layer.
- an Optical Path layer by extending the Lambda÷ concept defined in
[GMPLS-SIG] to the OCh switching layer.
Thus, GMPLS extensions for G.709 need to cover the Generalized Label
Request, the Generalized Label as well as the specific technology
dependent fields equivalent to the one currently specified for
SDH/SONET in [GMPLS-SSS]. Since the multiplexing in the digital
domain (such as ODUk multiplexing) has been considered in the
updated version of the G.709 recommendation (October 2001), we can
already propose a label space definition suitable for that purpose.
Notice also that we directly use the G.709 ODUk (i.e. Digital Path)
and OCh layers in order to define the corresponding label spaces.
3. Generalized Label Request
The Generalized Label Request as defined in [GMPLS-SIG], includes a
technology independent part and a technology dependent part (i.e.
the traffic parameters). In this section, we suggest to adapt both
parts in order to accommodate the GMPLS Signalling to the G.709
recommendation [ITUT-G709].
3.1 Technology Independent Part
As defined in [GMPLS-SIG], the LSP Encoding Type and the Generalized
Protocol Identifier (Generalized-PID) constitute the technology
independent part of the Generalized Label Request.
The information carried in the technology independent part of the
Generalized Label Request is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LSP Enc. Type |Switching Type | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As mentioned here above, we suggest here to adapt the LSP Encoding
Type and the G-PID (Generalized-PID) to accommodate G.709
recommendation [ITUT-G709].
3.1.1 LSP Encoding Type
Since G.709 defines two networking layers (ODUk layers and OCh
layer), the LSP Encoding Type code-points can reflect these two
D.Papadimitriou et al. - Internet Draft Expires May 2002 3
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
layers currently defined in [GMPLS-SIG] as Digital Wrapper÷ and
Lambda÷ code.
The LSP Encoding Type is specified per networking layer or more
precisely per group of functional networking layer: the ODUk layers
and the OCh layer.
Therefore, the current Digital Wrapper÷ code-point defined in
[GMPLS-SIG] can be replaced by two separated code-points:
- code-point for the G.709 Digital Path layer
- code-point for the non-standard Digital Wrapper layer
In the same way, two separated code-points can replace the current
defined Lambda÷ code-point:
- code-point for the G.709 Optical Channel layer
- code-point for the non-standard Lambda layer (also referred to
as Lambda layer which includes the pre-OTN Optical Channel
layer)
Consequently, we have the following additional code-points for the
LSP Encoding Type:
Value Type
----- ----
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.
No additional values are to be considered in order to accommodate
G.709 switching types since an ODUk switching belongs to the TDM
class while an OCh switching to the Lambda class.
However, in a strict layered G.709 network architecture, when a
downstream node receives a Generalized Label Request with one of
these values as Switching Type, this value is ignored.
3.1.3 Generalized-PID (G-PID)
The G-PID (16 bits field) as defined in [GMPLS-SIG], identifies the
payload carried by an LSP, i.e. an identifier of the client layer of
that LSP. This identifier is used by the endpoints of the G.709 LSP.
D.Papadimitriou et al. - Internet Draft Expires May 2002 4
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
The G-PID can take one of the following values when the client
payload is transported over the Digital Path layer, in addition to
the payload identifiers already defined in [GMPLS-SIG]:
- CBRa: asynchronous Constant Bit Rate i.e. mapping of STM-16/OC-48,
STM-64/OC-192 and STM-256/OC-768
- CBRb: bit synchronous Constant Bit Rate i.e. mapping of STM-16/OC-
48, STM-64/OC-192 and STM-256/OC-768
- ATM: mapping at 2.5, 10 and 40 Gbps
- BSOT: non-specific client Bit Stream with Octet Timing i.e.
Mapping of 2.5, 10 and 40 Gbps Bit Stream
- BSNT: non-specific client Bit Stream without Octet Timing i.e.
Mapping of 2.5, 10 and 40 Gbps Bit Stream
- ODUk: transport of Digital Path at 2.5, 10 and 40 Gbps
The G-PID can take one of the following values when the client
payload is transported over the Optical Channel layer, in addition
to the payload identifiers already defined in [GMPLS-SIG]:
- CBR: Constant Bit Rate i.e. mapping of STM-16/OC-48, STM-64/OC-192
and STM-256/OC-768
- OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps
When the client payloads such as Ethernet/MAC and IP/PPP are
encapsulated through the Generic Framing Procedure (GFP) as
described in ITU-T G.7041, we use dedicated G-PID values. Notice
that additional G-PID values such as ESCON, FICON and Fiber Channel
could complete this list in future releases.
In order to include pre-OTN developments as defined above, the G-PID
can take one of the values currently defined in [GMPLS-SIG], when
the client payload is transported over an Optical Channel (i.e. a
lambda):
- Gigabit Ethernet: 1 Gbps and 10 Gbps
- ESCON and FICON : left for further consideration
- Fiber Channel : left for further consideration
The following table summarizes the G-PID with respect to the LSP
Encoding Type:
Value G-PID Type LSP Encoding Type
----- ---------- -----------------
44 G.709 ODUj G.709 ODUk (with k > j)
45 G.709 OTUk(v) G.709 OCh (ODUk mapped into OTUk(v))
46 CBR/CBRa G.709 ODUk, G.709 OCh
47 CBRb G.709 ODUk
48 BSOT G.709 ODUk
49 BSNT G.709 ODUk
50 IP/PPP (GFP) G.709 ODUk
51 Ethernet (GFP) G.709 ODUk
The following table summarizes the update of the G-PID values
defined in [GMPLS-SIG]:
Value G-PID Type LSP Encoding Type
D.Papadimitriou et al. - Internet Draft Expires May 2002 5
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
----- ---------- -----------------
32 ATM Mapping SONET, SDH, G.709 ODUk
33 Ethernet (GbE) G.709 ODUk, G.709 OCh, Lambda, Fiber
34 SDH G.709 ODUk, G.709 OCh, Lambda, Fiber
35 SONET G.709 ODUk, G.709 OCh, Lambda, Fiber
3.2 G.709 Traffic-Parameters
When G.709 Digital Path Layer or G.709 Optical Channel Layer is
specified in the LSP Encoding Type field, the information referred
to as technology dependent information or simply traffic-parameters
and carried additionally to the one included in the Generalized
Label Request is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | RMT | NMC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this frame, RMT stands for Requested Multiplexing Type, NMC for
Number of Multiplexed Components and NVC for Number of Virtual
Components. Each of these fields is tailored in order to support
G.709 LSP.
3.2.1 Signal Type
This field (8 bits) indicates the requested G.709 elementary Signal
Type. The possible values are:
Value Type
----- ----
0 irrelevant
1 ODU1 (i.e. 2.5 Gbps)
2 ODU2 (i.e. 10 Gbps)
3 ODU3 (i.e. 40 Gbps)
4 Reserved for future use
5 Reserved for future use
6 OCh at 2.5 Gbps
7 OCh at 10 Gbps
8 OCh at 40 Gbps
9-255 Reserved for future use
The value of the Signal Type field depends on LSP Encoding Type
value defined in Section 3.1.1 and [GMPLS-SIG]:
- if the LSP Encoding Type value is the G.709 Digital Path layer
then the valid values are the ODUk signals (k = 1, 2 or 3)
- if the LSP Encoding Type value is the G.709 Optical Channel layer
then the valid values are the OCh at 2.5, 10 or 40 Gbps
D.Papadimitriou et al. - Internet Draft Expires May 2002 6
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
- if the LSP Encoding Type is Lambda÷ (which includes the
pre-OTN Optical Channel layer) then the valid value is irrelevant
(Signal Type = 0)
- if the LSP Encoding Type is Digital Wrapper÷, then the valid
value is irrelevant (Signal Type = 0)
3.2.2 Requested Multiplexing Type (RMT)
The RMT field (8 bits) defined as a vector of flags indicating the
type of multiplexing being requested for ODUk LSP. Each flag
indicates the support of a particular type of ODUk multiplexing.
These flags allow an upstream node to indicate to a downstream node
the different types of multiplexing that it supports. However, the
downstream node decides which one to use according to its own rules.
Several flags could be set simultaneously to indicate a particular
choice.
The entire field is set to zero to indicate that no multiplexing is
requested at all. The possible values for these flags are defined in
the following table:
Flag 1 (bit 1): Multiplexing
When used at the ODUk layer (i.e. digital path layer), application
of multiplexing to ODUk elementary signal results in so called ODUk-
Xc signal. In particular, ODUk multiplexing allows the multiplexing
of an ODU2 into four ODU tributary slots, which can be arbitrarily
selected to prevent that the bandwidth gets fragmented.
As described in [G709-FRM], in addition to the support of ODUk
mapping into OTUk, [ITUT-G.709] supports ODUk multiplexing. It
refers to the multiplexing of ODUj (j = 1, 2) into an ODUk (k > j)
signal, in particular:
- ODU1 into ODU2 multiplexing
- ODU1 into ODU3 multiplexing
- ODU2 into ODU3 multiplexing
- ODU1 and ODU2 into ODU3 multiplexing
More precisely, ODUj into ODUk multiplexing (k > j) is defined when
an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an
ODTUG constituted by ODU tributary slots) which is mapped into an
OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is
mapped into an OTUk.
The RMT field is set to zero (by default) to indicate an ODUk
mapping i.e. ODUk multiplexing is not requested.
At the Optical Channel layer, multiplexing is not defined in [ITU-T
G.709]. Therefore, the entire RMT field is set by default to zero
when requesting an OCh G.709 LSP.
3.2.3 Number of Multiplexed Components (NMC)
D.Papadimitriou et al. - Internet Draft Expires May 2002 7
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
The NMC field (16 bits) indicates the number of ODU tributary slots
used by an ODUj when multiplexed into an ODUk (k > j) for the
requested LSP, as specified in the RMT field. This field is
irrelevant if no multiplexing is requested (in particular at the
Optical Channel layer). In that case, it must be set to zero (NMC =
0) when sent and should be ignored when received. An RMT value
different from 0 must imply a number of components greater or equal
to 1.
When applied at the Digital Path layer and requesting multiplexing
(RMT = 1), 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, the NMC field is set to 1.
3.2.4 Number of Virtual Components (NVC)
The NVC field (16 bits) is dedicated to Inverse Multiplexing (i.e.
ODUk virtual concatenation) purposes. It indicates the number of
ODU1, ODU2 or ODU3 elementary signals that are requested to be
virtually concatenated to form an ODUk-Xv signal. These signals must
be of the same type by definition.
This field is set to 0 (default value) to indicate that no virtual
concatenation is requested.
Note: the current usage of this field only applies for G.709 ODUk
LSP. Therefore, it must be set to zero when requesting G.709 OCh
LSP.
3.2.5 Multiplier
The multiplier field (16 bits) indicates the number of identical
composed signals requested for the LSP. A composed signal is the
resulting signal from the application of the RMT, NMC and NVC fields
to an elementary Signal Type. GMPLS signalling implies today that
all the composed signals must be part of the same LSP.
The multiplier field is set to one (default value) to indicate that
exactly one base signal is being requested. Zero is an invalid
value. When the multiplier field is greater than one, the resulting
signal is referred to as a multiplied signal.
3.2.6 Reserved
The reserved field (32 bits) is dedicated for future use. Reserved
bits should be set to zero when sent and must be ignored when
received.
4. Generalized Label
D.Papadimitriou et al. - Internet Draft Expires May 2002 8
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
This section describes the Generalized Label space for the Digital
Path and the Optical Channel Layer. The label distribution rules
follows the ones defined in [GMPLS-SSS] and are detailed in Section
4.2.
4.1 ODUk Label Space
At the Digital Path layer (i.e. ODUk layers), G.709 defines three
different client payload bit rates. An Optical Data Unit (ODU)
frame has been defined for each of these bit rates. ODUk refers to
the frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps)
or 3 (for 40 Gbps).
In addition to the support of ODUk mapping into OTUk, the G.709
label space supports the sub-levels of ODUk multiplexing. ODUk
multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk
(k > j), in particular:
- ODU1 into ODU2 multiplexing
- ODU1 into ODU3 multiplexing
- ODU2 into ODU3 multiplexing
- ODU1 and ODU2 into ODU3 multiplexing
More precisely, ODUj into ODUk multiplexing (k > j) is defined when
an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an
ODTUG constituted by ODU tributary slots) which is mapped into an
OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is
mapped into an OTUk.
Therefore, the label space structure is a tree whose root is an OTUk
signal and leaves the ODUj signals (k >= j) that can be transported
via the tributary slots and switched between these slots. A G.709
Digital Path layer label identifies the exact position of a
particular ODUj signal in an ODUk multiplexing structure.
The G.709 Digital Path Layer label or ODUk label has the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | k3 | k2 |k1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The specification of the three fields k1, k2 and k3 self-
consistently characterizes the ODUk label space. The value space of
the k1, k2 and k3 fields is defined as follows:
1. k1 (1-bit) indicates:
- an unstructured client signal mapped into an ODU1 (k1 = 1)
via OPU1
2. k2 (3-bit) indicates:
D.Papadimitriou et al. - Internet Draft Expires May 2002 9
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
- an unstructured client signal mapped into an ODU2 (k2 = 1)
via OPU2
- or the position of an ODU1 tributary slot in an ODTUG2 (k2 =
2,..,5) mapped into an ODU2 (via OPU2)
3. k3 (6-bit) indicates:
- an unstructured client signal mapped into an ODU3 (k3 = 1)
via OPU3
- or the position of an ODU1 tributary slot in an ODTUG3 (k3 =
2,..,17) mapped into an ODU3 (via OPU3)
- or the position of an ODU2 tributary slot in an ODTUG3 (k3 =
18,..,33) mapped into an ODU3 (via OPU3)
If label k[i]=1 (i = 1, 2 or 3) and labels k[j]=0 (j = 1, 2 and 3
with j=/=i), the corresponding ODUk signal ODU[i] is not structured
and therefore simply mapped into the corresponding OTU[i]. We refer
to this as the mapping of an ODUk into an OTUk. Therefore, the
numbering starts at 1, zero is used to indicate a non-significant
field. A label field equal to zero is an invalid value.
Examples:
- k3=0, k2=0, k1=1 indicated an ODU1 mapped into an OTU1
- k3=0, k2=1, k1=0 indicated an ODU2 mapped into an OTU2
- k3=1, k2=0, k1=0 indicates an ODU3 mapped into an OTU3
- k3=0, k2=3, k1=0 indicates the second ODU1 into an ODTUG2 mapped
into an ODU2 (via OPU2) mapped into an OTU2
- k3=5, k2=0, k1=0 indicates the fourth ODU1 into an ODTUG3 mapped
into an ODU3 (via OPU3) mapped into an OTU3
Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required
to identify the 4 tributary slots used by the ODU2.
4.2 Label Distribution Rules
In case of ODUk in OTUk mapping, only one of label can appear in the
Label field of a Generalized Label.
In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered
list of the labels in the multiplex is given (this list can be
restricted to only one label when NMC = 1). Each label indicates a
component (ODUj tributary slot) of the multiplexed signal. The order
of the labels must reflect the order of the ODUj into the multiplex
(not the physical order of tributary slots).
In case of ODUk virtual concatenation, the explicit ordered list of
all labels in the concatenation is given. Each label indicates a
component of the virtually concatenated signal. The order of the
labels must reflect the order of the ODUk to concatenate (not the
physical order of time-slots). This representation limits virtual
concatenation to remain within a single (component) link.
In case of multiplication (i.e. when using the MT field), the
explicit ordered list of all labels taking part in the composed
D.Papadimitriou et al. - Internet Draft Expires May 2002 10
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
signal is given. In case of multiplication of multiplexed/virtually
concatenated signals, the first set of labels indicates the first
multiplexed/virtually concatenated signal, the second set of labels
indicates the second multiplexed/virtually concatenated signal, and
so on. The above representation limits multiplication to remain
within a single (component) link.
4.3 Optical Channel Label Space
At the Optical Channel layer, the label space must be consistently
defined as a flat space whose values reflect the local assignment of
OCh identifiers corresponding to the OTM-n.m sub-interface signals
(m = 1, 2 or 3). Notice that these identifiers do not cover OChr
since the corresponding Connection Function (OChr-CF) between OTM-
nr.m/OTM-0r.m is not yet defined in [ITUT-G798].
The OCh identifiers could be defined as specified in [GMPLS-SIG]
either with absolute values: channel identifiers (Channel ID) also
referred to as wavelength identifiers or relative values: channel
spacing also referred to as inter-wavelength spacing. The latter is
strictly confined to a per-port label space while the former could
be defined as a local or a global label space. Such an OCh label
space is applicable to both OTN Optical Channel layer and pre-OTN
Optical Channel layer. For this layer, label distribution rules are
defined in [GMPSL-SIG].
5. Applications
These applications examples are given in order to illustrate the
processing described in the previous sections.
1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) non-
structured signal is transported into the payload of an OTU1
(OTU2 or OTU3), the upstream node requests results in a non-
structured ODU1 (ODU2 or ODU3) signal request.
In such conditions, the downstream node has to return a unique
label since the ODU1 (ODU2 or ODU3) is directly mapped into the
corresponding OTU1 (OTU2 or OTU3). Since a single ODUk mapped
signal is requested (Signal Type = 1, 2 or 3 and RMT = 0), the
downstream node has to return a single ODUk label which can be
for instance one of the following when the Signal Type = 1:
- k3=0, k2=0, k1=1 indicating a single ODU1 mapped into an OTU1
- k3=0, k2=1, k1=0 indicating a single ODU2 mapped into an OTU2
- k3=1, k2=0, k1=0 indicating a single ODU3 mapped into an OTU3
2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed
into the payload of a structured ODU2 (or ODU3), the upstream
node requests results in a multiplexed ODU1 signal request (RMT =
1).
In such conditions, the downstream node has to return a unique
label since the ODU1 is multiplexed into one ODTUG2 (or ODTUG3).
D.Papadimitriou et al. - Internet Draft Expires May 2002 11
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or
OPU3) and then mapped into the corresponding OTU2 (or OTU3).
Since a single ODU1 multiplexed signal is requested (Signal Type
= 1, RMT = 1 and NMC = 1), the downstream node has to return a
single ODU1 label which can take for instance one of the
following values:
- k3=0, k2=4, k1=0 indicates the third ODU1 TS into ODTUG2
- k3=2, k2=0, k1=0 indicates the first ODU1 TS into ODTUG3
- k3=7, k2=0, k1=0 indicates the sixth ODU1 TS into ODTUG3
3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is
multiplexed into the payload of a structured ODU3, the upstream
node requests results in a multiplexed ODU2 signal request (RMT =
1).
In such conditions, the downstream node has to return four labels
since the ODU2 is multiplexed into one ODTUG3. The latter is
mapped into an ODU3 (via OPU3) and then mapped into an OTU3.
Since an ODU2 multiplexed signal is requested (Signal Type = 2,
RMT = 1 and NMC = 4), the downstream node has to return four ODU
labels which can take for instance the following values:
- k3=18, k2=0, k1=0 (first ODU TS into ODTUG3)
- k3=22, k2=0, k1=0 (fifth ODU TS into ODTUG3)
- k3=23, k2=0, k1=0 (sixth ODU TS into ODTUG3)
- k3=26, k2=0, k1=0 (ninth ODU TS into ODTUG3)
4. When a single OCh signal of 40 Gbps is requested (Signal Type = 8
and RMT = 0), the downstream node must return a single wavelength
label as specified in [GMPLS-SIG].
5. When requesting multiple ODUk LSP (i.e. multiplier MT > 1), an
explicit list of labels is returned to the requestor node. When
the downstream node receives a request for a 4 x ODU1 signal
(Signal Type = 1, RMT = 1, NMC = 1 and MT = 4), it returns an
ordered list of four labels to the upstream node: the first ODU1
label corresponding to the first signal of the LSP, the second
ODU1 label corresponding to the second signal of the LSP, etc.
For instance, the corresponding labels can take the following
values:
- First ODU1: k3=2, k2=0, k1=0 (first ODU1 TS into ODTUG3)
- Second ODU1: k3=6, k2=0, k1=0 (fifth ODU1 TS into ODTUG3)
- Third ODU1: k3=7, k2=0, k1=0 (sixth ODU1 TS into ODTUG3)
- Fourth ODU1: k3=10, k2=0, k1=0 (ninth ODU1 TS into ODTUG3)
6. Signalling Protocol Extensions
This section specifies the [GMPLS-RSVP] and [GMPLS-LDP] protocol
extensions needed to accommodate G.709 traffic parameters.
6.1 RSVP-TE Details
For RSVP-TE, the G.709 traffic parameters are carried in the G.709
SENDER_TSPEC and FLOWSPEC objects. The same format is used both
D.Papadimitriou et al. - Internet Draft Expires May 2002 12
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
for SENDER_TSPEC object and FLOWSPEC objects. The content of the
objects is defined above in Section 3.2. The objects have the
following class and type for G.709:
- G.709 SENDER_TSPEC Object: Class = 12, C-Type = 4 (TBA)
- G.709 FLOWSPEC Object: Class = 9, C-Type = 4 (TBA)
There is no Adspec associated with the SONET/SDH SENDER_TSPEC.
Either the Adspec is omitted or an Int-serv Adspec with the
Default General Characterization Parameters and Guaranteed Service
fragment is used, see [RFC2210].
For a particular sender in a session the contents of the FLOWSPEC
object received in a Resv message SHOULD be identical to the
contents of the SENDER_TSPEC object received in the corresponding
Path message. If the objects do not match, a ResvErr message with
a "Traffic Control Error/Bad Flowspec value" error SHOULD be
generated.
6.2 CR-LDP Details
For CR-LDP, the G.709 traffic parameters are carried in the G.709
Traffic Parameters TLV. The content of the TLV is defined in
Section 3.2. The header of the TLV has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type field indicates G.709 OTN: 0xTBA
7. Security Considerations
This document introduces no new security considerations to either
[GMPLS-RSVP] or [GMPLS-LDP].
8. References
1. [ITUT-G707] Network node interface for the synchronous digital
hierarchy (SDH)Ë, ITU-T Recommendation, April 2000.
2. [ITUT-G709] Interface for the Optical Transport Network (OTN)Ë,
ITU-T draft version 1.0, February 2001.
3. [ITUT-G798] Characteristics of Optical Transport Network
Hierarchy Equipment Functional BlocksË, ITU-T draft version 0.9,
October 2001.
4. [ITUT-G872] Architecture of Optical Transport NetworkË, ITU-T
draft version, February 2001.
5. [ITUT-GASTN] Automated Switched Transport NetworkË, ITU-T draft
D.Papadimitriou et al. - Internet Draft Expires May 2002 13
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
version, February 2001.
6. [GMPLS-ARCH] E. Mannie et al., Generalized Multi-Protocol Label
Switching (GMPLS) ArchitectureË, Internet Draft, Work in progress,
draft-ietf-ccamp-gmpls-architecture-01.txt, July 2001.
7. [GMPLS-LDP] P. Ashwood-Smith, L. Berger et al., Generalized MPLS
Signaling - CR-LDP ExtensionsË, Internet Draft, Work in progress,
draft-ietf-mpls-generalized-cr-ldp-04.txt, July 2001.
8. [GMPLS-RSVP] P. Ashwood-Smith, L. Berger et al., Generalized
MPLS Signaling - RSVP-TE ExtensionsË, Internet Draft, Work in
progress, draft-ietf-mpls-generalized-rsvp-te-05.txt, October
2001.
9. [GMPLS-SIG] P. Ashwood-Smith, L. Berger et al., Generalized MPLS
- Signaling Functional DescriptionË, Internet Draft, Work in
progress, draft-ietf-mpls-generalized-signaling-06.txt, October
2001.
10. [GMPLS-SSS] E.Mannie et al., Generalized MPLS SDH/Sonet
SpecificsË, Internet Draft, Work in progress, draft-ietf-ccamp-
gmpls-sonet-sdh-02.txt, October 2001.
11. [GMPLS-SSS-EXT] E.Mannie et al., Generalized MPLS SDH/Sonet
Specifics ExtensionsË, Internet Draft, Work in progress, draft-
ietf-ccamp-gmpls-sonet-sdh-extensions-00.txt, July 2001.
12. [G709-FRM] A. Bellato, D.Papadimitriou et al., G.709 Optical
Transport Networks GMPLS Control FrameworkË, Internet Draft, Work
in progress, draft-bellato-ccamp-g709-framework-01.txt, November
2001.
13. [RFC-2210] J. Wroclawski, The Use of RSVP with IETF Integrated
ServicesË, Internet RFC 2210, IETF Standard Track, September
1997.
9. Acknowledgments
The authors would like to be thank Bernard Sales, Emmanuel Desmet,
Jean-Loup Ferrant, Mathieu Garnot, Massimo Canali and Fong Liaw for
their constructive comments and inputs.
This draft incorporates material and ideas from draft-lin-ccamp-ipo-
common-label-request-00.txt.
10. Author's Addresses
Alberto Bellato
Alcatel
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7215
D.Papadimitriou et al. - Internet Draft Expires May 2002 14
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
Email: alberto.bellato@netit.alcatel.it
Michele Fontana
Alcatel
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7053
Email: michele.fontana@netit.alcatel.it
Germano Gasparini
Alcatel
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7670
Email: germano.gasparini@netit.alcatel.it
Nasir Ghani
Sorrento Networks
9990 Mesa Rim Road,
San Diego, CA 92121, USA
Phone: +1 858 646-7192
Email: nghani@sorrentonet.com
Gert Grammel
Alcatel
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-4453
Email: gert.grammel@netit.alcatel.it
Dan Guo
Turin Networks
1415 N. McDowell Blvd
Petaluma, CA 94954
Phone: +1 707 665-4357
Email: dguo@turinnetworks.com
Juergen Heiles
Siemens AG
Hofmannstr. 51
D-81379 Munich, Germany
Phone: +49 89 7 22 - 4 86 64
Email: Juergen.Heiles@icn.siemens.de
Jim Jones
Alcatel
3400 W. Plano Parkway,
Plano, TX 75075, USA
Phone: +1 972 519-2744
Email: Jim.D.Jones1@usa.alcatel.com
Zhi-Wei Lin
Lucent
D.Papadimitriou et al. - Internet Draft Expires May 2002 15
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
101 Crawfords Corner Rd, Rm 3C-512
Holmdel, New Jersey 07733-3030, USA
Tel: +1 732 949-5141
Email: zwlin@lucent.com
Eric Mannie
EBone (GTS)
Terhulpsesteenweg, 6A
1560 Hoeilaart, Belgium
Phone: +32 2 658-5652
Email: eric.mannie@ebone.com
Dimitri Papadimitriou (Editor)
Alcatel
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel.be
Siva Sankaranarayanan
Lucent
101 Crawfords Corner Rd
Holmdel, NJ 07733-3030
Email: siva@hotair.hobl.lucent.com
Maarten Vissers
Lucent
Boterstraat 45
Postbus 18
1270 AA Huizen, Netherlands
Email: mvissers@lucent.com
Yangguang Xu
Lucent
21-2A41, 1600 Osgood Street
North Andover, MA 01845, USA
Email: xuyg@lucent.com
Yong Xue
WorldCom
22001 Loudoun County Parkway
Ashburn, VA 20147, USA
Tel: +1 703 886-5358
E-mail: yong.xue@wcom.com
D.Papadimitriou et al. - Internet Draft Expires May 2002 16
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
Appendix 1 Abbreviations
1R Re-amplification
2R Re-amplification and Re-shaping
3R Re-amplification, Re-shaping and Re-timing
AI Adapted information
AIS Alarm Indication Signal
APS Automatic Protection Switching
BDI Backward Defect Indication
BEI Backward Error Indication
BI Backward Indication
BIP Bit Interleaved Parity
CBR Constant Bit Rate
CI Characteristic information
CM Connection Monitoring
EDC Error Detection Code
EXP Experimental
ExTI Expected Trace Identifier
FAS Frame Alignment Signal
FDI Forward Defect Indication
FEC Forward Error Correction
GCC General Communication Channel
IaDI Intra-Domain Interface
IAE Incoming Alignment Error
IrDI Inter-Domain Interface
MFAS MultiFrame Alignment Signal
MS Maintenance Signal
naOH non-associated Overhead
NNI Network-to-Network interface
OCC Optical Channel Carrier
OCG Optical Carrier Group
OCI Open Connection Indication
OCh Optical Channel (with full functionality)
OChr Optical Channel (with reduced functionality)
ODU Optical Channel Data Unit
OH Overhead
OMS Optical Multiplex Section
OMU Optical Multiplex Unit
OOS OTM Overhead Signal
OPS Optical Physical Section
OPU Optical Channel Payload Unit
OSC Optical Supervisory Channel
OTH Optical transport hierarchy
OTM Optical transport module
OTN Optical transport network
OTS Optical transmission section
OTU Optical Channel Transport Unit
PCC Protection Communication Channel
PLD Payload
PM Path Monitoring
PMI Payload Missing Indication
PRBS Pseudo Random Binary Sequence
PSI Payload Structure Identifier
D.Papadimitriou et al. - Internet Draft Expires May 2002 17
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
PT Payload Type
RES Reserved
RS Reed-Solomon
SM Section Monitoring
TC Tandem Connection
TCM Tandem Connection Monitoring
UNI User-to-Network Interface
Appendix 2 G.709 Indexes
- Index k: The index "k" is used to represent a supported bit rate
and the different versions of OPUk, ODUk and OTUk. k=1 represents an
approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate
bit rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s
and k = 4 an approximate bit rate of 160 Gbit/s (under definition).
The exact bit-rate values are in kbits/s:
. OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322
. ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983
. OTU: k=1: 2 666 057.143, k=2: 10 709 225.316, k=3: 43 018 413.559
- Index m: The index "m" is used to represent the bit rate or set of
bit rates supported on the interface. This is a one or more digit
k÷, where each k÷ represents a particular bit rate. The valid
values for m are (1, 2, 3, 12, 23, 123).
- Index n: The index "n" is used to represent the order of the OTM,
OTS, OMS, OPS, OCG and OMU. This index represents the maximum number
of wavelengths that can be supported at the lowest bit rate
supported on the wavelength. It is possible that a reduced number of
higher bit rate wavelengths are supported. The case n=0 represents a
single channel without a specific wavelength assigned to the
channel.
- Index r: The index "r", if present, is used to indicate a reduced
functionality OTM, OCG, OCC and OCh (non-associated overhead is not
supported). Note that for n=0 the index r is not required as it
implies always reduced functionality.
D.Papadimitriou et al. - Internet Draft Expires May 2002 18
draft-fontana-ccamp-gmpls-g709-02.txt November 2001
Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
D.Papadimitriou et al. - Internet Draft Expires May 2002 19