CCAMP Working Group D. Papadimitriou - Editor
Category: Internet Draft Alcatel
Expiration Date: May 2003
November 2002
Generalized MPLS Signalling Extensions
for G.709 Optical Transport Networks Control
draft-ietf-ccamp-gmpls-g709-03.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document is a companion to the Generalized MPLS (GMPLS)
signalling documents. It describes the technology specific
information needed to extend GMPLS signalling to control Optical
Transport Networks (OTN); it also includes the so-called pre-OTN
developments.
*** DISCLAIMER ***
In this document, the presented views on ITU-T G.709 OTN
Recommendation (and referenced) are intentionally restricted as
needed from the GMPLS perspective within the IETF CCAMP WG context.
Hence, the objective of this document is not to replicate the
content of the ITU-T OTN recommendations. Therefore, the reader
interested in going into more details concerning the corresponding
technologies is strongly invited to consult the corresponding ITU-
T documents (also referenced in this memo).
D.Papadimitriou et al. - Internet Draft û Expires May 2003 1
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
Table of Content
Status of this Memo 1
Abstract 1
Table of Content 2
1. Introduction 2
2. GMPLS Extensions for G.709 û Overview 3
3. Generalized Label Request 4
3.1 Technology Independent Part 4
3.1.1. LSP Encoding Type 4
3.1.2. Switching-Type 5
3.1.3. Generalized-PID (G-PID) 5
3.2. G.709 Traffic-Parameters 7
3.2.1. Signal Type (ST) 7
3.2.2. Number of Multiplexed Components (NMC) 8
3.2.3. Number of Virtual Components (NVC) 8
3.2.4. Multiplier (MT) 9
3.2.5. Reserved Fields 9
4. Generalized Label 9
4.1. ODUk Label Space 9
4.2. Label Distribution Rules 11
4.3. OCh Label Space 12
5. Examples 12
6. Signalling Protocol Extensions 13
6.1. RSVP-TE Details 13
6.2. CR-LDP Details 14
7. Security Considerations 15
8. IANA Considerations 15
9. Acknowledgments 15
10. Intellectual Property Notice 15
11. References 16
11.1 Normative References 16
12. Contributors 17
13. AuthorÆs Address 18
Appendix 1 û Abbreviations 19
Appendix 2 û G.709 Indexes 19
Full Copyright Statement 21
Conventions used in this document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119.
In addition, the reader is assumed to be familiar with the
terminology used in ITU-T [ITUT-G709] as well as [GMPLS-SIG],
[GMPLS-RSVP] and [GMPLS-LDP]. Abbreviations used in this document
are also detailed in Appendix 1.
Changes from v02.txt to v03.txt:
Editorial and text clarifications
Add G-PID values for ESCON and FICON
D.Papadimitriou et al. - Internet Draft û Expires May 2003 2
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
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) Capable. A
functional description of the extensions to MPLS signaling needed
to support these 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] (and referenced documents),
including pre-OTN developments. Per [GMPLS-SIG], G.709 specific
parameters are carried through the signaling protocol in traffic
parameter specific objects.
The G.709 traffic parameters defined hereafter (see Section 3.2)
MUST be used when the label is encoded as defined in this
document. Moreover, the label MUST be encoded as defined in
Section 4 when these G.709 traffic parameters are used.
Note: in the context of this memo, by pre-OTN developments, one
refers to Optical Channel, Digital Wrapper and Forward Error
Correction (FEC) solutions that are not fully G.709 compliant.
Details concerning pre-OTN SONET/SDH based solutions including
Optical Sections (OS), Regenerator Section (RS)/Section and
Multiplex Section (MS)/ Line overhead transparency are covered in
[GMPLS-SONET-SDH].
2. GMPLS Extensions for G.709 - Overview
Although G.709 defines several networking layers (OTS, OMS, OPS,
OCh, OChr constituting the optical transport hierarchy and OTUk,
ODUk constituting the digital transport hierarchy) only the OCh
(Optical Channel) and the ODUk (Optical Channel Data Unit) layers
are defined as switching layers. Both OCh (but not OChr) and ODUk
layers include the overhead for supervision and management. The OCh
overhead is transported in a non-associated manner (so also referred
to as the non-associated overhead û naOH) in the OTM Overhead Signal
(OOS), together with the OTS and OMS non-associated overhead. The
OOS is transported via a dedicated wavelength referred to as the
Optical Supervisory Channel (OSC). It should be noticed that the
naOH is only functionally specified and as such open to vendor
specific solutions. The ODUk overhead is transported in an
associated manner as part of the digital ODUk frame.
As described in [ITUT-G709], in addition to the support of ODUk
mapping into OTUk (k = 1, 2, 3), [ITUT-G.709] supports ODUk
D.Papadimitriou et al. - Internet Draft û Expires May 2003 3
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
multiplexing. It refers to the multiplexing of ODUj (j = 1, 2) into
an ODUk (k > j) signal, in particular:
- ODU1 into ODU2 multiplexing
- ODU1 into ODU3 multiplexing
- ODU2 into ODU3 multiplexing
- ODU1 and ODU2 into ODU3 multiplexing
Therefore, adapting GMPLS to control G.709 OTN, can be achieved by
considering that:
- a Digital Path layer by extending the previously defined
ôDigital Wrapperö in [GMPLS-SIG] corresponding to the ODUk
(digital) path layer.
- an Optical Path layer by extending the ôLambdaö concept defined
in [GMPLS-SIG] to the OCh (optical) path layer.
- a label space structure by considering a tree whose root is an
OTUk signal and leaves the ODUj signals (k >= j); enabling to
identify the exact position of a particular ODUj signal in an
ODUk multiplexing structure.
Thus, GMPLS extensions for G.709 need to cover the Generalized Label
Request, the Generalized Label as well as the specific technology
dependent objects included in the so-called traffic parameters as
specified in [GMPLS-SONET-SDH] for SONET/SDH networks. Moreover,
since the multiplexing in the digital domain (such as ODUk
multiplexing) has been considered in the amended version of the
G.709 recommendation (October 2001), this document also proposes a
label space definition suitable for that purpose. Notice also that
one directly uses the G.709 ODUk (i.e. Digital Path) and OCh (i.e.
Optical Path) layers in order to define the corresponding label
spaces.
3. Generalized Label Request
The Generalized Label Request as defined in [GMPLS-SIG], includes a
technology independent part and a technology dependent part (i.e.
the traffic parameters). In this section, both parts are extended to
accommodate the GMPLS Signalling to the G.709 transport plane
recommendation (see [ITUT-G709]).
3.1 Technology Independent Part
As defined in [GMPLS-SIG], the LSP Encoding Type, the Switching Type
and the Generalized Protocol Identifier (Generalized-PID) constitute
the technology independent part of the Generalized Label Request.
The encoding of the corresponding RSVP-TE object and CR-LDP TLV is
specified in [GMPLS-RSVP] Section 2.1 and [GMPLS-LDP] Section 2.1,
respectively.
As mentioned here above, this document extends the LSP Encoding
Type, Switching Type and G-PID (Generalized-PID) values to
accommodate G.709 recommendation [ITUT-G709].
3.1.1 LSP Encoding Type
D.Papadimitriou et al. - Internet Draft û Expires May 2003 4
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
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-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, the following additional code-points for the LSP
Encoding Type are defined:
Value Type
----- ----
12 G.709 ODUk (Digital Path)
13 G.709 Optical Channel
Moreover, the code-point for the G.709 Optical Channel (OCh) layer
will indicate the capability of an end-system to use the G.709 non-
associated overhead (naOH) i.e. the OTM Overhead Signal (OOS)
multiplexed into the OTM-n.m interface signal.
3.1.2 Switching Type
The Switching Type indicates the type of switching that should be
performed at the termination of a particular link. This field is
only needed for links that advertise more than one type of switching
capability (see [GMPLS-RTG]).
Here, no additional values are to be considered in order to
accommodate G.709 switching types since an ODUk switching (and so
LSPs) belongs to the TDM class while an OCh switching (and so LSPs)
to the Lambda class (i.e. LSC).
Moreover, in a strict layered G.709 network, when a downstream node
receives a Generalized Label Request including one of these values
for the Switching Type field, this value SHOULD be ignored.
3.1.3 Generalized-PID (G-PID)
D.Papadimitriou et al. - Internet Draft û Expires May 2003 5
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
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.
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 [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 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 [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
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.
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
following client payloads are transported over a so-called lambda:
- Gigabit Ethernet (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)
D.Papadimitriou et al. - Internet Draft û Expires May 2003 6
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
55 Ethernet PHY (transparent GFP) G.709 ODUk (and SDH)
56 ESCON G.709 ODUk, Lambda, Fiber
57 FICON G.709 ODUk, Lambda, Fiber
Note: Value 49 and 50 includes mapping of SDH
The following table summarizes the update of the G-PID values
defined in [GMPLS-SIG]:
Value G-PID Type LSP Encoding Type
----- ---------- -----------------
32 ATM Mapping SDH, G.709 ODUk
33 Ethernet PHY SDH, G.709 OCh, Lambda, Fiber
34 Sonet/SDH G.709 OCh, Lambda, Fiber
35 Reserved (SONET Dep.) G.709 OCh, Lambda, Fiber
3.2 G.709 Traffic-Parameters
When G.709 Digital Path Layer or G.709 Optical Channel Layer is
specified in the LSP Encoding Type field, the information referred
to as technology dependent information (or simply traffic-
parameters) is carried additionally to the one included in the
Generalized Label Request and is defined as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Signal Type | Reserved | NMC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this frame, NMC stands for Number of Multiplexed Components, NVC
for Number of Virtual Components and MT for Multiplier. Each of
these fields is tailored to support G.709 LSP requests.
3.2.1 Signal Type (ST)
This field (8 bits) indicates the type of G.709 Elementary Signal
that comprises the requested LSP. The permitted values are:
Value Type
----- ----
0 Irrelevant
1 ODU1 (i.e. 2.5 Gbps)
2 ODU2 (i.e. 10 Gbps)
3 ODU3 (i.e. 40 Gbps)
4 Reserved
5 Reserved
6 OCh at 2.5 Gbps
7 OCh at 10 Gbps
D.Papadimitriou et al. - Internet Draft û Expires May 2003 7
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
8 OCh at 40 Gbps
9-255 Reserved
The value of the Signal Type field depends on LSP Encoding Type
value defined in Section 3.1.1 and [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
- if the LSP Encoding Type is ôLambdaö (which includes the
pre-OTN Optical Channel layer) then the valid value is irrelevant
(Signal Type = 0)
- if the LSP Encoding Type is ôDigital Wrapperö, then the valid
value is irrelevant (Signal Type = 0)
Several transforms can be sequentially applied on the Elementary
Signal to build the Final Signal being actually requested for the
LSP. Each transform application is optional and MUST be ignored if
zero, except the Multiplier (MT) that cannot be zero and MUST be
ignored if equal to one. Transforms MUST be applied strictly in the
following order:
- First, virtual concatenation (by using the NVC field) can
be optionally applied directly on the Elementary Signal to form a
Composed Signal
- Second, a multiplication (by using the Multiplier field) can be
optionally applied either directly on the Elementary Signal, or
on the virtually concatenated signal obtained from the first
phase. The resulting signal is referred to as Final Signal.
3.2.2 Number of Multiplexed Components (NMC)
The NMC field (16 bits) indicates the number of ODU tributary slots
used by an ODUj when multiplexed into an ODUk (k > j) for the
requested LSP. This field is not applicable when an ODUk is mapped
into an OTUk and irrelevant at the Optical Channel layer. In both
cases, it MUST be set to zero (NMC = 0) when sent and should be
ignored when received.
When applied at the Digital Path layer, in particular for ODU2
connections multiplexed into one ODU3 payload, the NMC field
specifies the number of individual tributary slots (NMC = 4)
constituting the requested connection. These components are still
processed within the context of a single connection entity. For all
other currently defined multiplexing cases (see Section 2), the NMC
field is set to 1.
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.
D.Papadimitriou et al. - Internet Draft û Expires May 2003 8
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
This field is set to 0 (default value) to indicate that no virtual
concatenation is requested.
Note that the current usage of this field only applies for G.709
ODUk LSP i.e. values greater than zero are only acceptable for ODUk
Signal Types. Therefore, it MUST be set to zero (NVC = 0) when
requesting a G.709 OCh LSP and should be ignored when received.
3.2.4 Multiplier (MT)
The Multiplier field (16 bits) indicates the number of identical
Elementary Signals or Composed Signals requested for the LSP i.e.
that form the Final Signal. A Composed Signal is the resulting
signal from the application of the NMC and NVC fields to an
elementary Signal Type. GMPLS signalling currently implies that all
the Composed Signals must be part of the same LSP.
This field is set to one (default value) to indicate that exactly
one instance of a signal is being requested. Intermediate and egress
nodes MUST verify that the node itself and the interfaces on which
the LSP will be established can support the requested multiplier
value. If the requested values can not be supported, the receiver
node MUST generate a PathErr/NOTIFICATION message (see Section
6.1/6.2, respectively).
Zero is an invalid value. If received, the node MUST generate a
PathErr/NOTIFICATION message (see Section 6.1/6.2, respectively).
3.2.5 Reserved Fields
The reserved fields (8 bits in row 1 and 32 bits fields in row 3)
are dedicated for future use. Reserved bits SHOULD be set to zero
when sent and MUST be ignored when received.
4. Generalized Label
This section describes the Generalized Label value space for Digital
Paths and Optical Channels. The Generalized Label is defined in
[GMPLS-SIG]. The format of the corresponding RSVP-TE object and CR-
LDP TLV is specified in [GMPLS-RSVP] Section 2.2 and [GMPLS-LDP]
Section 2.2, respectively.
The label distribution rules detailed in Section 4.2, follow when
applicable the ones defined in [GMPLS-SONET-SDH].
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).
D.Papadimitriou et al. - Internet Draft û Expires May 2003 9
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
In addition to the support of ODUk mapping into OTUk, the G.709
label space supports the sub-levels of ODUk multiplexing. ODUk
multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk
(k > j), in particular:
- ODU1 into ODU2 multiplexing
- ODU1 into ODU3 multiplexing
- ODU2 into ODU3 multiplexing
- ODU1 and ODU2 into ODU3 multiplexing
More precisely, ODUj into ODUk multiplexing (k > j) is defined when
an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an
ODTUG constituted by ODU tributary slots) which is mapped into an
OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is
mapped into an OTUk.
Therefore, the label space structure is a tree whose root is an OTUk
signal and leaves the ODUj signals (k >= j) that can be transported
via the tributary slots and switched between these slots. A G.709
Digital Path layer label identifies the exact position of a
particular ODUj signal in an ODUk multiplexing structure.
The G.709 Digital Path Layer label or ODUk label has the following
format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | t3 | t2 |t1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The specification of the three fields t1, t2 and t3 self-
consistently characterizes the ODUk label space. The value space of
the t1, t2 and t3 fields is defined as follows:
1. t1 (1-bit):
- t1=1 indicates an ODU1 signal.
- t1 is not significant for the other ODUk signal types (t1=0).
2. t2 (3-bit):
- t2=1 indicates a not further sub-divided ODU2 signal.
- t2=2->5 indicates the tributary slot (t2th-2) used by the
ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2).
- t2 is not significant for an ODU3 (t2=0).
3. t3 (6-bit):
- t3=1 indicates a not further sub-divided ODU3 signal.
- t3=2->17 indicates the tributary slot (t3th-1) used by the
ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3).
- t3=18->33 indicates the tributary slot (t3th-17) used by the
ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3).
D.Papadimitriou et al. - Internet Draft û Expires May 2003 10
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required
to identify the 4 tributary slots used by the ODU2; these tributary
time slots have to be allocated in ascending order.
If the label sub-field value t[i]=1 (i, j = 1, 2 or 3) and t[j]=0 (j
> i), the corresponding ODUk signal ODU[i] is directly mapped into
the corresponding OTUk signal (k=i). This is referred to as the
mapping of an ODUk signal into an OTUk of the same order. Therefore,
the numbering starts at 1; zero is used to indicate a non-
significant field. A label field equal to zero is an invalid value.
Examples:
- t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1
- t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2
- t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3
- t3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot
of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2
- t3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot
of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3
4.2 Label Distribution Rules
In case of ODUk in OTUk mapping, only one of label can appear in the
Generalized Label.
In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered
list of the labels in the multiplex is given (this list can be
restricted to only one label when NMC = 1). Each label indicates a
component (ODUj tributary slot) of the multiplexed signal. The order
of the labels must reflect the order of the ODUj into the multiplex
(not the physical order of tributary slots).
In case of ODUk virtual concatenation, the explicit ordered list of
all labels in the concatenation is given. Each label indicates a
component of the virtually concatenated signal. The order of the
labels must reflect the order of the ODUk to concatenate (not the
physical order of time-slots). This representation limits virtual
concatenation to remain within a single (component) link. In case of
multiplexed virtually concatenated signals, the first set of labels
indicates the components (ODUj tributary slots) of the first
virtually concatenated signal, the second set of labels indicates
the components (ODUj tributary slots) of the second virtually
concatenated signal, and so on.
In case of multiplication (i.e. when using the MT field), the
explicit ordered list of all labels taking part in the composed
signal is given. The above representation limits multiplication to
remain within a single (component) link. In case of multiplication
of multiplexed/virtually concatenated signals, the first set of
labels indicates the components of the first multiplexed/virtually
concatenated signal, the second set of labels indicates components
of the second multiplexed/virtually concatenated signal, and so on.
D.Papadimitriou et al. - Internet Draft û Expires May 2003 11
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
Note: As defined in [GMPLS-SIG], label field values only have
significance between two neighbors, and the receiver may need (in
some particular cases) to convert the received value into a value
that has local significance.
4.3 Optical Channel Label Space
At the Optical Channel layer, the label space must be consistently
defined as a flat space whose values reflect the local assignment of
OCh identifiers corresponding to the OTM-n.m sub-interface signals
(m = 1, 2 or 3). Note that these identifiers do not cover OChr since
the corresponding Connection Function (OChr-CF) between OTM-
nr.m/OTM-0r.m is not defined in [ITUT-G798].
The OCh label space values are defined by either absolute values
(i.e. channel identifiers or Channel ID also referred to as
wavelength identifiers) or relative values (channel spacing also
referred to as inter-wavelength spacing). The latter is strictly
confined to a per-port label space while the former could be defined
as a local or a global (per node) label space. Such an OCh label
space is applicable to both OTN Optical Channel layer and pre-OTN
Optical Channel layer.
Optical Channel label encoding (and distribution) rules are defined
in [GMPSL-SIG]. They MUST be used for the Upstream Label, the
Suggested Label and the Generalized Label.
5. Examples
The following examples are given in order to illustrate the
processing described in the previous sections of this document.
1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is
directly transported in an OTU1 (OTU2 or OTU3), the upstream node
requests results simply in an ODU1 (ODU2 or ODU3) signal request.
In such conditions, the downstream node has to return a unique
label since the ODU1 (ODU2 or ODU3) is directly mapped into the
corresponding OTU1 (OTU2 or OTU3). Since a single ODUk signal is
requested (Signal Type = 1, 2 or 3), the downstream node has to
return a single ODUk label which can be for instance one of the
following when the Signal Type = 1:
- t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1
- t3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2
- t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3
2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed
into the payload of a structured ODU2 (or ODU3), the upstream
node requests results simply in a ODU1 signal request.
In such conditions, the downstream node has to return a unique
label since the ODU1 is multiplexed into one ODTUG2 (or ODTUG3).
D.Papadimitriou et al. - Internet Draft û Expires May 2003 12
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or
OPU3) and then mapped into the corresponding OTU2 (or OTU3).
Since a single ODU1 multiplexed signal is requested (Signal Type
= 1 and NMC = 1), the downstream node has to return a single ODU1
label which can take for instance one of the following values:
- t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2
- t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3
- t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3
3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is
multiplexed into the payload of a structured ODU3, the upstream
node requests results simply in a ODU2 signal request.
In such conditions, the downstream node has to return four labels
since the ODU2 is multiplexed into one ODTUG3. The latter is
mapped into an ODU3 (via OPU3) and then mapped into an OTU3.
Since an ODU2 multiplexed signal is requested (Signal Type = 2,
and NMC = 4), the downstream node has to return four ODU labels
which can take for instance the following values:
- t3=18, t2=0, t1=0 (first part of ODU2 in first TS of ODTUG3)
- t3=22, t2=0, t1=0 (second part of ODU2 in fifth TS of ODTUG3)
- t3=23, t2=0, t1=0 (third part of ODU2 in sixth TS of ODTUG3)
- t3=26, t2=0, t1=0 (fourth part of ODU2 in ninth TS of ODTUG3)
4. When a single OCh signal of 40 Gbps is requested (Signal Type =
8), the downstream node must return a single wavelength
label as specified in [GMPLS-SIG].
5. When requesting multiple ODUk LSP (i.e. with a multiplier (MT)
value > 1), an explicit list of labels is returned to the
requestor node.
When the downstream node receives a request for a 4 x ODU1 signal
(Signal Type = 1, NMC = 1 and MT = 4) multiplexed into a ODU3, it
returns an ordered list of four labels to the upstream node: the
first ODU1 label corresponding to the first signal of the LSP,
the second ODU1 label corresponding to the second signal of the
LSP, etc. For instance, the corresponding labels can take the
following values:
- First ODU1: t3=2, t2=0, t1=0 (in first TS of ODTUG3)
- Second ODU1: t3=10, t2=0, t1=0 (in ninth TS of ODTUG3)
- Third ODU1: t3=7, t2=0, t1=0 (in sixth TS of ODTUG3)
- Fourth ODU1: t3=6, t2=0, t1=0 (in fifth TS of ODTUG3)
6. Signalling Protocol Extensions
This section specifies the [GMPLS-RSVP] and [GMPLS-LDP] protocol
extensions needed to accommodate G.709 traffic parameters.
6.1 RSVP-TE Details
D.Papadimitriou et al. - Internet Draft û Expires May 2003 13
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
For RSVP-TE, the G.709 traffic parameters are carried in the G.709
SENDER_TSPEC and FLOWSPEC objects. The same format is used both
for SENDER_TSPEC object and FLOWSPEC objects. The content of the
objects is defined above in Section 3.2. The objects have the
following class and type for G.709:
- G.709 SENDER_TSPEC Object: Class = 12, C-Type = TBA
- G.709 FLOWSPEC Object: Class = 9, C-Type = TBA
There is no Adspec associated with the SONET/SDH SENDER_TSPEC.
Either the Adspec is omitted or an Int-serv Adspec with the
Default General Characterization Parameters and Guaranteed Service
fragment is used, see [RFC2210].
For a particular sender in a session the contents of the FLOWSPEC
object received in a Resv message SHOULD be identical to the
contents of the SENDER_TSPEC object received in the corresponding
Path message. If the objects do not match, a ResvErr message with
a "Traffic Control Error/Bad Flowspec value" error SHOULD be
generated.
Intermediate and egress nodes MUST verify that the node itself and
the interfaces on which the LSP will be established can support
the requested Signal Type, NMC and NVC values (as defined in
Section 3.2). If the requested value(s) can not be supported, the
receiver node MUST generate a PathErr message with a "Traffic
Control Error/ Service unsupported" indication (see [RFC2205]).
In addition, if the MT field is received with a zero value, the
node MUST generate a PathErr message with a "Traffic Control
Error/Bad Tspec value" indication (see [RFC2205]).
6.2 CR-LDP Details
For CR-LDP, the G.709 traffic parameters are carried in the G.709
Traffic Parameters TLV. The content of the TLV is defined in
Section 3.2. The header of the TLV has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type field indicates G.709 traffic parameters: 0xTBA
Intermediate and egress nodes MUST verify that the node itself and
the interfaces on which the LSP will be established can support
the requested Signal Type, NMC and NVC values (as defined in
Section 3.2). If the requested value(s) can not be supported, the
receiver node MUST generate a NOTIFICATION message with a
"Resource Unavailable" status code (see [RFC3212]).
D.Papadimitriou et al. - Internet Draft û Expires May 2003 14
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
In addition, if the MT field is received with a zero value, the
node MUST generate a NOTIFICATION message with a "Resource
Unavailable" status code (see [RFC3212]).
7. Security Considerations
This draft introduces no new security considerations to either
[GMPLS-RSVP] or [GMPLS-LDP]. GMPLS security is described in
section 11 of [GMPLS-SIG], in [RFC-3212] and in [RFC-3209].
8. IANA Considerations
IANA assigns values to RSVP-TE objects (see [RFC-3209]) and CR-LDP
(see [RFC-3212]).
Two C-Type values have to be assigned by IANA for the following
RSVP objects:
- G.709 SENDER_TSPEC object: Class = 12, C-Type = TBA (see Section
6.1).
- G.709 FLOWSPEC object: Class = 9, C-Type = TBA (see Section
6.1).
This draft also uses the LDP [RFC 3031] name spaces, which require
assignment of the Type field for the following TLV:
- G.709 Traffic Parameters TLV (see section 6.2).
9. Acknowledgments
The authors would like to thank Jean-Loup Ferrant, Mathieu Garnot,
Massimo Canali, Germano Gasparini and Fong Liaw for their
constructive comments and inputs as well as James Fu, Siva
Sankaranarayanan and Yangguang Xu for their useful feedback.
This draft incorporates (upon agreement) material and ideas from
draft-lin-ccamp-ipo-common-label-request-00.txt.
10. Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
D.Papadimitriou et al. - Internet Draft û Expires May 2003 15
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
11. References
11.1 Normative References
[ITUT-G707] ITU-T G.707 Recommendation, æNetwork node interface for
the synchronous digital hierarchy (SDH)Æ, ITU-T,
October 2000.
[ITUT-G709] ITU-T G.709 Recommendation, version 1.0 (and Amendment
1), æInterface for the Optical Transport Network
(OTN)Æ, ITU-T, February 2001 (and October 2001).
[ITUT-G798] ITU-T G.798 Recommendation, version 1.0,
æCharacteristics of Optical Transport Network Hierarchy
Equipment Functional BlocksÆ, ITU-T, October 2001.
[ITUT-G872] ITU-T G.872 Recommendation, version 2.0, æArchitecture
of Optical Transport NetworkÆ, ITU-T, October 2001.
[GMPLS-ARCH] E.Mannie (Editor) et al., æGeneralized Multi-Protocol
Label Switching (GMPLS) ArchitectureÆ, Internet Draft,
Work in progress, draft-ietf-ccamp-gmpls-architecture-
03.txt, August 2002.
[GMPLS-LDP] L.Berger (Editor) et al., æGeneralized MPLS Signaling -
CR-LDP ExtensionsÆ, Internet Draft, Work in progress,
draft-ietf-mpls-generalized-cr-ldp-07.txt, August 2002.
[GMPLS-RSVP] L.Berger (Editor) et al., æGeneralized MPLS Signaling -
RSVP-TE ExtensionsÆ, Internet Draft, Work in progress,
draft-ietf-mpls-generalized-rsvp-te-09.txt, October
2002.
[GMPLS-RTG] K.Kompella et al., æRouting Extensions in Support of
Generalized MPLSÆ, Internet Draft, Work in Progress,
draft-ietf-ccamp-gmpls-routing-05.txt, September 2002.
[GMPLS-SIG] L.Berger (Editor) et al., æGeneralized MPLS
- Signaling Functional DescriptionÆ, Internet Draft,
Work in progress, draft-ietf-mpls-generalized-
signaling-09.txt, August 2002.
[GMPLS-SONET-SDH] E.Mannie and D.Papadimitriou (Editors) et al.,
æGeneralized Multiprotocol Label Switching Extensions
for SONET and SDH ControlÆ, Internet Draft, Work in
progress, draft-ietf-ccamp-gmpls-sonet-sdh-07.txt,
October 2002.
D.Papadimitriou et al. - Internet Draft û Expires May 2003 16
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
[RFC-2119] S.Bradner, "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
[RFC-2205] R.Braden et al., "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC-2210] J.Wroclawski, æThe Use of RSVP with IETF Integrated
ServicesÆ, Internet RFC 2210, IETF Standard Track,
September 1997.
[RFC-3036] L.Andersson et al., æLDP SpecificationÆ, Internet RFC
3036, IETF Proposed Standard, January 2001.
[RFC-3209] D.Awduche et al., æRSVP-TE: Extensions to RSVP for LSP
TunnelsÆ, Internet RFC 3209, IETF Proposed Standard,
December 2001.
[RFC-3212] B.Jamoussi (Editor) et al. æConstraint-Based LSP Setup
using LDPÆ, Internet RFC 3212, IETF Proposed Standard,
January 2002.
12. Contributors
Alberto Bellato (Alcatel)
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7215
Email: alberto.bellato@netit.alcatel.it
Sudheer Dharanikota (Nayna Networks)
157 Topaz Street,
Milpitas, CA 95035, USA
Phone: +1 408 956-8000X357
Email: sudheer@nayna.com
Michele Fontana (Alcatel)
Via Trento 30,
I-20059 Vimercate, Italy
Phone: +39 039 686-7053
Email: michele.fontana@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
D.Papadimitriou et al. - Internet Draft û Expires May 2003 17
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
Email: gert.grammel@netit.alcatel.it
Dan Guo (Turin Networks)
1415 N. McDowell Blvd,
Petaluma, CA 94954, USA
Phone: +1 707 665-4357
Email: dguo@turinnetworks.com
Juergen Heiles (Siemens AG)
Hofmannstr. 51,
D-81379 Munich, Germany
Phone: +49 897 224-8664
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)
101 Crawfords Corner Rd, Rm 3C-512
Holmdel, New Jersey 07733-3030, USA
Tel: +1 732 949-5141
Email: zwlin@lucent.com
Eric Mannie (KPNQwest)
Terhulpsesteenweg, 6A,
1560 Hoeilaart, Belgium
Phone: +32 2 658-5652
Email: eric.mannie@ebone.com
Maarten Vissers (Lucent)
Boterstraat 45, Postbus 18,
1270 AA Huizen, Netherlands
Email: mvissers@lucent.com
Yong Xue (WorldCom)
22001 Loudoun County Parkway,
Ashburn, VA 20147, USA
Tel: +1 703 886-5358
Email: yong.xue@wcom.com
13. AuthorÆs Address
Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1,
B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be
D.Papadimitriou et al. - Internet Draft û Expires May 2003 18
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
Appendix 1 û Abbreviations
BSNT Bit Stream without Octet Timing
BSOT Bit Stream with Octet Timing
CBR Constant Bit Rate
ESCON Enterprise Systems Connection
FC Fiber Channel
FEC Forward Error Correction
FICON Fiber Connection
FSC Fiber Switch Capable
GCC General Communication Channel
GFP Generic Framing Procedure
LSC Lambda Switch Capable
LSP Label Switched Path
MS Multiplex Section
naOH non-associated Overhead
NMC Number of Multiplexed Components
NVC Number of Virtual Components
OCC Optical Channel Carrier
OCG Optical Carrier Group
OCh Optical Channel (with full functionality)
OChr Optical Channel (with reduced functionality)
ODTUG Optical Date Tributary Unit Group
ODU Optical Channel Data Unit
OH Overhead
OMS Optical Multiplex Section
OMU Optical Multiplex Unit
OOS OTM Overhead Signal
OPS Optical Physical Section
OPU Optical Channel Payload Unit
OSC Optical Supervisory Channel
OTH Optical Transport Hierarchy
OTM Optical Transport Module
OTN Optical Transport Network
OTS Optical Transmission Section
OTU Optical Channel Transport Unit
OTUkV Functionally Standardized OTUk
PPP Point to Point Protocol
PSC Packet Switch Capable
RES Reserved
RS Regenerator Section
TTI Trail Trace Identifier
TDM Time Division Multiplex
Appendix 2 û G.709 Indexes
- Index k: The index "k" is used to represent a supported bit rate
and the different versions of OPUk, ODUk and OTUk. k=1 represents an
approximate bit rate of 2.5 Gbit/s, k=2 represents an approximate
bit rate of 10 Gbit/s, k = 3 an approximate bit rate of 40 Gbit/s
and k = 4 an approximate bit rate of 160 Gbit/s (under definition).
The exact bit-rate values are in kbits/s:
. OPU: k=1: 2 488 320.000, k=2: 9 995 276.962, k=3: 40 150 519.322
D.Papadimitriou et al. - Internet Draft û Expires May 2003 19
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
. 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 2003 20
draft-ietf-ccamp-gmpls-g709-03.txt November 2002
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 2003 21
Datatracker
draft-ietf-ccamp-gmpls-g709-03
This is an older version of an Internet-Draft that was ultimately published as RFC 4328.
| Document | Document type |
This is an older version of an Internet-Draft that was ultimately published as RFC 4328.
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author | |||
| RFC stream |
|
||
| Other formats | |||
| Additional resources | Mailing list discussion |