CCAMP Working Group Alberto Bellato (Alcatel)
Category: Internet Draft Michele Fontana (Alcatel)
Expiration Date: December 2001 Germano Gasparini (Alcatel)
Gert Grammel (Alcatel)
Jim Jones (Alcatel)
Zhi-Wei Lin (Lucent)
Eric Mannie (EBone)
Dimitri Papadimitriou (Alcatel)
Siva Sankaranarayanan (Lucent)
Maarten Vissers (Lucent)
Yangguang Xu (Lucent)
June 2001
GMPLS Signalling Extensions
for G.709 Optical Transport Networks Control
draft-fontana-ccamp-gmpls-g709-00.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 - Internet Draft û Expires December 2001 1
draft-fontana-ccamp-gmpls-g709-00.txt June 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) including the so-called pre-OTN developments both 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
the 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
present the technology details that are specific to G.709 Optical
Transport Networks (OTN) as specified in ITU-T G.709
recommendation [ITUT-G709] which also includes pre-OTN
developments. Per [GMPLS-SIG], G.709 specific parameters are
carried through the signaling protocol in traffic parameter
specific objects.
2. GMPLS Extensions for G.709
Adapting GMPLS to control G.709 OTN, can be achieved by considering
that G.709 defines two transport hierarchies: a digital (also known
as the ôDigital Wrapperö) and an optical transport hierarchy. First,
a digital layer (the previously defined ôDigital Wrapperö in [GMPLS-
SIG]), which is defined as a Digital Path Layer, indeed a new TDM
technology. Second, an Optical Channel layer or Optical Path layer
including a digital OTM Overhead Signal (OOS), i.e. a non-associated
overhead.
GMPLS extensions for G.709 need to cover the Generalized Label
Request, the Generalized Label as well as specific technology
dependent fields such as those currently specified for SDH/SONET in
[GMPLS-SSS]. Since the multiplexing in the electrical domain (such
as ODUk multiplexing) will be added very soon into the version 2 of
the G.709 recommendation, we can already propose a label space
definition suitable for that purpose.
As implicitly specified in GMPLS control for SDH/SONET Networks
[GMPLS-SSS], since GFP is only used as a framing protocol we donÆt
consider this framing layer to be included into the G.709 label
space. Rather, we directly use the G.709 digital and optical
transport hierarchies in order to define the corresponding label
spaces.
D.Papadimitriou - Internet Draft û Expires December 2001 2
draft-fontana-ccamp-gmpls-g709-00.txt June 2001
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 | Reserved | G-PID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As mentioned here above, we suggest here to adapt the LSP Encoding
Type and the G-PID (Generalized-PID) to accommodate G.709
recommendation [ITUT-G709].
3.1.1 LSP Encoding Type
Since G.709 defines two networking layers (ODUk layers and OCh
layer), the LSP Encoding Type code-points can reflect these two
layers currently defined in [GMPLS-SIG] as ôDigital Wrapperö and
ôLambdaö code. The LSP Encoding Type is specified per networking
layer or more precisely per group of functional networking layer:
the ODUk layers and the OCh layer.
Therefore, the current ôDigital Wrapperö code defined in [GMPLS-SIG]
can be replaced by two separated code-points:
- code for the G.709 Digital Path layer
- code for the non-standard Digital Wrapper layer
In the same way, two separated code-points can replace the current
defined ôLambdaö code:
- code for the G.709 Optical Channel layer
- code for the non-standard Lambda layer (also referred to as
Lambda layer which includes the pre-OTN Optical Channel layer)
Moreover, the code 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.
D.Papadimitriou - Internet Draft û Expires December 2001 3
draft-fontana-ccamp-gmpls-g709-00.txt June 2001
3.1.2 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 G.709 endpoints of the LSP.
The G-PID can take one of the following values at 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
Therefore, the G-PID values defined in [GMPLS-SIG] are used when the
client payloads are encapsulated through the GFP mapping procedure:
Packets (translated by PoS), Ethernet and ATM Mapping. Noticed that
other G-PID values not defined in [GMPLS-SIG] such as Escon and
Fiber Channel could complete this list in the near future.
In order to include pre-OTN developments, the G-PID at the Optical
Channel Layer can in addition to the G.709 Digital Path Layer (at
2.5 Gbps i.e. ODU1, 10 Gbps i.e. ODU2 and 40 Gbps i.e. ODU3) take
one of the values currently defined in [GMPLS-SIG], in particular:
- SDH: STM-16, STM-64 and STM-256
- Sonet: OC-48, OC-192 and OC-768
- Ethernet: 1 Gbps and 10 Gbps
The following table summarizes the G-PID with respect to the LSP
Encoding Type:
G-PID Type LSP Encoding Type
---------- -----------------
CBRa G.709 Digital Path
CBRb G.709 Digital Path
ATM G.709 Digital Path
BSOT G.709 Digital Path
BSNT G.709 Digital Path
PoS (GFP) G.709 Digital Path
ATM Mapping (GFP) G.709 Digital Path
Ethernet (GFP) G.709 Digital Path, Non-standard Lambda
ODUk G.709 Optical Channel, Non-standard Lambda
SDH G.709 Optical Channel, Non-standard Lambda
SONET G.709 Optical Channel, Non-standard Lambda
D.Papadimitriou - Internet Draft û Expires December 2001 4
draft-fontana-ccamp-gmpls-g709-00.txt June 2001
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 | OOS | RMT | RNC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transparency |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this frame, OOS stands for OTM Overhead Signal, RMT for Requested
Multiplexing Type and RNC for Requested Number of 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 OCh associated to an OTM-x.1
6 OCh associated to an OTM-x.2
7 OCh associated to an OTM-x.3
8 Reserved for future use
The value of the Signal Type field depends on the ôLambdaö code
value (i.e. LSP Encoding Type value):
- if the ôLambda codeö refers to the G.709 Digital Path layer
then the valid values are the ODUk signals (k = 1, 2 or 3)
- if the ôLambda codeö refers to the G.709 Optical Channel layer
then the valid values are the OCh associated to the OTM-x.m
interface signals (x = 0r, nr or n and m = 1, 2 or 3)
- if the ôLambda codeö refers to the Pre-OTN Optical Channel layer
then the valid values are the OCh associated to the pre-OTN
interface (i.e. irrelevant)
D.Papadimitriou - Internet Draft û Expires December 2001 5
draft-fontana-ccamp-gmpls-g709-00.txt June 2001
3.2.2 Requested Multiplexing Type (RMT)
The RMT field (4 bits) indicates the type of multiplexing being
requested for ODUk LSP or OCh LSP. It is set to zero (by default).
The possible values are defined in the following table:
Value Grouping type
----- -------------
0 No multiplexing (default)
1 Flexible multiplexing
2 Inverse multiplexing
3 Reserved for future use
When used at the ODUk layer (i.e. digital path layer), flexible
multiplexing as described in [G709-FRM], refers to the mapping of an
ODU2 into four arbitrary OPU3 tributary slots (i.e. each slot
containing one ODU1) arbitrarily selected to prevent that the
bandwidth gets fragmented. Inverse multiplexing (or ODUk Virtual
Concatenation) currently under definition at ITU-T is also
considered but not used. The RMT field is set to zero (by default)
to indicate an ODUk mapping i.e. neither ODUk flexible multiplexing
nor ODUk inverse multiplexing is requested.
When used at the Optical Channel layer, flexible multiplexing is
reserved for future use while inverse multiplexing means that the
requested composed signal constitutes a waveband (i.e. an optical
channel multiplex). A waveband, denoted as OCh[j.k] (j >= 1) is
defined as a non-contiguous set of identical optical channels j x
OCh, each of them is associated to an OTM-x.m (x = nr or n) sub-
interface signal. The bit rate of each OCh constituting the waveband
(i.e. the composed L-LSP) must be identical, k is unique per OCh
multiplex. By default, the RMT field is set to zero when used at the
Optical Channel layer.
Notice as well, that today both OTN and Pre-OTN specifications do
not define the optical channel multiplex. Therefore, in this
context, any waveband switching development as defined in this
specification is purely vendor specific.
3.2.3 Requested Number of Components (RNC)
The RNC field (16 bits) indicates the number of identical G.709
signals (ODUk or OCh) to be multiplexed, as specified in the RMT
field, for the requested LSP.
This field must be ignored if no multiplexing is requested (RMT = 0)
as per current [ITUT-G709] recommendation. An RMT value different
from 0 must imply a number of components greater than 1.
When applied at the Digital Path layer and requesting flexible
multiplexing (RMT = 1, in particular for ODU2 connections) or
inverse multiplexing (RMT = 2), the RNC field specifies the number
of individual ODUk signals (in this case, RNC = 4 individual ODU1
D.Papadimitriou - Internet Draft û Expires December 2001 6
draft-fontana-ccamp-gmpls-g709-00.txt June 2001
signals) constituting the requested connection. These components are
still processed within the context of a single connection entity.
When applied at the Optical Channel layer and requesting an Optical
Channel multiplex (RMT = 2), the RNC field specifies the number of
individual OCh signals constituting the requested connection. For
instance, a waveband of 3 optical channels (also denoted to as
OCh[3.k]) is requested by setting the RNC field to the value 3.
3.2.4 Reserved Fields
The reserved field (16 bits) is dedicated for future Inverse
Multiplexing (i.e. ODUk virtual multiplexing) purposes in the
current specification. Reserved bits should be set to zero when sent
and must be ignored when received.
3.2.5 OTM Overhead Signal (OOS)
The OOS field (4 bits) indicates whether or not the non-associated
overhead is supported at the G.709 Optical Channel layer. This
feature is irrelevant (OOS = 0) at the G.709 Digital Path layer and
the pre-OTN Optical Channel layer if the latter does not support non
associated overhead. Other values are defined as follows:
Value Type
----- ----
0 irrelevant
1 OOS reduced functionality (limited overhead)
2 OOS full functionality (full overhead)
3 OOS vendor-specific (specific overhead)
The usage of this field is defined as follows:
- With OTM-0r.m and OTM-nr.m interfaces (reduced functionality
stack), OTM Overhead Signal (OOS) is not supported. Therefore
with these types of interface signals, the OOS Field = 1.
- With OTM-n.m interfaces (full functionality stack), the OOS is
supported and mapped into the Optical Supervisory Channel (OSC)
which is multiplexed into the OTM-n.m using wavelength division
multiplexing. With OTM-n.m interfaces, the OOS Field = 2.
- With OTM-n.m interfaces (and eventually OTM-nr.m or even with
OTM-0.m), non-standard OOS can be defined to allow for instance
interoperability with pre-OTN based devices or with any optical
devices which does not support G.709 OOS specification. This
vendor-specific OOS value enables the use of any proprietary
signal monitoring exchange through any kind of supervisory
channel (it can be any kind of IP-based control channel). In
this case, the OOS Field = 3.
D.Papadimitriou - Internet Draft û Expires December 2001 7
draft-fontana-ccamp-gmpls-g709-00.txt June 2001
The OOS field does not restrict the transport mechanism of the OTM
Overhead Signal (OOS) since in-fiber/out-of-band OSC and out-of-
fiber/out-of-band transport mechanisms are allowed.
3.2.6 Transparency
Transparency is only defined for pre-OTN developments since by
definition any signal transported over an OTN is fully transparent.
Thus, this field can only be used when the LSP Encoding Type
explicitly refers to the non-standard lambda layer.
This 32-bits field is a vector of flags indicating the type of
transparency selected when requesting a pre-OTN optical channel.
Several flags can be combined to provide different types of
transparency. Not all combinations are necessarily valid. As it is
commonly the case today with Pre-OTN capable interfaces, three kinds
of transparency levels are currently defined:
- RS/Section and MS/Line overhead termination
- RS/Section overhead termination with MS/Line overhead transparency
- RS/Section overhead and MS/Line overhead transparency (also
referred to as full transparency)
The transparency field is used to request a pre-OTN LSP that
supports the requested transparency, it may also be used to setup
the transparency process to be applied in each intermediate LSR.
The different transparency flags are the following (other
transparency types are left for further study):
- flag 1 (bit 1) : Section/Regenerator Section layer.
- flag 2 (bit 2) : Line/Multiplex Section layer.
Where bit 1 is the low order bit. Others flags are reserved for
further use, they should be set to zero when sent, and must be
ignored when received. A flag is set to one to indicate that the
corresponding transparency is requested. For instance, RS/Section OH
termination with MS/Line OH transparency is requested by setting the
flag 1 = 0 and the flag 2 = 1 while full transparency is requested
by setting the flag 1 = 1 and the flag 2 = 1.
With pre-OTN interfaces terminating RS/Section and MS/Line overhead,
the pre-OTN network must be capable to transport transparently
HOVC/STS-SPE signals. This transparency type is defined as the
default transparency and is specified value by zeroing all flags
(default TOH transparency).
3.2.7 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, RNC, OOS and
Transparency fields to an elementary Signal Type. GMPLS signalling
implies today that all the composed signals must be part of the same
LSP.
D.Papadimitriou - Internet Draft û Expires December 2001 8
draft-fontana-ccamp-gmpls-g709-00.txt June 2001
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.
4. Generalized Label
This section describes the Generalized Label space for the Digital
Path and the Optical Channel Layer.
4.1 Digital Path Layer
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 must support the sub-levels of ODUk flexible
multiplexing (or simply ODUk multiplexing):
- ODU2 multiplexing:
. The mapping of an ODU2 into four arbitrary OPU3 tributary
slots selected arbitrarily (i.e. each slot containing one
ODU1)
- ODU3 multiplexing:
. Not applicable today since higher order OPU tributary slots
are not defined in the current [ITUT-G709] recommendation
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:
- k1: indicates a particular ODU1 in one ODU2 (k1 = 1,..,4), ODU3
(k1 = 5,..,20); k1 values from 21 to 84 are reserved for
future use
- k2: indicates a particular ODU2 in one ODU3 (k2 = 1,..,4); k2
values from 5 to 20 are reserved for future use
- k3: k3 values (k3 = 1,..,4) are reserved for future use
If k1, k2 and k3 values are equal to zero, the corresponding ODUk
are not structured, i.e. k[i]=0 (i = 1, 2, 3) indicates that the
ODU[i] is not structured and the ODU[i] is simply mapped into the
OTU[i] as described in Section 4.4 of [G709-FRM].
D.Papadimitriou - Internet Draft û Expires December 2001 9
draft-fontana-ccamp-gmpls-g709-00.txt June 2001
Since k3 usage is not yet fully specified, k3 value always equals
zero, k2 valid interval is [0,4] and k1 valid interval is [0,20].
Thus, when used in a G.709 Generalized Label:
- k1: indicates a particular ODU1 in one ODU2 (k1 = 1,..,4) or in
one ODU3 (k1 = 5,..,20)
- k2: indicates a particular ODU2 in one ODU3 (k2 = 1,..,4)
If k1 and k2 values are equal to zero means non-significant: a
particular ODUk is not structured, i.e. ki=0 indicates that the ODUi
in not structured.
Examples:
- k2=0, k1=0 indicates a full ODU3 (full 40 Gbps).
- k2=0, k1=3 indicates the third unstructured ODU1 in the ODU2.
- k2=2, k1=0 indicates the second unstructured ODU2 in the ODU3.
- k2=0, k1=8 indicates the fourth unstructured ODU1 in the ODU3.
- k2=4, k1=2 indicates the second ODU1 of the fourth ODU2 in the
ODU3.
4.2 Optical Channel layer
At the Optical Channel layer, the label space should be consistently
defined as a flat space whose values reflect the local assignment of
OCh identifiers corresponding to the OTM-x.m sub-interface signals
(m = 1, 2 or 3 and x = 0r, nr or n).
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.
5. Applications
1. When one ODU1 (ODU2 or ODU3) non-structured signal is transported
into one OTU1 (OTU2 or OTU3) payload, the upstream node requests in
a non-structured ODU1 (ODU2 or ODU3) signal. 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).
When a single ODUk signal is requested (Signal Type = 1, 2 or 3 and
RMT = 0), the downstream node has to return a single ODUk label. It
could be one of the following when the Signal Type = 1:
- k2=0, k1=0 indicating a single unstructured ODU1
- k2=0, k1=3 indicating the third unstructured ODU1 in the ODU2
- k2=0, k1=6 indicating the second unstructured ODU1 in the ODU3
- k2=2, k1=3 indicating the third unstructured ODU1 of the second
ODU2 in the ODU3
2. When one ODU2 signal is transported into an ODU3 payload, which
is sub-divided into 16 ODU1 tributary slots, the ODU tributary slots
D.Papadimitriou - Internet Draft û Expires December 2001 10
draft-fontana-ccamp-gmpls-g709-00.txt June 2001
(here, denoted A, B, C and D with A < B < C < D) can be arbitrary
selected. For instance, one ODU2 can be transported in ODU1
tributary slots 5, 12, 13 and 18. Therefore, when the upstream node
requests in such conditions a multiplexed ODU2 signal (Signal Type =
2, RMT = 1 and RNC = 4), the downstream node returns four ODUk
labels:
- First label: k1=5, k2=0 (first ODU1)
- Second label: k1=12, k2=0 (second ODU1)
- Third label: k1=13, k2=0 (third ODU1)
- Fourth label: k1=18, k2=0 (fourth ODU1)
3. When a single OCh signal of 40Gbps is requested (Signal Type = 7
and RMT = 0), the downstream node must return a single wavelength
label.
4. When a composed OCh[4.2] signal is requested i.e. a waveband or
optical channel multiplex composed by four bit-rate identical OCh
signal of 10Gbps (Signal Type = 6, RMT = 2 and RNC = 4), the
downstream node has to return four distinct wavelength labels to the
requesting upstream node since the optical channels composing the
multiplex are not necessarily contiguously multiplexed.
5. When requesting multiple LSP (i.e. multiplier MT > 1), more than
one label is returned to the requestor node. For instance, when the
downstream node receives a request for a 4 x ODU1 signal (Signal
Type = 1, RMT = 0 and MT = 4), it returns 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 same LSP, etc. For instance, since ODU1 are non-
contiguously multiplexed into one ODU3 such that corresponding
labels are attributed independently:
- First label: k1=5, k2=0 (first ODU1)
- Second label: k1=8, k2=0 (second ODU1)
- Third label: k1=18, k2=0 (third ODU1)
- Fourth label: k1=19, k2=0 (fourth ODU1)
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
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
D.Papadimitriou - Internet Draft û Expires December 2001 11
draft-fontana-ccamp-gmpls-g709-00.txt June 2001
Default General Characterization Parameters and Guaranteed Service
fragment is used, see [RFC-2210].
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 by receiver 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
Security considerations for OTN networks are not defined in this
document.
8. References
1. [ITUT-G707] æNetwork node interface for the synchronous digital
hierarchy (SDH)Æ, ITU-T Recommendation, March 1996.
2. [ITUT-G709] æInterface for the Optical Transport Network (OTN)Æ,
ITU-T draft version, February 2001.
3. [ITUT-G872] æArchitecture of Optical Transport NetworkÆ, ITU-T
draft version, February 2001.
4. [ITUT-G962] æOptical interfaces for multi-channel systems with
optical amplifiersÆ, ITU-T Recommendation, October 1998.
5. [ITUT-GASTN] æAutomated Switched Transport NetworkÆ, ITU-T draft
version, February 2001.
6. [GMPLS-ARCH] E. Mannie et al., æGeneralized Multi-Protocol Label
Switching (GMPLS) ArchitectureÆ, Internet Draft, Work in progress,
draft-many-gmpls-architecture-00.txt, February 2001.
7. [GMPLS-LDP] P. Ashwood-Smith et al., æGeneralized MPLS Signaling -
CR-LDP ExtensionsÆ, Internet Draft, Work in progress, draft-ietf-
mpls-generalized-cr-ldp-03.txt, May 2001.
D.Papadimitriou - Internet Draft û Expires December 2001 12
draft-fontana-ccamp-gmpls-g709-00.txt June 2001
8. [GMPLS-RSVP] P. Ashwood-Smith et al., æGeneralized MPLS Signaling
- RSVP-TE ExtensionsÆ, Internet Draft, draft-ietf-mpls-generalized-
rsvp-te-03.txt, May 2001.
9. [GMPLS-SIG] P. Ashwood-Smith et al., æGeneralized MPLS - Signaling
Functional DescriptionÆ, Internet Draft, Work in progress, draft-
ietf-mpls-generalized-signaling-04.txt, May 2001.
10. [GMPLS-SSS] S. Ansorge et al., æGeneralized MPLS û SDH/Sonet
SpecificsÆ, Internet Draft, Work in progress, draft-ietf-ccamp-gmpls-
sonet-sdh-00.txt, May 2001.
11. [G709-FRM] A. Bellato et al., æG.709 Optical Transport Networks
GMPLS Control FrameworkÆ, Internet Draft, Work in progress, draft-
bellato-ccamp-gmpls-control-g709-00.txt, June 2001.
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
Michele Fontana
Alcatel TND-Vimercate
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7053
Email: michele.fontana@netit.alcatel.it
Germano Gasparini
Alcatel TND-Vimercate
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7670
Email: germano.gasparini@netit.alcatel.it
Alberto Bellato
Alcatel TND-Vimercate
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7215
Email: alberto.bellato@netit.alcatel.it
Gert Grammel
Alcatel TND-Vimercate
Via Trento 30,
I-20059 Vimercate, Italy
D.Papadimitriou - Internet Draft û Expires December 2001 13
draft-fontana-ccamp-gmpls-g709-00.txt June 2001
Phone: +39 039 686-7060
Email: gert.grammel@netit.alcatel.it
Jim Jones
Alcatel TND-USA
3400 W. Plano Parkway,
Plano, TX 75075, USA
Phone: +1 972 519-2744
Email: Jim.D.Jones1@usa.alcatel.com
Dimitri Papadimitriou (Editor)
Senior R&D Engineer û Optical Networking
Alcatel IPO-NSG
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel.be
Eric Mannie
EBone (GTS)
Terhulpsesteenweg, 6A
1560 Hoeilaart, Belgium
Phone: +32 2 658-5652
Email: eric.mannie@gts.com
Zhi-Wei Lin
Lucent Technologies
101 Crawfords Corner Rd, Rm 3C-512
Holmdel, New Jersey 07733-3030, USA
Tel: +1 732 949-5141
Email: zwlin@lucent.com
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
D.Papadimitriou - Internet Draft û Expires December 2001 14
draft-fontana-ccamp-gmpls-g709-00.txt June 2001
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
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
D.Papadimitriou - Internet Draft û Expires December 2001 15
draft-fontana-ccamp-gmpls-g709-00.txt June 2001
- 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 - Internet Draft û Expires December 2001 16
draft-fontana-ccamp-gmpls-g709-00.txt June 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 - Internet Draft û Expires December 2001 17