draft-ietf-ccamp-gmpls-g709-06.txt   draft-ietf-ccamp-gmpls-g709-07.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: September 2004 March 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-06.txt draft-ietf-ccamp-gmpls-g709-07.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.
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
six months and may be updated, replaced, or obsoleted by other six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts documents at any time. It is inappropriate to use Internet- Drafts
as reference material or to cite them other than as "work in as reference material or to cite them other than as "work in
progress." progress."
skipping to change at line 41 skipping to change at line 40
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document is a companion to the Generalized MPLS (GMPLS) This document is a companion to the Generalized MPLS (GMPLS)
signalling documents. It describes the technology specific signalling documents. It describes the technology specific
information needed to extend GMPLS signalling to control Optical information needed to extend GMPLS signalling to control Optical
Transport Networks (OTN); it also includes the so-called pre-OTN Transport Networks (OTN); it also includes the so-called pre-OTN
developments. developments.
*** DISCLAIMER *** *** Note on ITU-T G.709 Recommendation ***
In this document, the presented views on ITU-T G.709 OTN The views on the ITU-T G.709 OTN Recommendation presented in this
Recommendation (and referenced) are intentionally restricted as document are intentionally restricted to the GMPLS perspective
needed from the GMPLS perspective within the IETF CCAMP WG context. 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).
D.Papadimitriou (Editor) et al. - Expires June 2004 1 D.Papadimitriou (Editor) et al. - Expires September 2004 1
Table of Content Table of Contents
Status of this Memo ............................................. 1 Status of this Memo ............................................. 1
Abstract ........................................................ 1 Abstract ........................................................ 1
Table of Content ................................................ 2 Table of Contents ............................................... 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 ........................................ 4 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) .................................. 5 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) ....................... 8 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 ........................................... 9 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. RSVP-TE Signalling Protocol Extensions ...................... 14 6. RSVP-TE Signalling Protocol Extensions ...................... 13
7. Security Considerations ..................................... 14 7. Security Considerations ..................................... 14
8. IANA Considerations ......................................... 14 8. IANA Considerations ......................................... 14
9. Acknowledgments ............................................. 15 9. Acknowledgments ............................................. 15
10. Intellectual Property Notice ............................... 15 10. Intellectual Property Notice ............................... 15
11. References ................................................. 15 11. References ................................................. 15
11.1 Normative References ...................................... 15 11.1 Normative References ...................................... 15
12. Contributors ............................................... 16 11.2 Informative References .................................... 16
13. Author's Address ........................................... 17 12. Contributors ............................................... 17
Appendix 1 - Abbreviations ..................................... 18 13. Editor's Address ........................................... 18
Appendix 2 - G.709 Indexes ..................................... 18 Appendix 1 - Abbreviations ..................................... 19
Full Copyright Statement ....................................... 20 Appendix 2 - G.709 Indexes ..................................... 19
Full Copyright Statement ....................................... 21
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], and terminology used in ITU-T [ITUT-G709] as well as [RFC3471], and
[RFC3473]. Abbreviations used in this document are detailed in [RFC3473]. Abbreviations used in this document are detailed in
Appendix 1. Appendix 1.
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
D.Papadimitriou (Editor) et al. - Expires June 2004 2 D.Papadimitriou (Editor) et al. - Expires September 2004 2
Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch
(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 the RSVP- switching is provided in [RFC3471]. [RFC3473] describes the RSVP-
TE specific formats and mechanisms needed to support all four TE specific formats and mechanisms needed to support all four
classes of interfaces. 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
skipping to change at line 145 skipping to change at line 145
[GMPLS-SONET-SDH]. [GMPLS-SONET-SDH].
2. GMPLS Extensions for G.709 - Overview 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
(Optical Channel) and the ODUk (Optical Channel Data Unit) layers (Optical Channel) and the ODUk (Optical Channel Data Unit) layers
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 (also referred to
to as the non-associated overhead naOH) in the OTM Overhead Signal 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-G709] supports ODUk
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 D.Papadimitriou (Editor) et al. - Expires September 2004 3
Therefore, adapting GMPLS to control G.709 OTN, can be achieved by Adapting GMPLS to control G.709 OTN, can be achieved by creating:
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 [RFC3471] 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 [RFC3471] 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
ODUk multiplexing structure. ODUk multiplexing structure.
Thus, the GMPLS signalling extensions for G.709 need to cover the Thus, the GMPLS signalling extensions for G.709 need to cover the
Generalized Label Request, the Generalized Label as well as the Generalized Label Request, the Generalized Label as well as the
specific technology dependent objects included in the so-called specific technology dependent objects included in the so-called
traffic parameters as specified in [GMPLS-SONET-SDH] for SONET/SDH traffic parameters as specified in [GMPLS-SONET-SDH] for SONET/SDH
networks. Moreover, since the multiplexing in the digital domain networks. Moreover, since multiplexing in the digital domain (such
(such as ODUk multiplexing) has been specified in the amended as ODUk multiplexing) has been specified in the amended version of
version of the G.709 ITU-T recommendation (October 2001), this the G.709 ITU-T recommendation (October 2001), this document also
document also proposes a label space definition suitable for that proposes a label space definition suitable for that purpose. Notice
purpose. Notice also that one directly uses the G.709 ODUk (i.e. also that one uses the G.709 ODUk (i.e. Digital Path) and OCh (i.e.
Digital Path) and OCh (i.e. Optical Path) layers in order to define Optical Path) layers directly in order to define the corresponding
the corresponding label spaces. label spaces.
3. Generalized Label Request 3. Generalized Label Request
The Generalized Label Request as defined in [RFC3471], includes a The Generalized Label Request as defined in [RFC3471], 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, 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 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 GENERALIZED_LABEL_REQUEST The encoding of the corresponding RSVP-TE GENERALIZED_LABEL_REQUEST
object is specified in [RFC3473] Section 2.1. object is specified in [RFC3473] Section 2.1.
As mentioned here above, this document extends the LSP Encoding As mentioned above, this document extends the LSP Encoding Type, the
Type, Switching Type and G-PID (Generalized-PID) values to Switching Type and G-PID (Generalized-PID) values to accommodate
accommodate G.709 recommendation [ITUT-G709]. G.709 recommendation [ITUT-G709].
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 D.Papadimitriou (Editor) et al. - Expires September 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 separate 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 separate code-points can replace the current
defined "Lambda" code-point: defined "Lambda" code-point:
- code-point for the G.709 Optical Channel layer - code-point for the G.709 Optical Channel layer
- code-point for the non-standard Lambda layer (also referred to - code-point for the non-standard Lambda layer (also referred to
as Lambda layer which includes the pre-OTN Optical Channel as Lambda layer which includes the pre-OTN Optical Channel
layer) layer)
Consequently, the following additional code-points for the LSP Consequently, the following additional code-points for the LSP
Encoding Type are defined: Encoding Type are defined:
Value Type Value Type
skipping to change at line 267 skipping to change at line 266
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.
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 D.Papadimitriou (Editor) et al. - Expires September 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 322 skipping to change at line 321
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
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 D.Papadimitriou (Editor) et al. - Expires September 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: Values 49 and 50 include 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
skipping to change at line 361 skipping to change at line 360
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 The RSVP-TE encoding of the G.709 traffic-parameters is detailed in
are detailed in Section 6. 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)
3 ODU3 (i.e. 40 Gbps) 3 ODU3 (i.e. 40 Gbps)
4 Reserved 4 Reserved (for future use)
D.Papadimitriou (Editor) et al. - Expires June 2004 7 D.Papadimitriou (Editor) et al. - Expires September 2004 7
5 Reserved 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 9-255 Reserved (for future use)
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)
- 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)
skipping to change at line 432 skipping to change at line 431
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.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 D.Papadimitriou (Editor) et al. - Expires September 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 LSPs i.e. values greater than zero, are only acceptable for
Signal Types. Therefore, it MUST be set to zero (NVC = 0) when ODUk Signal Types. Therefore, it MUST be set to zero (NVC = 0), and
requesting a G.709 OCh LSP and should be ignored when received. should be ignored when received, when a G.709 OCh LSP is requested.
3.2.4 Multiplier (MT) 3.2.4 Multiplier (MT)
The Multiplier field (16 bits) indicates the number of identical The Multiplier field (16 bits) indicates the number of identical
Elementary Signals or Composed Signals requested for the LSP i.e. Elementary Signals or Composed Signals requested for the LSP i.e.
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.
skipping to change at line 466 skipping to change at line 465
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 message (see Section 6). node MUST generate a PathErr message (see Section 6).
Zero is an invalid value for the MT field. If received, the node Zero is an invalid value for the MT field. If received, the node
MUST generate a PathErr message (see Section 6). 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 in row 3) are
are dedicated for future use. Reserved bits SHOULD be set to zero dedicated for future use. Reserved bits SHOULD be set to zero when
when sent and MUST be ignored when received. 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 GENERALIZED_LABEL [RFC3471]. The format of the corresponding RSVP-TE GENERALIZED_LABEL
object is specified in [RFC3473] Section 2.2. object is specified in [RFC3473] Section 2.2.
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].
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 D.Papadimitriou (Editor) et al. - Expires September 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 532 skipping to change at line 531
The specification of the fields t1, t2 and t3 self-consistently The specification of the fields t1, t2 and t3 self-consistently
characterizes the ODUk label space. The value space for the t1, t2 characterizes the ODUk label space. The value space for the t1, t2
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 an ODU2 signal that is not further sub-
divided.
- 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 an ODU3 signal that is not further sub-
- t3=2->17 indicates the tributary slot (t3th-1) used by the
D.Papadimitriou (Editor) et al. - Expires June 2004 10 D.Papadimitriou (Editor) et al. - Expires September 2004 10
divided.
- 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
skipping to change at line 593 skipping to change at line 594
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.
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
D.Papadimitriou (Editor) et al. - Expires September 2004 11
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
significance between two neighbors, and the receiver may need (in
some particular cases) to convert the received value into a value
that has local significance.
4.3 Optical Channel Label Space 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). Note that these identifiers do not cover OChr since (m = 1, 2 or 3). Note that these identifiers do not cover OChr since
the corresponding Connection Function (OChr-CF) between OTM- the corresponding Connection Function (OChr-CF) between OTM-
nr.m/OTM-0r.m is not defined in [ITUT-G798]. nr.m/OTM-0r.m is not defined in [ITUT-G798].
The OCh label space values are defined by either absolute values The OCh label space values are defined by either absolute values
skipping to change at line 649 skipping to change at line 645
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:
- 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.
D.Papadimitriou (Editor) et al. - Expires September 2004 12
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
skipping to change at line 703 skipping to change at line 699
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)
- 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)
D.Papadimitriou (Editor) et al. - Expires June 2004 13
6. RSVP-TE Signalling Protocol Extensions 6. RSVP-TE Signalling Protocol Extensions
D.Papadimitriou (Editor) et al. - Expires September 2004 13
This section specifies the [RFC3473] protocol extensions needed to This section specifies the [RFC3473] protocol extensions needed to
accommodate G.709 traffic parameters. accommodate G.709 traffic parameters.
The G.709 traffic parameters are carried in the G.709 SENDER_TSPEC The G.709 traffic parameters are carried in the G.709 SENDER_TSPEC
and FLOWSPEC objects. The same format is used both for and FLOWSPEC objects. The same format is used both 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 = 5 (TBA by IANA) - G.709 SENDER_TSPEC Object: Class = 12, C-Type = TBA
- G.709 FLOWSPEC Object: Class = 9, C-Type = 5 (TBA by IANA) - 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
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 749 skipping to change at line 744
Error/Bad Tspec value" indication (see [RFC2205]). Error/Bad Tspec value" indication (see [RFC2205]).
7. Security Considerations 7. Security Considerations
This draft introduces no new security considerations to [RFC3473]. This draft introduces no new security considerations to [RFC3473].
GMPLS security is described in section 11 of [RFC3471] and refers GMPLS security is described in section 11 of [RFC3471] and refers
to [RFC3209] for RSVP-TE. to [RFC3209] for RSVP-TE.
8. IANA Considerations 8. IANA Considerations
Three values have to be defined by IANA for this document: Two 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 = 5 - A G.709 SENDER_TSPEC object: Class = 12, C-Type = 5
(Suggested value, TBA) - see Section 6. (Suggested value, TBA) - see Section 6.
D.Papadimitriou (Editor) et al. - Expires June 2004 14
- A G.709 FLOWSPEC object: Class = 9, C-Type = 5 - A G.709 FLOWSPEC object: Class = 9, C-Type = 5
(Suggested value, TBA) - see Section 6. (Suggested value, TBA) - see Section 6.
D.Papadimitriou (Editor) et al. - Expires September 2004 14
IANA is also requested to track the code-point spaces extended
and/or updated by this document. That is:
- LSP Encoding Type
- Generalized PID (G-PID)
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. Many
thanks to Adrian Farrel for having thoroughly reviewing this
document.
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.
10. Intellectual Property Notice 10. Intellectual Property Consideration
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 Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology
this document or the extent to which any license under such rights described in this document or the extent to which any license
might or might not be available; neither does it represent that it under such rights might or might not be available; nor does it
has made any effort to identify any such rights. Information on the represent that it has made any independent effort to identify any
IETF's procedures with respect to rights in standards-track and such rights. Information on the procedures with respect to rights
standards-related documentation can be found in BCP-11. Copies of in RFC documents can be found in BCP 78 and BCP 79.
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 Copies of IPR disclosures made to the IETF Secretariat and any
copyrights, patents or patent applications, or other proprietary assurances of licenses to be made available, or the result of an
rights which may cover technology that may be required to practice attempt made to obtain a general license or permission for the use
this standard. Please address the information to the IETF Executive of such proprietary rights by implementers or users of this
Director. specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
10.1 IPR Disclosure Acknowledgement
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3668.
11. References 11. References
11.1 Normative References 11.1 Normative References
D.Papadimitriou (Editor) et al. - Expires September 2004 15
[ITUT-G707] ITU-T, "Network node interface for the synchronous [ITUT-G707] ITU-T, "Network node interface for the synchronous
digital hierarchy (SDH)," G.707 Recommendation, October digital hierarchy (SDH)," G.707 Recommendation, October
2000. 2000.
[ITUT-G709] ITU-T, "Interface for the Optical Transport Network [ITUT-G709] ITU-T, "Interface for the Optical Transport Network
(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
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
Label Switching (GMPLS) Architecture," Internet Draft
(work in progress), draft-ietf-ccamp-gmpls-
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
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.
[RFC2026] S.Bradner, "The Internet Standards Process -- Revision
3," BCP 9, RFC 2026, October 1996.
[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.
skipping to change at line 852 skipping to change at line 858
[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.
[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.
11.2 Informative References
[GMPLS-ARCH] Mannie, E. (Editor) et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Architecture," Internet Draft
D.Papadimitriou (Editor) et al. - Expires September 2004 16
(work in progress), draft-ietf-ccamp-gmpls-
architecture-07.txt, May 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)
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
skipping to change at line 903 skipping to change at line 917
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
Email: zwlin@lucent.com Email: zwlin@lucent.com
Eric Mannie (Consult) Eric Mannie (Consult)
Email: eric_mannie@hotmail.com Email: eric_mannie@hotmail.com
Maarten Vissers (Alcatel) Maarten Vissers (Alcatel)
Lorenzstrasse, 10, Lorenzstrasse, 10,
D.Papadimitriou (Editor) et al. - Expires September 2004 17
70435 Stuttgart, Germany 70435 Stuttgart, Germany
Email: maarten.vissers@alcalel.de Email: maarten.vissers@alcalel.de
Yong Xue (WorldCom) Yong Xue (WorldCom)
22001 Loudoun County Parkway, 22001 Loudoun County Parkway,
Ashburn, VA 20147, USA Ashburn, VA 20147, USA
Email: yong.xue@wcom.com Email: yong.xue@wcom.com
13. Author's Address 13. Editor'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 17 D.Papadimitriou (Editor) et al. - Expires September 2004 18
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 975 skipping to change at line 991
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 18 D.Papadimitriou (Editor) et al. - Expires September 2004 19
. 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
of wavelengths that can be supported at the lowest bit rate of wavelengths that can be supported at the lowest bit rate
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 19 D.Papadimitriou (Editor) et al. - Expires September 2004 20
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. Copyright (C) The Internet Society (2004). This document is subject
This document and translations of it may be copied and furnished to to the rights, licenses and restrictions contained in BCP 78 and
others, and derivative works that comment on or otherwise explain it except as set forth therein, the authors retain all their rights.
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein are provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF IMPLIED,INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
D.Papadimitriou (Editor) et al. - Expires June 2004 20 D.Papadimitriou (Editor) et al. - Expires September 2004 21
 End of changes. 

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