draft-ietf-ccamp-gmpls-g709-05.txt   draft-ietf-ccamp-gmpls-g709-06.txt 
CCAMP Working Group D. Papadimitriou - Editor CCAMP Working Group D. Papadimitriou - Editor
Internet Draft (Alcatel) Internet Draft (Alcatel)
Category: Standard Track Category: Standard Track
Expiration Date: June 2004 January 2004 Expiration Date: June 2004 January 2004
Generalized MPLS 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-05.txt draft-ietf-ccamp-gmpls-g709-06.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 64 skipping to change at line 64
Table of Content Table of Content
Status of this Memo ............................................. 1 Status of this Memo ............................................. 1
Abstract ........................................................ 1 Abstract ........................................................ 1
Table of Content ................................................ 2 Table of Content ................................................ 2
1. Introduction ................................................. 2 1. Introduction ................................................. 2
2. GMPLS Extensions for G.709 - Overview ........................ 3 2. GMPLS Extensions for G.709 - Overview ........................ 3
3. Generalized Label Request .................................... 4 3. Generalized Label Request .................................... 4
3.1 Technology Independent Part ................................. 4 3.1 Technology Independent Part ................................. 4
3.1.1. LSP Encoding Type ........................................ 5 3.1.1. LSP Encoding Type ........................................ 4
3.1.2. Switching-Type ........................................... 5 3.1.2. Switching-Type ........................................... 5
3.1.3. Generalized-PID (G-PID) .................................. 6 3.1.3. Generalized-PID (G-PID) .................................. 5
3.2. G.709 Traffic-Parameters ................................... 7 3.2. G.709 Traffic-Parameters ................................... 7
3.2.1. Signal Type (ST).......................................... 7 3.2.1. Signal Type (ST).......................................... 7
3.2.2. Number of Multiplexed Components (NMC) ................... 8 3.2.2. Number of Multiplexed Components (NMC) ................... 8
3.2.3. Number of Virtual Components (NVC) ....................... 9 3.2.3. Number of Virtual Components (NVC) ....................... 8
3.2.4. Multiplier (MT) .......................................... 9 3.2.4. Multiplier (MT) .......................................... 9
3.2.5. Reserved Fields .......................................... 9 3.2.5. Reserved Fields .......................................... 9
4. Generalized Label ............................................ 9 4. Generalized Label ............................................ 9
4.1. ODUk Label Space .......................................... 10 4.1. ODUk Label Space ........................................... 9
4.2. Label Distribution Rules .................................. 11 4.2. Label Distribution Rules .................................. 11
4.3. OCh Label Space ........................................... 12 4.3. OCh Label Space ........................................... 12
5. Examples .................................................... 12 5. Examples .................................................... 12
6. Signalling Protocol Extensions .............................. 13 6. RSVP-TE Signalling Protocol Extensions ...................... 14
6.1. RSVP-TE Details ........................................... 13 7. Security Considerations ..................................... 14
6.2. CR-LDP Details ............................................ 14 8. IANA Considerations ......................................... 14
7. Security Considerations ..................................... 15
8. IANA Considerations ......................................... 15
9. Acknowledgments ............................................. 15 9. Acknowledgments ............................................. 15
10. Intellectual Property Notice ............................... 16 10. Intellectual Property Notice ............................... 15
11. References ................................................. 16 11. References ................................................. 15
11.1 Normative References ...................................... 16 11.1 Normative References ...................................... 15
12. Contributors ............................................... 17 12. Contributors ............................................... 16
13. Author's Address ........................................... 18 13. Author's Address ........................................... 17
Appendix 1 - Abbreviations ..................................... 19 Appendix 1 - Abbreviations ..................................... 18
Appendix 2 - G.709 Indexes ..................................... 19 Appendix 2 - G.709 Indexes ..................................... 18
Full Copyright Statement ....................................... 21 Full Copyright Statement ....................................... 20
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. this document are to be interpreted as described in RFC-2119.
In addition, the reader is assumed to be familiar with the In addition, the reader is assumed to be familiar with the
terminology used in ITU-T [ITUT-G709] as well as [RFC3471], terminology used in ITU-T [ITUT-G709] as well as [RFC3471], and
[RFC3473] and [RFC3472]. Abbreviations used in this document are [RFC3473]. Abbreviations used in this document are detailed in
detailed in Appendix 1. Appendix 1.
D.Papadimitriou (Editor) et al. - Expires June 2004 2
1. Introduction 1. Introduction
Generalized MPLS (GMPLS) extends MPLS from supporting Packet Generalized MPLS (GMPLS) extends MPLS from supporting Packet
Switching Capable (PSC) interfaces and switching to include Switching Capable (PSC) interfaces and switching to include
support of three new classes of interfaces and switching: Time- support of three new classes of interfaces and switching: Time-
Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch
D.Papadimitriou (Editor) et al. - Expires June 2004 2
(FSC) Capable. A functional description of the extensions to MPLS (FSC) Capable. A functional description of the extensions to MPLS
signaling needed to support these new classes of interfaces and signaling needed to support these new classes of interfaces and
switching is provided in [RFC3471]. [RFC3473] describes RSVP-TE switching is provided in [RFC3471]. [RFC3473] describes the RSVP-
specific formats and mechanisms needed to support all four classes TE specific formats and mechanisms needed to support all four
of interfaces, and CR-LDP extensions can be found in [RFC3472]. classes of interfaces.
This document presents the technology details that are specific to This document presents the technology details that are specific to
G.709 Optical Transport Networks (OTN) as specified in the ITU-T G.709 Optical Transport Networks (OTN) as specified in the ITU-T
G.709 recommendation [ITUT-G709] (and referenced documents), G.709 recommendation [ITUT-G709] (and referenced documents),
including pre-OTN developments. Per [RFC3471], G.709 technology including pre-OTN developments. Per [RFC3471], G.709 technology
specific parameters are carried through the signaling protocol in specific parameters are carried through the signaling protocol in
dedicated traffic parameter objects. dedicated traffic parameter objects.
The G.709 traffic parameters defined hereafter (see Section 3.2) The G.709 traffic parameters defined hereafter (see Section 3.2)
MUST be used when the label is encoded as defined in this MUST be used when the label is encoded as defined in this
skipping to change at line 158 skipping to change at line 156
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.
As described in [ITUT-G709], in addition to the support of ODUk As described in [ITUT-G709], in addition to the support of ODUk
mapping into OTUk (k = 1, 2, 3), [ITUT-G.709] supports ODUk mapping into OTUk (k = 1, 2, 3), [ITUT-G.709] supports ODUk
D.Papadimitriou (Editor) et al. - Expires June 2004 3
multiplexing. It refers to the multiplexing of ODUj (j = 1, 2) into multiplexing. It refers to the multiplexing of ODUj (j = 1, 2) into
an ODUk (k > j) signal, in particular: an ODUk (k > j) signal, 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
D.Papadimitriou (Editor) et al. - Expires June 2004 3
Therefore, adapting GMPLS to control G.709 OTN, can be achieved by Therefore, adapting GMPLS to control G.709 OTN, can be achieved by
considering that: considering that:
- a Digital Path layer by extending the previously defined - a Digital Path layer by extending the previously defined
"Digital Wrapper" in [GMPLS-SIG] corresponding to the ODUk "Digital Wrapper" in [GMPLS-SIG] corresponding to the ODUk
(digital) path layer. (digital) path layer.
- an Optical Path layer by extending the "Lambda" concept defined - an Optical Path layer by extending the "Lambda" concept defined
in [GMPLS-SIG] to the OCh (optical) path layer. in [GMPLS-SIG] to the OCh (optical) path layer.
- a label space structure by considering a tree whose root is an - a label space structure by considering a tree whose root is an
OTUk signal and leaves the ODUj signals (k >= j); enabling to OTUk signal and leaves the ODUj signals (k >= j); enabling to
identify the exact position of a particular ODUj signal in an identify the exact position of a particular ODUj signal in an
skipping to change at line 204 skipping to change at line 201
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, both parts are extended to the traffic parameters). In this section, both parts are extended to
accommodate the GMPLS Signalling to the G.709 transport plane accommodate the GMPLS Signalling to the G.709 transport plane
recommendation (see [ITUT-G709]). recommendation (see [ITUT-G709]).
3.1 Technology Independent Part 3.1 Technology Independent Part
As defined in [RFC3471], the LSP Encoding Type, the Switching Type As defined in [RFC3471], the LSP Encoding Type, the Switching Type
and the Generalized Protocol Identifier (Generalized-PID) constitute and the Generalized Protocol Identifier (Generalized-PID) constitute
the technology independent part of the Generalized Label Request. the technology independent part of the Generalized Label Request.
The encoding of the corresponding RSVP-TE object and CR-LDP TLV is The encoding of the corresponding RSVP-TE GENERALIZED_LABEL_REQUEST
specified in [RFC3473] Section 2.1 and [RFC3472] Section 2.1, object is specified in [RFC3473] Section 2.1.
respectively.
As mentioned here above, this document extends the LSP Encoding As mentioned here above, this document extends the LSP Encoding
Type, Switching Type and G-PID (Generalized-PID) values to Type, Switching Type and G-PID (Generalized-PID) values to
accommodate G.709 recommendation [ITUT-G709]. accommodate G.709 recommendation [ITUT-G709].
D.Papadimitriou (Editor) et al. - Expires June 2004 4
3.1.1 LSP Encoding Type 3.1.1 LSP Encoding Type
Since G.709 defines two networking layers (ODUk layers and OCh Since G.709 defines two networking layers (ODUk layers and OCh
layer), the LSP Encoding Type code-points can reflect these two layer), the LSP Encoding Type code-points can reflect these two
layers currently defined in [RFC3471] as "Digital Wrapper" and layers currently defined in [RFC3471] as "Digital Wrapper" and
"Lambda" code. "Lambda" code.
D.Papadimitriou (Editor) et al. - Expires June 2004 4
The LSP Encoding Type is specified per networking layer or more The LSP Encoding Type is specified per networking layer or more
precisely per group of functional networking layer: the ODUk layers precisely per group of functional networking layer: the ODUk layers
and the OCh layer. and the OCh layer.
Therefore, the current "Digital Wrapper" code-point defined in Therefore, the current "Digital Wrapper" code-point defined in
[RFC3471] can be replaced by two separated code-points: [RFC3471] can be replaced by two separated code-points:
- code-point for the G.709 Digital Path layer - code-point for the G.709 Digital Path layer
- code-point for the non-standard Digital Wrapper layer - code-point for the non-standard Digital Wrapper layer
In the same way, two separated code-points can replace the current In the same way, two separated code-points can replace the current
skipping to change at line 266 skipping to change at line 261
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
LSPs) belongs to the TDM class while an OCh switching (and so LSPs) LSPs) belongs to the TDM class while an OCh switching (and so LSPs)
to the Lambda class (i.e. LSC). to the Lambda class (i.e. LSC).
Moreover, in a strict layered G.709 network, when a downstream node Moreover, in a strict layered G.709 network, when a downstream node
receives a Generalized Label Request including one of these values receives a Generalized Label Request including one of these values
for the Switching Type field, this value SHOULD be ignored. for the Switching Type field, this value SHOULD be ignored.
D.Papadimitriou (Editor) et al. - Expires June 2004 5
3.1.3 Generalized-PID (G-PID) 3.1.3 Generalized-PID (G-PID)
The G-PID (16 bits field) as defined in [RFC3471], identifies the The G-PID (16 bits field) as defined in [RFC3471], identifies the
payload carried by an LSP, i.e. an identifier of the client layer of 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. that LSP. This identifier is used by the endpoints of the G.709 LSP.
D.Papadimitriou (Editor) et al. - Expires June 2004 5
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 Digital Path layer, in addition to payload is transported over the Digital Path layer, in addition to
the payload identifiers defined in [RFC3471]: the payload identifiers defined in [RFC3471]:
- CBRa: asynchronous Constant Bit Rate i.e. mapping of STM-16/OC- - CBRa: asynchronous Constant Bit Rate i.e. mapping of STM-16/OC-
48, STM-64/OC-192 and STM-256/OC-768 48, STM-64/OC-192 and STM-256/OC-768
- CBRb: bit synchronous Constant Bit Rate i.e. mapping of STM- - CBRb: bit synchronous Constant Bit Rate i.e. mapping of STM-
16/OC-48, STM-64/OC-192 and STM-256/OC-768 16/OC-48, STM-64/OC-192 and STM-256/OC-768
- ATM: mapping at 2.5, 10 and 40 Gbps - ATM: mapping at 2.5, 10 and 40 Gbps
- BSOT: non-specific client Bit Stream with Octet Timing i.e. - BSOT: non-specific client Bit Stream with Octet Timing i.e.
skipping to change at line 321 skipping to change at line 315
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
----- ---------- ----------------- ----- ---------- -----------------
47 G.709 ODUj G.709 ODUk (with k > j) 47 G.709 ODUj G.709 ODUk (with k > j)
48 G.709 OTUk(v) G.709 OCh 48 G.709 OTUk(v) G.709 OCh
ODUk mapped into OTUk(v) ODUk mapped into OTUk(v)
49 CBR/CBRa G.709 ODUk, G.709 OCh 49 CBR/CBRa G.709 ODUk, G.709 OCh
50 CBRb G.709 ODUk 50 CBRb G.709 ODUk
D.Papadimitriou (Editor) et al. - Expires June 2004 6
51 BSOT G.709 ODUk 51 BSOT G.709 ODUk
52 BSNT G.709 ODUk 52 BSNT G.709 ODUk
53 IP/PPP (GFP) G.709 ODUk (and SDH) 53 IP/PPP (GFP) G.709 ODUk (and SDH)
54 Ethernet MAC (framed 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) 55 Ethernet PHY (transparent GFP) G.709 ODUk (and SDH)
56 ESCON G.709 ODUk, Lambda, Fiber 56 ESCON G.709 ODUk, Lambda, Fiber
D.Papadimitriou (Editor) et al. - Expires June 2004 6
57 FICON G.709 ODUk, Lambda, Fiber 57 FICON G.709 ODUk, Lambda, Fiber
58 Fiber Channel G.709 ODUk, Lambda, Fiber 58 Fiber Channel G.709 ODUk, Lambda, Fiber
Note: Value 49 and 50 includes mapping of SDH 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 [RFC3471]: defined in [RFC3471]:
Value G-PID Type LSP Encoding Type Value G-PID Type LSP Encoding Type
----- ---------- ----------------- ----- ---------- -----------------
32 ATM Mapping SDH, G.709 ODUk 32 ATM Mapping SDH, G.709 ODUk
33 Ethernet PHY SDH, G.709 OCh, Lambda, Fiber 33 Ethernet PHY SDH, G.709 OCh, Lambda, Fiber
34 Sonet/SDH G.709 OCh, Lambda, Fiber 34 Sonet/SDH G.709 OCh, Lambda, Fiber
35 Reserved (SONET Dep.) 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- to as technology dependent (or simply traffic parameters) is carried
parameters) is carried additionally to the one included in the additionally to the one included in the Generalized Label Request.
Generalized Label Request and is defined as follows:
The G.709 traffic parameters are 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 (MT) | | NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
In this frame, NMC stands for Number of Multiplexed Components, NVC In this frame, NMC stands for Number of Multiplexed Components, NVC
for Number of Virtual Components and MT for Multiplier. Each of for Number of Virtual Components and MT for Multiplier. Each of
these fields is tailored to support G.709 LSP requests. these fields is tailored to support G.709 LSP requests.
The RSVP-TE encoding and processing of the G.709 traffic-parameters
are detailed in Section 6.
3.2.1 Signal Type (ST) 3.2.1 Signal Type (ST)
This field (8 bits) indicates the type of G.709 Elementary Signal This field (8 bits) indicates the type of G.709 Elementary Signal
that comprises the requested LSP. The permitted values are: 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)
D.Papadimitriou (Editor) et al. - Expires June 2004 7
3 ODU3 (i.e. 40 Gbps) 3 ODU3 (i.e. 40 Gbps)
4 Reserved 4 Reserved
D.Papadimitriou (Editor) et al. - Expires June 2004 7
5 Reserved 5 Reserved
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 9-255 Reserved
The value of the Signal Type field depends on LSP Encoding Type The value of the Signal Type field depends on LSP Encoding Type
value defined in Section 3.1.1 and [RFC3471]: value defined in Section 3.1.1 and [RFC3471]:
- 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)
skipping to change at line 429 skipping to change at line 427
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.
D.Papadimitriou (Editor) et al. - Expires June 2004 8
3.2.3 Number of Virtual Components (NVC) 3.2.3 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
D.Papadimitriou (Editor) et al. - Expires June 2004 8
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.
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 that the current usage of this field only applies for G.709 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 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 Signal Types. Therefore, it MUST be set to zero (NVC = 0) when
skipping to change at line 461 skipping to change at line 459
that form the Final Signal. A Composed Signal is the resulting that form the Final Signal. A Composed Signal is the resulting
signal from the application of the NMC and NVC fields to an signal from the application of the NMC and NVC fields to an
elementary Signal Type. GMPLS signalling currently implies that all elementary Signal Type. GMPLS signalling currently implies that all
the Composed Signals must be part of the same LSP. the Composed Signals must be part of the same LSP.
This field is set to one (default value) to indicate that exactly This field is set to one (default value) to indicate that exactly
one instance of a signal is being requested. Intermediate and egress one instance of a signal is being requested. Intermediate and egress
nodes MUST verify that the node itself and the interfaces on which nodes MUST verify that the node itself and the interfaces on which
the LSP will be established can support the requested multiplier the LSP will be established can support the requested multiplier
value. If the requested values can not be supported, the receiver value. If the requested values can not be supported, the receiver
node MUST generate a PathErr/NOTIFICATION message (see Section node MUST generate a PathErr message (see Section 6).
6.1/6.2, respectively).
Zero is an invalid value. If received, the node MUST generate a Zero is an invalid value for the MT field. If received, the node
PathErr/NOTIFICATION message (see Section 6.1/6.2, respectively). MUST generate a PathErr message (see Section 6).
3.2.5 Reserved Fields 3.2.5 Reserved Fields
The reserved fields (8 bits in row 1 and 32 bits fields in row 3) 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 are dedicated for future use. Reserved bits SHOULD be set to zero
when sent and MUST be ignored when received. when sent and MUST be ignored when received.
4. Generalized Label 4. Generalized Label
This section describes the Generalized Label value space for Digital This section describes the Generalized Label value space for Digital
Paths and Optical Channels. The Generalized Label is defined in Paths and Optical Channels. The Generalized Label is defined in
[RFC3471]. The format of the corresponding RSVP-TE object and CR-LDP [RFC3471]. The format of the corresponding RSVP-TE GENERALIZED_LABEL
TLV is specified in [RFC3473] Section 2.2 and [RFC3472] Section 2.2, object is specified in [RFC3473] Section 2.2.
respectively.
The label distribution rules detailed in Section 4.2 follow (when The label distribution rules detailed in Section 4.2 follow (when
applicable) the ones defined in [GMPLS-SONET-SDH]. applicable) the ones defined in [GMPLS-SONET-SDH].
D.Papadimitriou (Editor) et al. - Expires June 2004 9
4.1 ODUk Label Space 4.1 ODUk Label Space
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) frame different client payload bit rates. An Optical Data Unit (ODU) frame
has been defined for each of these bit rates. ODUk refers to the has been defined for each of these bit rates. ODUk refers to the
D.Papadimitriou (Editor) et al. - Expires June 2004 9
frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps) or frame at bit rate k, where k = 1 (for 2.5 Gbps), 2 (for 10 Gbps) or
3 (for 40 Gbps). 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
skipping to change at line 539 skipping to change at line 535
and t3 fields is defined as follows: and t3 fields is defined as follows:
1. t1 (1-bit): 1. t1 (1-bit):
- t1=1 indicates an ODU1 signal. - t1=1 indicates an ODU1 signal.
- 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).
D.Papadimitriou (Editor) et al. - Expires June 2004 10
- 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.
- t3=2->17 indicates the tributary slot (t3th-1) used by the - t3=2->17 indicates the tributary slot (t3th-1) used by the
D.Papadimitriou (Editor) et al. - Expires June 2004 10
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
skipping to change at line 595 skipping to change at line 591
component of the virtually concatenated signal. The order of the component of the virtually concatenated signal. The order of the
labels must reflect the order of the ODUk to concatenate (not the labels must reflect the order of the ODUk to concatenate (not the
physical order of time-slots). This representation limits virtual physical order of time-slots). This representation limits virtual
concatenation to remain within a single (component) link. In case of concatenation to remain within a single (component) link. In case of
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.
D.Papadimitriou (Editor) et al. - Expires June 2004 11
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 (Editor) et al. - Expires June 2004 11
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 [RFC3471], label field values only have Note: as defined in [RFC3471], 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.
skipping to change at line 648 skipping to change at line 645
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.
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 (ODU2 or ODU3) is directly mapped into the label since the ODU1 (ODU2 or ODU3) is directly mapped into the
corresponding OTU1 (OTU2 or OTU3). Since a single ODUk signal is corresponding OTU1 (OTU2 or OTU3). Since a single ODUk signal is
requested (Signal Type = 1, 2 or 3), the downstream node has to 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 return a single ODUk label which can be for instance one of the
following when the Signal Type = 1: following when the Signal Type = 1:
D.Papadimitriou (Editor) et al. - Expires June 2004 12
- 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
D.Papadimitriou (Editor) et al. - Expires June 2004 12
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.
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
skipping to change at line 702 skipping to change at line 699
When the downstream node receives a request for a 4 x ODU1 signal 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 (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 returns an ordered list of four labels to the upstream node: the
first ODU1 label corresponding to the first signal of the LSP, first ODU1 label corresponding to the first signal of the LSP,
the second ODU1 label corresponding to the second signal of the the second ODU1 label corresponding to the second signal of the
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)
D.Papadimitriou (Editor) et al. - Expires June 2004 13
- 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 D.Papadimitriou (Editor) et al. - Expires June 2004 13
This section specifies the [RFC3473] and [RFC3472] protocol 6. RSVP-TE Signalling Protocol Extensions
extensions needed to accommodate G.709 traffic parameters.
6.1 RSVP-TE Details This section specifies the [RFC3473] protocol extensions needed to
accommodate G.709 traffic parameters.
For RSVP-TE, the G.709 traffic parameters are carried in the G.709 The G.709 traffic parameters are carried in the G.709 SENDER_TSPEC
SENDER_TSPEC and FLOWSPEC objects. The same format is used both and FLOWSPEC objects. The same format is used both for
for SENDER_TSPEC object and FLOWSPEC objects. The content of the 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 = TBA - G.709 SENDER_TSPEC Object: Class = 12, C-Type = 5 (TBA by IANA)
- G.709 FLOWSPEC Object: Class = 9, C-Type = TBA - G.709 FLOWSPEC Object: Class = 9, C-Type = 5 (TBA by IANA)
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
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
skipping to change at line 746 skipping to change at line 741
the interfaces on which the LSP will be established can support the interfaces on which the LSP will be established can support
the requested Signal Type, NMC and NVC values (as defined in the requested Signal Type, NMC and NVC values (as defined in
Section 3.2). If the requested value(s) can not be supported, the Section 3.2). If the requested value(s) can not be supported, the
receiver node MUST generate a PathErr message with a "Traffic receiver node MUST generate a PathErr message with a "Traffic
Control Error/Service unsupported" indication (see [RFC2205]). Control Error/Service unsupported" indication (see [RFC2205]).
In addition, if the MT field is received with a zero value, the In addition, if the MT field is received with a zero value, the
node MUST generate a PathErr message with a "Traffic Control node MUST generate a PathErr message with a "Traffic Control
Error/Bad Tspec value" indication (see [RFC2205]). 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.Papadimitriou (Editor) et al. - Expires June 2004 14
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]).
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 7. Security Considerations
This draft introduces no new security considerations to either This draft introduces no new security considerations to [RFC3473].
[RFC3473] or [RFC3472]. GMPLS security is described in section 11 GMPLS security is described in section 11 of [RFC3471] and refers
of [RFC3471] and refers to [RFC3209] for RSVP-TE and to [RFC3212] to [RFC3209] for RSVP-TE.
for CR-LDP.
8. IANA Considerations 8. IANA Considerations
Three values have to be defined by IANA for this document: Three values have to be defined by IANA for this document:
Two RSVP C-Types in registry: Two RSVP C-Types in registry:
http://www.iana.org/assignments/rsvp-parameters http://www.iana.org/assignments/rsvp-parameters
- A G.709 SENDER_TSPEC object: Class = 12, C-Type = TBA - A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5
(see section 6.1). (Suggested value, TBA) - see Section 6.
- A G.709 FLOWSPEC object: Class = 9, C-Type = TBA (see
section 6.1).
One LDP TLV Type in registry:
http://www.iana.org/assignments/ldp-namespaces
- A Type field value for the G.709 Traffic Parameters D.Papadimitriou (Editor) et al. - Expires June 2004 14
TLV (see section 6.2). - A G.709 FLOWSPEC object: Class = 9, C-Type = 5
(Suggested value, TBA) - see Section 6.
9. Acknowledgments 9. Acknowledgments
The authors would like to thank Jean-Loup Ferrant, Mathieu Garnot, The authors would like to thank Jean-Loup Ferrant, Mathieu Garnot,
Massimo Canali, Germano Gasparini and Fong Liaw for their Massimo Canali, Germano Gasparini and Fong Liaw for their
constructive comments and inputs as well as James Fu, Siva constructive comments and inputs as well as James Fu, Siva
Sankaranarayanan and Yangguang Xu for their useful feedback. Sankaranarayanan and Yangguang Xu for their useful feedback.
This draft incorporates (upon agreement) material and ideas from This draft incorporates (upon agreement) material and ideas from
draft-lin-ccamp-ipo-common-label-request-00.txt. draft-lin-ccamp-ipo-common-label-request-00.txt.
D.Papadimitriou (Editor) et al. - Expires June 2004 15
10. Intellectual Property Notice 10. Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
skipping to change at line 853 skipping to change at line 813
(OTN)," G.709 Recommendation (and Amendment 1), (OTN)," G.709 Recommendation (and Amendment 1),
February 2001 (October 2001). February 2001 (October 2001).
[ITUT-G798] ITU-T, "Characteristics of Optical Transport Network [ITUT-G798] ITU-T, "Characteristics of Optical Transport Network
Hierarchy Equipment Functional Blocks," G.798 Hierarchy Equipment Functional Blocks," G.798
Recommendation, October 2001. Recommendation, October 2001.
[ITUT-G872] ITU-T, version 2.0, "Architecture of Optical Transport [ITUT-G872] ITU-T, version 2.0, "Architecture of Optical Transport
Network," G.872 Recommendation, October 2001. Network," G.872 Recommendation, October 2001.
D.Papadimitriou (Editor) et al. - Expires June 2004 15
[GMPLS-ARCH] Mannie, E. (Editor) et al., "Generalized Multi-Protocol [GMPLS-ARCH] Mannie, E. (Editor) et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Architecture," Internet Draft Label Switching (GMPLS) Architecture," Internet Draft
(work in progress), draft-ietf-ccamp-gmpls- (work in progress), draft-ietf-ccamp-gmpls-
architecture-07.txt, May 2003. architecture-07.txt, May 2003.
[GMPLS-RTG] Kompella, K. (Editor) et al., "Routing Extensions in [GMPLS-RTG] Kompella, K. (Editor) et al., "Routing Extensions in
Support of Generalized MPLS," Internet Draft (work in Support of Generalized MPLS," Internet Draft (work in
progress), draft-ietf-ccamp-gmpls-routing-09.txt, progress), draft-ietf-ccamp-gmpls-routing-09.txt,
October 2003. October 2003.
[GMPLS-SONET-SDH] Mannie, E. and Papadimitriou, D. (Editors) et al., [GMPLS-SONET-SDH] Mannie, E. and Papadimitriou, D. (Editors) et al.,
"Generalized Multiprotocol Label Switching Extensions "Generalized Multiprotocol Label Switching Extensions
D.Papadimitriou (Editor) et al. - Expires June 2004 16
for SONET and SDH Control," Internet Draft (work in for SONET and SDH Control," Internet Draft (work in
progress), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, progress), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt,
February 2003. February 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997. Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., et al., "Resource ReSerVation Protocol [RFC2205] Braden, R., et al., "Resource ReSerVation Protocol
(RSVP) -- Version 1 Functional Specification," RFC (RSVP) -- Version 1 Functional Specification," RFC
2205, September 1997. 2205, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services," RFC 2210, September 1997 Services," RFC 2210, September 1997.
[RFC3036] Andersson, L. et al., "LDP Specification," RFC 3036,
January 2001.
[RFC3209] Awduche, D. et al., "RSVP-TE: Extensions to RSVP for [RFC3209] Awduche, D. et al., "RSVP-TE: Extensions to RSVP for
LSP Tunnels," RFC 3209, December 2001. LSP Tunnels," RFC 3209, December 2001.
[RFC3212] Jamoussi, B. (Editor) et al., "Constraint-Based LSP
Setup using LDP," RFC 3212, January 2002.
[RFC3471] Berger, L. (Editor) et al., "Generalized Multi- [RFC3471] Berger, L. (Editor) et al., "Generalized Multi-
Protocol Label Switching (GMPLS) Signaling - Protocol Label Switching (GMPLS) Signaling -
Functional Description," RFC 3471, January 2003. Functional Description," RFC 3471, January 2003.
[RFC3472] Berger, L. (Editor) et al., "Generalized Multi-
Protocol Label Switching (GMPLS) Signaling -
Constraint-based Routed Label Distribution Protocol
(CR-LDP) Extensions," RFC 3472, January 2003.
[RFC3473] Berger, L. (Editor) et al., "Generalized Multi- [RFC3473] Berger, L. (Editor) et al., "Generalized Multi-
Protocol Label Switching (GMPLS) Signaling Resource Protocol Label Switching (GMPLS) Signaling Resource
ReserVation Protocol-Traffic Engineering (RSVP-TE) ReserVation Protocol-Traffic Engineering (RSVP-TE)
Extensions," RFC 3473, January 2003. Extensions," RFC 3473, January 2003.
12. Contributors 12. Contributors
Alberto Bellato (Alcatel) Alberto Bellato (Alcatel)
Via Trento 30, Via Trento 30,
I-20059 Vimercate, Italy I-20059 Vimercate, Italy
Email: alberto.bellato@alcatel.it Email: alberto.bellato@alcatel.it
Sudheer Dharanikota (Consult) Sudheer Dharanikota (Consult)
Email: sudheer@ieee.org Email: sudheer@ieee.org
Michele Fontana (Alcatel) Michele Fontana (Alcatel)
Via Trento 30, Via Trento 30,
I-20059 Vimercate, Italy I-20059 Vimercate, Italy
Email: michele.fontana@alcatel.it Email: michele.fontana@alcatel.it
D.Papadimitriou (Editor) et al. - Expires June 2004 16
Nasir Ghani (Sorrento Networks) Nasir Ghani (Sorrento Networks)
D.Papadimitriou (Editor) et al. - Expires June 2004 17
9990 Mesa Rim Road, 9990 Mesa Rim Road,
San Diego, CA 92121, USA San Diego, CA 92121, USA
Email: nghani@sorrentonet.com Email: nghani@sorrentonet.com
Gert Grammel (Alcatel) Gert Grammel (Alcatel)
Lorenzstrasse, 10, Lorenzstrasse, 10,
70435 Stuttgart, Germany 70435 Stuttgart, Germany
Email: gert.grammel@alcatel.de Email: gert.grammel@alcatel.de
Dan Guo (Turin Networks) Dan Guo (Turin Networks)
skipping to change at line 972 skipping to change at line 919
Email: yong.xue@wcom.com Email: yong.xue@wcom.com
13. Author's Address 13. Author's Address
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
D.Papadimitriou (Editor) et al. - Expires June 2004 18 D.Papadimitriou (Editor) et al. - Expires June 2004 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 Connection FICON Fiber Connection
skipping to change at line 1028 skipping to change at line 975
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 (Editor) et al. - Expires June 2004 19 D.Papadimitriou (Editor) et al. - Expires June 2004 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 1050 skipping to change at line 997
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 (Editor) et al. - Expires June 2004 20 D.Papadimitriou (Editor) et al. - Expires June 2004 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 1079 skipping to change at line 1026
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 (Editor) et al. - Expires June 2004 21 D.Papadimitriou (Editor) et al. - Expires June 2004 20
 End of changes. 

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