draft-ietf-ccamp-gmpls-g709-00.txt   draft-ietf-ccamp-gmpls-g709-01.txt 
CCAMP Working Group D. Papadimitriou (Alcatel) - Editor CCAMP Working Group D. Papadimitriou (Alcatel) - Editor
Category: Internet Draft Category: Internet Draft
Expiration Date: September 2002 Alberto Bellato (Alcatel) Expiration Date: December 2002 Alberto Bellato (Alcatel)
Sudheer Dharanikota (Nayna) Sudheer Dharanikota (Nayna)
Michele Fontana (Alcatel) Michele Fontana (Alcatel)
Nasir Ghani (Sorrento) Nasir Ghani (Sorrento)
Gert Grammel (Alcatel) Gert Grammel (Alcatel)
Dan Guo (Turin) Dan Guo (Turin)
Juergen Heiles (Siemens) Juergen Heiles (Siemens)
Jim Jones (Alcatel) Jim Jones (Alcatel)
Zhi-Wei Lin (Lucent) Zhi-Wei Lin (Lucent)
Eric Mannie (KPNQwest) Eric Mannie (KPNQwest)
Maarten Vissers (Lucent) Maarten Vissers (Lucent)
Yong Xue (WorldCom) Yong Xue (WorldCom)
March 2002 June 2002
GMPLS Signalling Extensions Generalized MPLS Signalling Extensions
for G.709 Optical Transport Networks Control for G.709 Optical Transport Networks Control
draft-ietf-ccamp-gmpls-g709-00.txt draft-ietf-ccamp-gmpls-g709-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
skipping to change at line 50 skipping to change at line 50
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Conventions used in this document: Conventions used in this document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2]. this document are to be interpreted as described in RFC-2119 [2].
D.Papadimitriou et al. - Internet Draft û Expires September 2002 1 D.Papadimitriou et al. - Internet Draft û Expires December 2002 1
Abstract Abstract
This document is a companion to the Generalized MPLS (GMPLS) This document is a companion to the Generalized MPLS (GMPLS)
signalling documents [GMPLS-SIG], [GMPLS-RSVP] and [GMPLS-LDP]. It signalling documents. It describes the technology specific
describes the G.709 [ITUT-G709] technology specific information information needed to extend GMPLS signalling to control Optical
needed to extend GMPLS signalling to control Optical Transport Transport Networks (OTN); it also includes the so-called pre-OTN
Networks (OTN); it also includes the so-called pre-OTN
developments. developments.
DISCLAIMER *** DISCLAIMER ***
In this document, the presented views on ITU-T G.709 OTN In this document, the presented views on ITU-T G.709 OTN
Recommendation (and referenced) are intentionally restricted as Recommendation (and referenced) are intentionally restricted as
needed from the GMPLS perspective within the IETF CCAMP WG context. needed from the GMPLS perspective within the IETF CCAMP WG context.
Hence, the objective of this document is not to replicate the Hence, the objective of this document is not to replicate the
content of the ITU-T OTN recommendations. Therefore, the reader content of the ITU-T OTN recommendations. Therefore, the reader
interested in going into more details concerning the corresponding interested in going into more details concerning the corresponding
technologies is strongly invited to consult the corresponding ITU- technologies is strongly invited to consult the corresponding ITU-
T documents (also referenced in this memo). T documents (also referenced in this memo).
skipping to change at line 100 skipping to change at line 99
parameter specific objects. parameter specific objects.
Note: in the context of this memo, by pre-OTN developments, one Note: in the context of this memo, by pre-OTN developments, one
refers to Optical Channel, Digital Wrapper and Forward Error refers to Optical Channel, Digital Wrapper and Forward Error
Correction (FEC) solutions that are not G.709 compliant. Details Correction (FEC) solutions that are not G.709 compliant. Details
concerning pre-OTN SONET/SDH based solutions including Optical concerning pre-OTN SONET/SDH based solutions including Optical
Sections (OS), Regenerator Section(RS)/Section and Multiplex Sections (OS), Regenerator Section(RS)/Section and Multiplex
Section(MS)/ Line overhead transparency are covered in [GMLS-SSS] Section(MS)/ Line overhead transparency are covered in [GMLS-SSS]
and [GMPLS-SSS-EXT]. and [GMPLS-SSS-EXT].
2. GMPLS Extensions for G.709 2. GMPLS Extensions for G.709 - Overview
Although G.709 defines several networking layers (OTS, OMS, OPS, Although G.709 defines several networking layers (OTS, OMS, OPS,
OCh, OChr constituting the optical transport hierarchy and OTUk, OCh, OChr constituting the optical transport hierarchy and OTUk,
ODUk constituting the digital transport hierarchy) only the OCh ODUk constituting the digital transport hierarchy) only the OCh
D.Papadimitriou et al. - Internet Draft û Expires September 2002 2
(Optical Channel) and the ODUk (Optical Channel Data Unit) layers (Optical Channel) and the ODUk (Optical Channel Data Unit) layers
D.Papadimitriou et al. - Internet Draft û Expires November 2002 2
are defined as switching layers. Both OCh (but not OChr) and ODUk are defined as switching layers. Both OCh (but not OChr) and ODUk
layers include the overhead for supervision and management. The OCh layers include the overhead for supervision and management. The OCh
overhead is transported in a non-associated manner (so also referred overhead is transported in a non-associated manner (so also referred
to as the non-associated overhead û naOH) in the OTM Overhead Signal to as the non-associated overhead û naOH) in the OTM Overhead Signal
(OOS), together with the OTS and OMS non-associated overhead. The (OOS), together with the OTS and OMS non-associated overhead. The
OOS is transported via a dedicated wavelength referred to as the OOS is transported via a dedicated wavelength referred to as the
Optical Supervisory Channel (OSC). It should be noticed that the Optical Supervisory Channel (OSC). It should be noticed that the
naOH is only functionally specified and as such open to vendor naOH is only functionally specified and as such open to vendor
specific solutions. The ODUk overhead is transported in an specific solutions. The ODUk overhead is transported in an
associated manner as part of the digital ODUk frame. associated manner as part of the digital ODUk frame.
skipping to change at line 160 skipping to change at line 159
3. Generalized Label Request 3. Generalized Label Request
The Generalized Label Request as defined in [GMPLS-SIG], includes a The Generalized Label Request as defined in [GMPLS-SIG], includes a
technology independent part and a technology dependent part (i.e. technology independent part and a technology dependent part (i.e.
the traffic parameters). In this section, we suggest to adapt both the traffic parameters). In this section, we suggest to adapt both
parts in order to accommodate the GMPLS Signalling to the G.709 parts in order to accommodate the GMPLS Signalling to the G.709
recommendation [ITUT-G709]. recommendation [ITUT-G709].
3.1 Technology Independent Part 3.1 Technology Independent Part
D.Papadimitriou et al. - Internet Draft û Expires September 2002 3 D.Papadimitriou et al. - Internet Draft û Expires November 2002 3
As defined in [GMPLS-SIG], the LSP Encoding Type and the Generalized As defined in [GMPLS-SIG], the LSP Encoding Type and the Generalized
Protocol Identifier (Generalized-PID) constitute the technology Protocol Identifier (Generalized-PID) constitute the technology
independent part of the Generalized Label Request. independent part of the Generalized Label Request.
The information carried in the technology independent part of the The information carried in the technology independent part of the
Generalized Label Request is defined as follows: Generalized Label Request is defined as follows:
0 1 2 3 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 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 214 skipping to change at line 213
Value Type Value Type
----- ---- ----- ----
12 G.709 ODUk (Digital Path) 12 G.709 ODUk (Digital Path)
13 G.709 Optical Channel 13 G.709 Optical Channel
Moreover, the code-point for the G.709 Optical Channel (OCh) layer 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- will indicate the capability of an end-system to use the G.709 non-
associated overhead (naOH) i.e. the OTM Overhead Signal (OOS) associated overhead (naOH) i.e. the OTM Overhead Signal (OOS)
multiplexed into the OTM-n.m interface signal. multiplexed into the OTM-n.m interface signal.
D.Papadimitriou et al. - Internet Draft û Expires September 2002 4 D.Papadimitriou et al. - Internet Draft û Expires November 2002 4
3.1.2 Switching Type 3.1.2 Switching Type
The Switching Type indicates the type of switching that should be The Switching Type indicates the type of switching that should be
performed at the termination of a particular link. This field is performed at the termination of a particular link. This field is
only needed for links that advertise more than one type of switching only needed for links that advertise more than one type of switching
capability (see [GMPLS-RTG]). capability (see [GMPLS-RTG]).
Here, no additional values are to be considered in order to Here, no additional values are to be considered in order to
accommodate G.709 switching types since an ODUk switching (and so accommodate G.709 switching types since an ODUk switching (and so
skipping to change at line 259 skipping to change at line 258
Mapping of 2.5, 10 and 40 Gbps Bit Stream Mapping of 2.5, 10 and 40 Gbps Bit Stream
- ODUk: transport of Digital Path at 2.5, 10 and 40 Gbps - 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 The G-PID can take one of the following values when the client
payload is transported over the Optical Channel layer, in addition payload is transported over the Optical Channel layer, in addition
to the payload identifiers already defined in [GMPLS-SIG]: 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 - CBR: Constant Bit Rate i.e. mapping of STM-16/OC-48, STM-64/OC-192
and STM-256/OC-768 and STM-256/OC-768
- OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps - 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 Also, when client payloads such as Ethernet MAC/PHY and IP/PPP are
encapsulated through the Generic Framing Procedure (GFP) as encapsulated through the Generic Framing Procedure (GFP) as
described in ITU-T G.7041, we use dedicated G-PID values. Notice 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 that additional G-PID values such as ESCON, FICON and Fiber Channel
could complete this list in future releases. could complete this list in future releases.
In order to include pre-OTN developments as defined above, the G-PID 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 can take one of the values currently defined in [GMPLS-SIG] when the
the client payload is transported over an Optical Channel (i.e. a following client payloads are transported over a so-called lambda:
lambda):
D.Papadimitriou et al. - Internet Draft û Expires September 2002 5 D.Papadimitriou et al. - Internet Draft û Expires November 2002 5
- Gigabit Ethernet: 1 Gbps and 10 Gbps - Gigabit Ethernet: 1 Gbps and 10 Gbps
- ESCON and FICON : left for further consideration - ESCON and FICON : left for further consideration
- Fiber Channel : left for further consideration - Fiber Channel : left for further consideration
The following table summarizes the G-PID with respect to the LSP The following table summarizes the G-PID with respect to the LSP
Encoding Type: Encoding Type:
Value G-PID Type LSP Encoding Type Value G-PID Type LSP Encoding Type
----- ---------- ----------------- ----- ---------- -----------------
44 G.709 ODUj G.709 ODUk (with k > j) 47 G.709 ODUj G.709 ODUk (with k > j)
45 G.709 OTUk(v) G.709 OCh (ODUk mapped into OTUk(v)) 48 G.709 OTUk(v) G.709 OCh
46 CBR/CBRa G.709 ODUk, G.709 OCh ODUk mapped into OTUk(v)
47 CBRb G.709 ODUk 49 CBR/CBRa G.709 ODUk, G.709 OCh
48 BSOT G.709 ODUk 50 CBRb G.709 ODUk
49 BSNT G.709 ODUk 51 BSOT G.709 ODUk
50 IP/PPP (GFP) G.709 ODUk 52 BSNT G.709 ODUk
51 Ethernet (GFP) G.709 ODUk 53 IP/PPP (GFP) G.709 ODUk (and SDH)
54 Ethernet MAC (framed GFP) G.709 ODUk (and SDH)
55 Ethernet PHY (transparent GFP) G.709 ODUk (and SDH)
Note: Value 46 and 47 includes mapping of SDH/Sonet Note: Value 49 and 50 includes mapping of SDH
The following table summarizes the update of the G-PID values The following table summarizes the update of the G-PID values
defined in [GMPLS-SIG]: defined in [GMPLS-SIG]:
Value G-PID Type LSP Encoding Type Value G-PID Type LSP Encoding Type
----- ---------- ----------------- ----- ---------- -----------------
32 ATM Mapping SONET, SDH, G.709 ODUk 32 ATM Mapping SDH, G.709 ODUk
33 Ethernet (GbE) G.709 OCh, Lambda, Fiber 33 Ethernet PHY SDH, G.709 OCh, Lambda, Fiber
34 SDH G.709 OCh, Lambda, Fiber 34 SDH G.709 OCh, Lambda, Fiber
35 SONET G.709 OCh, Lambda, Fiber 35 Reserved (SONET Dep.) G.709 OCh, Lambda, Fiber
3.2 G.709 Traffic-Parameters 3.2 G.709 Traffic-Parameters
When G.709 Digital Path Layer or G.709 Optical Channel Layer is When G.709 Digital Path Layer or G.709 Optical Channel Layer is
specified in the LSP Encoding Type field, the information referred specified in the LSP Encoding Type field, the information referred
to as technology dependent information or simply traffic-parameters to as technology dependent information (or simply traffic-
is carried additionally to the one included in the Generalized Label parameters) is carried additionally to the one included in the
Request and is defined as follows: Generalized Label Request and is defined as follows:
0 1 2 3 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 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 | | Signal Type | Reserved | NMC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier | | NVC | Multiplier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this frame, NMC stands for Number of Multiplexed Components and In this frame, NMC stands for Number of Multiplexed Components and
NVC for Number of Virtual Components. Each of these fields is NVC for Number of Virtual Components. Each of these fields is
tailored in order to support G.709 LSP. tailored in order to support G.709 LSP.
3.2.1 Signal Type D.Papadimitriou et al. - Internet Draft û Expires November 2002 6
D.Papadimitriou et al. - Internet Draft û Expires September 2002 6 3.2.1 Signal Type (ST)
This field (8 bits) indicates the requested G.709 elementary Signal
Type. The possible values are: This field (8 bits) indicates the type of G.709 Elementary Signal
that comprises the requested LSP. The permitted values are:
Value Type Value Type
----- ---- ----- ----
0 irrelevant 0 Irrelevant
1 ODU1 (i.e. 2.5 Gbps) 1 ODU1 (i.e. 2.5 Gbps)
2 ODU2 (i.e. 10 Gbps) 2 ODU2 (i.e. 10 Gbps)
3 ODU3 (i.e. 40 Gbps) 3 ODU3 (i.e. 40 Gbps)
4 Reserved for future use 4 Reserved for future use
5 Reserved for future use 5 Reserved for future use
6 OCh at 2.5 Gbps 6 OCh at 2.5 Gbps
7 OCh at 10 Gbps 7 OCh at 10 Gbps
8 OCh at 40 Gbps 8 OCh at 40 Gbps
9-255 Reserved for future use 9-255 Reserved for future use
skipping to change at line 354 skipping to change at line 355
- if the LSP Encoding Type value is the G.709 Digital Path layer - 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) 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 - 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 then the valid values are the OCh at 2.5, 10 or 40 Gbps
- if the LSP Encoding Type is ôLambdaö (which includes the - if the LSP Encoding Type is ôLambdaö (which includes the
pre-OTN Optical Channel layer) then the valid value is irrelevant pre-OTN Optical Channel layer) then the valid value is irrelevant
(Signal Type = 0) (Signal Type = 0)
- if the LSP Encoding Type is ôDigital Wrapperö, then the valid - if the LSP Encoding Type is ôDigital Wrapperö, then the valid
value is irrelevant (Signal Type = 0) 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 either directly on the Elementary
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.
3.2.3 Number of Multiplexed Components (NMC) 3.2.3 Number of Multiplexed Components (NMC)
The NMC field (16 bits) indicates the number of ODU tributary slots 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 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 requested LSP. This field is not applicable when an ODUk is mapped
into an OTUk and irrelevant at the Optical Channel layer. In both into an OTUk and irrelevant at the Optical Channel layer. In both
D.Papadimitriou et al. - Internet Draft û Expires November 2002 7
cases, it MUST be set to zero (NMC = 0) when sent and should be cases, it MUST be set to zero (NMC = 0) when sent and should be
ignored when received. ignored when received.
When applied at the Digital Path layer, in particular for ODU2 When applied at the Digital Path layer, in particular for ODU2
connections multiplexed into one ODU3 payload, the NMC field connections multiplexed into one ODU3 payload, the NMC field
specifies the number of individual tributary slots (NMC = 4) specifies the number of individual tributary slots (NMC = 4)
constituting the requested connection. These components are still constituting the requested connection. These components are still
processed within the context of a single connection entity. For all processed within the context of a single connection entity. For all
other currently defined multiplexing cases (see Section 2), the NMC other currently defined multiplexing cases (see Section 2), the NMC
field is set to 1. field is set to 1.
3.2.4 Number of Virtual Components (NVC) 3.2.4 Number of Virtual Components (NVC)
The NVC field (16 bits) is dedicated to ODUk virtual concatenation The NVC field (16 bits) is dedicated to ODUk virtual concatenation
(i.e. ODUk Inverse Multiplexing) purposes. It indicates the number (i.e. ODUk Inverse Multiplexing) purposes. It indicates the number
of ODU1, ODU2 or ODU3 elementary signals that are requested to be of ODU1, ODU2 or ODU3 elementary signals that are requested to be
virtually concatenated to form an ODUk-Xv signal. By definition, virtually concatenated to form an ODUk-Xv signal. By definition,
these signals MUST be of the same type. these signals MUST be of the same type.
D.Papadimitriou et al. - Internet Draft û Expires September 2002 7
This field is set to 0 (default value) to indicate that no virtual This field is set to 0 (default value) to indicate that no virtual
concatenation is requested. concatenation is requested.
Note: the current usage of this field only applies for G.709 ODUk 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. Therefore, it must be set to zero when requesting G.709 OCh
LSP. LSP.
3.2.5 Multiplier (MT) 3.2.5 Multiplier (MT)
The multiplier field (16 bits) indicates the number of identical The multiplier field (16 bits) indicates the number of identical
skipping to change at line 415 skipping to change at line 431
4. Generalized Label 4. Generalized Label
This section describes the Generalized Label space for the Digital This section describes the Generalized Label space for the Digital
Path and the Optical Channel Layer. The label distribution rules Path and the Optical Channel Layer. The label distribution rules
follows the ones defined in [GMPLS-SSS] and are detailed in Section follows the ones defined in [GMPLS-SSS] and are detailed in Section
4.2. 4.2.
4.1 ODUk Label Space 4.1 ODUk Label Space
D.Papadimitriou et al. - Internet Draft û Expires November 2002 8
At the Digital Path layer (i.e. ODUk layers), G.709 defines three At the Digital Path layer (i.e. ODUk layers), G.709 defines three
different client payload bit rates. An Optical Data Unit (ODU) different client payload bit rates. An Optical Data Unit (ODU)
frame has been defined for each of these bit rates. ODUk refers to 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) the frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps)
or 3 (for 40 Gbps). or 3 (for 40 Gbps).
In addition to the support of ODUk mapping into OTUk, the G.709 In addition to the support of ODUk mapping into OTUk, the G.709
label space supports the sub-levels of ODUk multiplexing. ODUk label space supports the sub-levels of ODUk multiplexing. ODUk
multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk multiplexing refers to multiplexing of ODUj (j = 1, 2) into an ODUk
(k > j), in particular: (k > j), in particular:
- ODU1 into ODU2 multiplexing - ODU1 into ODU2 multiplexing
- ODU1 into ODU3 multiplexing - ODU1 into ODU3 multiplexing
- ODU2 into ODU3 multiplexing - ODU2 into ODU3 multiplexing
- ODU1 and ODU2 into ODU3 multiplexing - ODU1 and ODU2 into ODU3 multiplexing
More precisely, ODUj into ODUk multiplexing (k > j) is defined when More precisely, ODUj into ODUk multiplexing (k > j) is defined when
an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an
D.Papadimitriou et al. - Internet Draft û Expires September 2002 8
ODTUG constituted by ODU tributary slots) which is mapped into 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 OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is
mapped into an OTUk. mapped into an OTUk.
Therefore, the label space structure is a tree whose root is 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 signal and leaves the ODUj signals (k >= j) that can be transported
via the tributary slots and switched between these slots. A G.709 via the tributary slots and switched between these slots. A G.709
Digital Path layer label identifies the exact position of a Digital Path layer label identifies the exact position of a
particular ODUj signal in an ODUk multiplexing structure. particular ODUj signal in an ODUk multiplexing structure.
skipping to change at line 469 skipping to change at line 484
- t1 is not significant for the other ODUk signal types (t1=0). - t1 is not significant for the other ODUk signal types (t1=0).
2. t2 (3-bit): 2. t2 (3-bit):
- t2=1 indicates a not further sub-divided ODU2 signal. - t2=1 indicates a not further sub-divided ODU2 signal.
- t2=2->5 indicates the tributary slot (t2th-2) used by the - t2=2->5 indicates the tributary slot (t2th-2) used by the
ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2). ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2).
- t2 is not significant for an ODU3 (t2=0). - t2 is not significant for an ODU3 (t2=0).
3. t3 (6-bit): 3. t3 (6-bit):
- t3=1 indicates a not further sub-divided ODU3 signal. - t3=1 indicates a not further sub-divided ODU3 signal.
D.Papadimitriou et al. - Internet Draft û Expires November 2002 9
- t3=2->17 indicates the tributary slot (t3th-1) used by the - t3=2->17 indicates the tributary slot (t3th-1) used by the
ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3). ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3).
- t3=18->33 indicates the tributary slot (t3th-17) used by the - t3=18->33 indicates the tributary slot (t3th-17) used by the
ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3). ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3).
Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required
to identify the 4 tributary slots used by the ODU2; these tributary to identify the 4 tributary slots used by the ODU2; these tributary
time slots have to be allocated in ascending order. 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 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 > i), the corresponding ODUk signal ODU[i] is directly mapped into
the corresponding OTUk signal (k=i). We refer to this as the mapping the corresponding OTUk signal (k=i). We refer to this as the mapping
of an ODUk signal into an OTUk of the same order. Therefore, the 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 numbering starts at 1; zero is used to indicate a non-significant
field. A label field equal to zero is an invalid value. field. A label field equal to zero is an invalid value.
Examples: Examples:
- t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1 - t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1
D.Papadimitriou et al. - Internet Draft û Expires September 2002 9
- t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2 - 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=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 - 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 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 - 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 of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3
4.2 Label Distribution Rules 4.2 Label Distribution Rules
In case of ODUk in OTUk mapping, only one of label can appear in the In case of ODUk in OTUk mapping, only one of label can appear in the
Label field of a Generalized Label. Generalized Label.
In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered 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 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 restricted to only one label when NMC = 1). Each label indicates a
component (ODUj tributary slot) of the multiplexed signal. The order component (ODUj tributary slot) of the multiplexed signal. The order
of the labels must reflect the order of the ODUj into the multiplex of the labels must reflect the order of the ODUj into the multiplex
(not the physical order of tributary slots). (not the physical order of tributary slots).
In case of ODUk virtual concatenation, the explicit ordered list of In case of ODUk virtual concatenation, the explicit ordered list of
all labels in the concatenation is given. Each label indicates a all labels in the concatenation is given. Each label indicates a
skipping to change at line 524 skipping to change at line 539
multiplexed virtually concatenated signals, the first set of labels multiplexed virtually concatenated signals, the first set of labels
indicates the components (ODUj tributary slots) of the first indicates the components (ODUj tributary slots) of the first
virtually concatenated signal, the second set of labels indicates virtually concatenated signal, the second set of labels indicates
the components (ODUj tributary slots) of the second virtually the components (ODUj tributary slots) of the second virtually
concatenated signal, and so on. concatenated signal, and so on.
In case of multiplication (i.e. when using the MT field), the In case of multiplication (i.e. when using the MT field), the
explicit ordered list of all labels taking part in the composed explicit ordered list of all labels taking part in the composed
signal is given. The above representation limits multiplication to signal is given. The above representation limits multiplication to
remain within a single (component) link. In case of multiplication remain within a single (component) link. In case of multiplication
D.Papadimitriou et al. - Internet Draft û Expires November 2002 10
of multiplexed/virtually concatenated signals, the first set of of multiplexed/virtually concatenated signals, the first set of
labels indicates the components of the first multiplexed/virtually labels indicates the components of the first multiplexed/virtually
concatenated signal, the second set of labels indicates components concatenated signal, the second set of labels indicates components
of the second multiplexed/virtually concatenated signal, and so on. of the second multiplexed/virtually concatenated signal, and so on.
Note: As defined in [GMPLS-SIG], label field values only have Note: As defined in [GMPLS-SIG], label field values only have
significance between two neighbors, and the receiver may need (in significance between two neighbors, and the receiver may need (in
some particular cases) to convert the received value into a value some particular cases) to convert the received value into a value
that has local significance. that has local significance.
4.3 Optical Channel Label Space 4.3 Optical Channel Label Space
At the Optical Channel layer, the label space must be consistently At the Optical Channel layer, the label space must be consistently
defined as a flat space whose values reflect the local assignment of defined as a flat space whose values reflect the local assignment of
OCh identifiers corresponding to the OTM-n.m sub-interface signals OCh identifiers corresponding to the OTM-n.m sub-interface signals
(m = 1, 2 or 3). Notice that these identifiers do not cover OChr (m = 1, 2 or 3). Notice that these identifiers do not cover OChr
since the corresponding Connection Function (OChr-CF) between OTM- since the corresponding Connection Function (OChr-CF) between OTM-
nr.m/OTM-0r.m is not yet defined in [ITUT-G798]. nr.m/OTM-0r.m is not defined in [ITUT-G798].
D.Papadimitriou et al. - Internet Draft û Expires September 2002 10 The OCh identifiers can be defined as specified in [GMPLS-SIG]
The OCh identifiers could be defined as specified in [GMPLS-SIG]
either with absolute values (channel identifiers (Channel ID) also either with absolute values (channel identifiers (Channel ID) also
referred to as wavelength identifiers) or relative values (channel referred to as wavelength identifiers) or relative values (channel
spacing also referred to as inter-wavelength spacing). The latter is spacing also referred to as inter-wavelength spacing). The latter is
strictly confined to a per-port label space while the former could 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 be defined as a local or a global (per node) label space. Such an
space is applicable to both OTN Optical Channel layer and pre-OTN OCh label space is applicable to both OTN Optical Channel layer and
Optical Channel layer. For this layer, label distribution rules are pre-OTN Optical Channel layer.
defined in [GMPSL-SIG].
Optical Channel Label distribution rules are defined in [GMPSL-SIG].
5. Examples 5. Examples
The following examples are given in order to illustrate the The following examples are given in order to illustrate the
processing described in the previous sections of this document. processing described in the previous sections of this document.
1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is 1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is
directly transported in an OTU1 (OTU2 or OTU3), the upstream node directly transported in an OTU1 (OTU2 or OTU3), the upstream node
requests results simply in an ODU1 (ODU2 or ODU3) signal request. requests results simply in an ODU1 (ODU2 or ODU3) signal request.
skipping to change at line 578 skipping to change at line 595
following when the Signal Type = 1: following when the Signal Type = 1:
- t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1 - 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=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 - 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 2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed
into the payload of a structured ODU2 (or ODU3), the upstream into the payload of a structured ODU2 (or ODU3), the upstream
node requests results simply in a ODU1 signal request. node requests results simply in a ODU1 signal request.
D.Papadimitriou et al. - Internet Draft û Expires November 2002 11
In such conditions, the downstream node has to return a unique In such conditions, the downstream node has to return a unique
label since the ODU1 is multiplexed into one ODTUG2 (or ODTUG3). label since the ODU1 is multiplexed into one ODTUG2 (or ODTUG3).
The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or The latter is then mapped into the ODU2 (or ODU3) via OPU2 (or
OPU3) and then mapped into the corresponding OTU2 (or OTU3). OPU3) and then mapped into the corresponding OTU2 (or OTU3).
Since a single ODU1 multiplexed signal is requested (Signal Type Since a single ODU1 multiplexed signal is requested (Signal Type
= 1 and NMC = 1), the downstream node has to return a single ODU1 = 1 and NMC = 1), the downstream node has to return a single ODU1
label which can take for instance one of the following values: 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=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=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 - 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 3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is
multiplexed into the payload of a structured ODU3, the upstream multiplexed into the payload of a structured ODU3, the upstream
node requests results simply in a ODU2 signal request. node requests results simply in a ODU2 signal request.
In such conditions, the downstream node has to return four labels In such conditions, the downstream node has to return four labels
since the ODU2 is multiplexed into one ODTUG3. The latter is since the ODU2 is multiplexed into one ODTUG3. The latter is
D.Papadimitriou et al. - Internet Draft û Expires September 2002 11
mapped into an ODU3 (via OPU3) and then mapped into an OTU3. mapped into an ODU3 (via OPU3) and then mapped into an OTU3.
Since an ODU2 multiplexed signal is requested (Signal Type = 2, Since an ODU2 multiplexed signal is requested (Signal Type = 2,
and NMC = 4), the downstream node has to return four ODU labels and NMC = 4), the downstream node has to return four ODU labels
which can take for instance the following values: which can take for instance the following values:
- t3=18, t2=0, t1=0 (first part of ODU2 in first TS of ODTUG3) - 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=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=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) - t3=26, t2=0, t1=0 (fourth part of ODU2 in ninth TS of ODTUG3)
skipping to change at line 631 skipping to change at line 647
LSP, etc. For instance, the corresponding labels can take the LSP, etc. For instance, the corresponding labels can take the
following values: following values:
- First ODU1: t3=2, t2=0, t1=0 (in first TS of ODTUG3) - 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) - 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) - 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) - Fourth ODU1: t3=6, t2=0, t1=0 (in fifth TS of ODTUG3)
6. Signalling Protocol Extensions 6. Signalling Protocol Extensions
D.Papadimitriou et al. - Internet Draft û Expires November 2002 12
This section specifies the [GMPLS-RSVP] and [GMPLS-LDP] protocol This section specifies the [GMPLS-RSVP] and [GMPLS-LDP] protocol
extensions needed to accommodate G.709 traffic parameters. extensions needed to accommodate G.709 traffic parameters.
6.1 RSVP-TE Details 6.1 RSVP-TE Details
For RSVP-TE, the G.709 traffic parameters are carried in the G.709 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 SENDER_TSPEC and FLOWSPEC objects. The same format is used both
for SENDER_TSPEC object and FLOWSPEC objects. The content of the for SENDER_TSPEC object and FLOWSPEC objects. The content of the
objects is defined above in Section 3.2. The objects have the objects is defined above in Section 3.2. The objects have the
following class and type for G.709: following class and type for G.709:
- G.709 SENDER_TSPEC Object: Class = 12, C-Type = 4 (TBA) - G.709 SENDER_TSPEC Object: Class = 12, C-Type = TBA
- G.709 FLOWSPEC Object: Class = 9, C-Type = 4 (TBA) - G.709 FLOWSPEC Object: Class = 9, C-Type = TBA
There is no Adspec associated with the SONET/SDH SENDER_TSPEC. There is no Adspec associated with the SONET/SDH SENDER_TSPEC.
Either the Adspec is omitted or an Int-serv Adspec with the Either the Adspec is omitted or an Int-serv Adspec with the
Default General Characterization Parameters and Guaranteed Service Default General Characterization Parameters and Guaranteed Service
fragment is used, see [RFC2210]. fragment is used, see [RFC2210].
For a particular sender in a session the contents of the FLOWSPEC For a particular sender in a session the contents of the FLOWSPEC
object received in a Resv message SHOULD be identical to the object received in a Resv message SHOULD be identical to the
D.Papadimitriou et al. - Internet Draft û Expires September 2002 12
contents of the SENDER_TSPEC object received in the corresponding contents of the SENDER_TSPEC object received in the corresponding
Path message. If the objects do not match, a ResvErr message with Path message. If the objects do not match, a ResvErr message with
a "Traffic Control Error/Bad Flowspec value" error SHOULD be a "Traffic Control Error/Bad Flowspec value" error SHOULD be
generated. generated.
6.2 CR-LDP Details 6.2 CR-LDP Details
For CR-LDP, the G.709 traffic parameters are carried in the G.709 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 Traffic Parameters TLV. The content of the TLV is defined in
Section 3.2. The header of the TLV has the following format: Section 3.2. The header of the TLV has the following format:
skipping to change at line 674 skipping to change at line 689
0 1 2 3 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 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 | |U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The type field indicates G.709 traffic parameters: 0xTBA The type field indicates G.709 traffic parameters: 0xTBA
7. Security Considerations 7. Security Considerations
This document introduces no new security considerations to either This draft introduces no new security considerations to either
[GMPLS-RSVP] or [GMPLS-LDP]. [GMPLS-RSVP] or [GMPLS-LDP]. GMPLS security is described in
section 11 of [GMPLS-SIG], in [RFC-3212] and in [RFC-3209].
8. References 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
D.Papadimitriou et al. - Internet Draft û Expires November 2002 13
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.
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 [ITUT-G707] ITU-T G.707 Recommendation, æNetwork node interface for
the synchronous digital hierarchy (SDH)Æ, ITU-T, April the synchronous digital hierarchy (SDH)Æ, ITU-T,
2000. October 2000.
[ITUT-G709] ITU-T G.709 Recommendation, version 1.0 (and Addendum), [ITUT-G709] ITU-T G.709 Recommendation, version 1.0 (and Amendment
æInterface for the Optical Transport Network (OTN)Æ, 1), æInterface for the Optical Transport Network
ITU-T, October 2001. (OTN)Æ, ITU-T, February 2001 (and October 2001).
D.Papadimitriou et al. - Internet Draft û Expires November 2002 14
[ITUT-G798] ITU-T G.798 Recommendation, version 1.0, [ITUT-G798] ITU-T G.798 Recommendation, version 1.0,
æCharacteristics of Optical Transport Network Hierarchy æCharacteristics of Optical Transport Network Hierarchy
Equipment Functional BlocksÆ, ITU-T, October 2001. Equipment Functional BlocksÆ, ITU-T, October 2001.
[ITUT-G872] ITU-T G.872 Recommendation, version 1.0, revision 6, [ITUT-G872] ITU-T G.872 Recommendation, version 2.0, æArchitecture
æArchitecture of Optical Transport NetworkÆ, ITU-T, of Optical Transport NetworkÆ, ITU-T, October 2001.
August 2001.
[ITUT-GASTN] ITU-T G.807 Recommendation, version 1.0, æAutomated
Switched Transport NetworkÆ, ITU-T, February 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-
02.txt, February 2002.
[GMPLS-LDP] L.Berger (Editor) et al., æGeneralized MPLS Signaling - [GMPLS-LDP] L.Berger (Editor) et al., æGeneralized MPLS Signaling -
CR-LDP ExtensionsÆ, Internet Draft, Work in progress, CR-LDP ExtensionsÆ, Internet Draft, Work in progress,
draft-ietf-mpls-generalized-cr-ldp-06.txt, April 2002.
D.Papadimitriou et al. - Internet Draft û Expires September 2002 13
draft-ietf-mpls-generalized-cr-ldp-05.txt, November
2001.
[GMPLS-RSVP] L.Berger (Editor) et al., æGeneralized MPLS Signaling - [GMPLS-RSVP] L.Berger (Editor) et al., æGeneralized MPLS Signaling -
RSVP-TE ExtensionsÆ, Internet Draft, Work in progress, RSVP-TE ExtensionsÆ, Internet Draft, Work in progress,
draft-ietf-mpls-generalized-rsvp-te-06.txt, November draft-ietf-mpls-generalized-rsvp-te-07.txt, April 2002.
2001.
[GMPLS-RTG] K.Kompella et al., ôRouting Extensions in Support of [GMPLS-RTG] K.Kompella et al., æRouting Extensions in Support of
Generalized MPLS,ö Internet Draft, Work in Progress, Generalized MPLSÆ, Internet Draft, Work in Progress,
draft-ietf-ccamp-gmpls-routing-02.txt, February draft-ietf-ccamp-gmpls-routing-04.txt, April 2002.
2002.
[GMPLS-SIG] L.Berger (Editor) et al., æGeneralized MPLS [GMPLS-SIG] L.Berger (Editor) et al., æGeneralized MPLS
- Signaling Functional DescriptionÆ, Internet Draft, - Signaling Functional DescriptionÆ, Internet Draft,
Work in progress, draft-ietf-mpls-generalized- Work in progress, draft-ietf-mpls-generalized-
signaling-07.txt, October 2001. signaling-08.txt, April 2002.
[GMPLS-SSS] E.Mannie (Editor) et al., æGeneralized MPLS û SDH/Sonet
SpecificsÆ, Internet Draft, Work in progress, draft-
ietf-ccamp-gmpls-sonet-sdh-03.txt, February 2002.
[GMPLS-SSS-EXT] E.Mannie (Editor) et al., æGeneralized MPLS û
SDH/Sonet Specifics ExtensionsÆ, Internet Draft,
Work, in progress, draft-ietf-ccamp-gmpls-sonet-sdh-
extensions-01.txt, February 2002.
[G709-FRM] A.Bellato, D.Papadimitriou et al., æG.709 Optical [GMPLS-SSS] E.Mannie and D.Papadimitriou (Editors) et al.,
Transport Networks GMPLS Control FrameworkÆ, Internet æGeneralized Multiprotocol Label Switching Extensions
Draft, Work in progress, draft-bellato-ccamp-g709- for SONET and SDH ControlÆ, Internet Draft, Work in
framework-01.txt, November 2001. progress, draft-ietf-ccamp-gmpls-sonet-sdh-05.txt, June
2002.
[RFC-2210] J.Wroclawski, æThe Use of RSVP with IETF Integrated [RFC-2210] J.Wroclawski, æThe Use of RSVP with IETF Integrated
ServicesÆ, Internet RFC 2210, IETF Standard Track, ServicesÆ, Internet RFC 2210, IETF Standard Track,
September 1997. September 1997.
9. Acknowledgments [RFC-3036] L.Andersson et al., æLDP SpecificationÆ, Internet RFC
3036, IETF Proposed Standard, January 2001.
The authors would like to thank Jean-Loup Ferrant, Mathieu Garnot, [RFC-3209] D.Awduche et al., æRSVP-TE: Extensions to RSVP for LSP
Massimo Canali, Germano Gasparini and Fong Liaw for their TunnelsÆ, Internet RFC 3209, IETF Proposed Standard,
constructive comments and inputs as well as James Fu, Siva December 2001.
Sankaranarayanan and Yangguang Xu.
This draft incorporates (upon agreement) material and ideas from [RFC-3212] B.Jamoussi (Editor) et al. æConstraint-Based LSP Setup
draft-lin-ccamp-ipo-common-label-request-00.txt. using LDPÆ, Internet RFC 3212, IETF Proposed Standard,
January 2002.
10. Author's Addresses 11.2 Informative References
[GMPLS-ARCH] E.Mannie (Editor) et al., æGeneralized Multi-Protocol
Label Switching (GMPLS) ArchitectureÆ, Internet Draft,
Work in progress, draft-ietf-ccamp-gmpls-architecture-
02.txt, February 2002.
[GMPLS-SSS-EXT] E.Mannie and D.Papadimitriou (Editors) et al.,
D.Papadimitriou et al. - Internet Draft û Expires November 2002 15
Generalized Multiprotocol Label Switching extensions to
control non-standard SONET and SDH featuresÆ, Internet
Draft, Work in progress, draft-ietf-ccamp-gmpls-sonet-
sdh-extensions-03.txt, June 2002.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," RFC 2119.
12. Author's Addresses
Alberto Bellato (Alcatel) Alberto Bellato (Alcatel)
Via Trento 30, Via Trento 30,
I-20059 Vimercate, Italy I-20059 Vimercate, Italy
Phone: +39 039 686-7215 Phone: +39 039 686-7215
Email: alberto.bellato@netit.alcatel.it Email: alberto.bellato@netit.alcatel.it
D.Papadimitriou et al. - Internet Draft û Expires September 2002 14
Sudheer Dharanikota (Nayna Networks) Sudheer Dharanikota (Nayna Networks)
157 Topaz St., 157 Topaz Street,
Milpitas, CA 95035, USA Milpitas, CA 95035, USA
Phone: +1 408 956-8000X357 Phone: +1 408 956-8000X357
Email: sudheer@nayna.com Email: sudheer@nayna.com
Michele Fontana (Alcatel) Michele Fontana (Alcatel)
Via Trento 30, Via Trento 30,
I-20059 Vimercate, Italy I-20059 Vimercate, Italy
Phone: +39 039 686-7053 Phone: +39 039 686-7053
Email: michele.fontana@netit.alcatel.it Email: michele.fontana@netit.alcatel.it
skipping to change at line 787 skipping to change at line 852
Phone: +1 858 646-7192 Phone: +1 858 646-7192
Email: nghani@sorrentonet.com Email: nghani@sorrentonet.com
Gert Grammel (Alcatel) Gert Grammel (Alcatel)
Via Trento 30, Via Trento 30,
I-20059 Vimercate, Italy I-20059 Vimercate, Italy
Phone: +39 039 686-4453 Phone: +39 039 686-4453
Email: gert.grammel@netit.alcatel.it Email: gert.grammel@netit.alcatel.it
Dan Guo (Turin Networks) Dan Guo (Turin Networks)
1415 N. McDowell Blvd 1415 N. McDowell Blvd,
Petaluma, CA 94954, USA Petaluma, CA 94954, USA
Phone: +1 707 665-4357 Phone: +1 707 665-4357
Email: dguo@turinnetworks.com Email: dguo@turinnetworks.com
Juergen Heiles (Siemens AG) Juergen Heiles (Siemens AG)
Hofmannstr. 51 Hofmannstr. 51,
D-81379 Munich, Germany D-81379 Munich, Germany
Phone: +49 89 7 22 - 4 86 64 Phone: +49 897 224-8664
Email: Juergen.Heiles@icn.siemens.de Email: juergen.heiles@icn.siemens.de
Jim Jones (Alcatel) Jim Jones (Alcatel)
3400 W. Plano Parkway,
Plano, TX 75075, USA D.Papadimitriou et al. - Internet Draft û Expires November 2002 16
3400 W. Plano Parkway, Plano, TX 75075, USA
Phone: +1 972 519-2744 Phone: +1 972 519-2744
Email: Jim.D.Jones1@usa.alcatel.com Email: Jim.D.Jones1@usa.alcatel.com
Zhi-Wei Lin (Lucent) Zhi-Wei Lin (Lucent)
101 Crawfords Corner Rd, Rm 3C-512 101 Crawfords Corner Rd, Rm 3C-512
Holmdel, New Jersey 07733-3030, USA Holmdel, New Jersey 07733-3030, USA
Tel: +1 732 949-5141 Tel: +1 732 949-5141
Email: zwlin@lucent.com Email: zwlin@lucent.com
Eric Mannie (KPNQwest) Eric Mannie (KPNQwest)
Terhulpsesteenweg, 6A Terhulpsesteenweg, 6A,
1560 Hoeilaart, Belgium 1560 Hoeilaart, Belgium
Phone: +32 2 658-5652 Phone: +32 2 658-5652
D.Papadimitriou et al. - Internet Draft û Expires September 2002 15
Email: eric.mannie@ebone.com Email: eric.mannie@ebone.com
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1, Francis Wellesplein 1,
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
Email: Dimitri.Papadimitriou@alcatel.be Email: dimitri.papadimitriou@alcatel.be
Maarten Vissers (Lucent) Maarten Vissers (Lucent)
Boterstraat 45 Boterstraat 45, Postbus 18,
Postbus 18
1270 AA Huizen, Netherlands 1270 AA Huizen, Netherlands
Email: mvissers@lucent.com Email: mvissers@lucent.com
Yong Xue (WorldCom) Yong Xue (WorldCom)
22001 Loudoun County Parkway 22001 Loudoun County Parkway,
Ashburn, VA 20147, USA Ashburn, VA 20147, USA
Tel: +1 703 886-5358 Tel: +1 703 886-5358
Email: yong.xue@wcom.com Email: yong.xue@wcom.com
D.Papadimitriou et al. - Internet Draft û Expires September 2002 16 D.Papadimitriou et al. - Internet Draft û Expires November 2002 17
Appendix 1 û Abbreviations Appendix 1 û Abbreviations
BSNT Bit Stream without Octet Timing BSNT Bit Stream without Octet Timing
BSOT Bit Stream with Octet Timing BSOT Bit Stream with Octet Timing
CBR Constant Bit Rate CBR Constant Bit Rate
ESCON Enterprise Systems Connection ESCON Enterprise Systems Connection
FC Fiber Channel FC Fiber Channel
FEC Forward Error Correction FEC Forward Error Correction
FICON Fiber Connector FICON Fiber Connector
skipping to change at line 892 skipping to change at line 955
Appendix 2 û G.709 Indexes Appendix 2 û G.709 Indexes
- Index k: The index "k" is used to represent a supported bit rate - 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 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 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 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). and k = 4 an approximate bit rate of 160 Gbit/s (under definition).
The exact bit-rate values are in kbits/s: 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 . 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 September 2002 17 D.Papadimitriou et al. - Internet Draft û Expires November 2002 18
. ODU: k=1: 2 498 775.126, k=2: 10 037 273.924, k=3: 40 319 218.983 . 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 . 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 - 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 bit rates supported on the interface. This is a one or more digit
ôkö, where each ôkö represents a particular bit rate. The valid ôkö, where each ôkö represents a particular bit rate. The valid
values for m are (1, 2, 3, 12, 23, 123). values for m are (1, 2, 3, 12, 23, 123).
- Index n: The index "n" is used to represent the order of the OTM, - 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 OTS, OMS, OPS, OCG and OMU. This index represents the maximum number
skipping to change at line 914 skipping to change at line 977
supported on the wavelength. It is possible that a reduced number of supported on the wavelength. It is possible that a reduced number of
higher bit rate wavelengths are supported. The case n=0 represents a higher bit rate wavelengths are supported. The case n=0 represents a
single channel without a specific wavelength assigned to the single channel without a specific wavelength assigned to the
channel. channel.
- Index r: The index "r", if present, is used to indicate a reduced - Index r: The index "r", if present, is used to indicate a reduced
functionality OTM, OCG, OCC and OCh (non-associated overhead is not 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 supported). Note that for n=0 the index r is not required as it
implies always reduced functionality. implies always reduced functionality.
D.Papadimitriou et al. - Internet Draft û Expires September 2002 18 D.Papadimitriou et al. - Internet Draft û Expires November 2002 19
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
skipping to change at line 943 skipping to change at line 1006
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
D.Papadimitriou et al. - Internet Draft û Expires September 2002 19 D.Papadimitriou et al. - Internet Draft û Expires November 2002 20
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/