draft-ietf-ccamp-gmpls-g709-08.txt   draft-ietf-ccamp-gmpls-g709-09.txt 
CCAMP Working Group D. Papadimitriou - Editor CCAMP Working Group D. Papadimitriou - Editor
Internet Draft (Alcatel) Internet Draft (Alcatel)
Updates RFC 3471
Category: Standard Track Category: Standard Track
Expiration Date: March 2005 September 2004 Expiration Date: June 2005 January 2005
Generalized MPLS (GMPLS) Signaling Extensions Generalized MPLS (GMPLS) Signaling Extensions
for G.709 Optical Transport Networks Control for G.709 Optical Transport Networks Control
draft-ietf-ccamp-gmpls-g709-08.txt draft-ietf-ccamp-gmpls-g709-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, I certify that any applicable By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed, 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 and any of which I become aware will be disclosed, in accordance
with RFC 3668. with RFC 3668.
Working documents of the Internet Engineering Task Force (IETF), its Working documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
skipping to change at line 46 skipping to change at line 47
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This document is a companion to the Generalized MPLS (GMPLS) This document is a companion to the Generalized MPLS (GMPLS)
signaling documents. It describes the technology specific signaling documents. It describes the technology specific
information needed to extend GMPLS signaling to control Optical information needed to extend GMPLS signaling 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.
*** Note on ITU-T G.709 Recommendation *** D.Papadimitriou (Editor) et al. - Expires June 2005 1
The views on the ITU-T G.709 OTN Recommendation presented in this
document are intentionally restricted to the GMPLS perspective
within the IETF CCAMP WG context. Hence, the objective of this
document is not to replicate the content of the ITU-T OTN
recommendations. Therefore, the reader interested in more details
concerning the corresponding technologies is strongly invited to
D.Papadimitriou (Editor) et al. - Expires March 2005 1
consult the corresponding ITU-T documents (also referenced in this
memo).
Table of Contents Table of Contents
Status of this Memo ............................................. 1 Status of this Memo ............................................. 1
Abstract ........................................................ 1 Abstract ........................................................ 1
Table of Contents ............................................... 2 Table of Contents ............................................... 2
Conventions used in this Document ............................... 2 Conventions used in this Document ............................... 2
1. Introduction ................................................. 3 1. Introduction ................................................. 3
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 .................................... 5
3.1 Technology Independent Part ................................. 4 3.1 Common Part ................................................. 5
3.1.1. LSP Encoding Type ........................................ 4 3.1.1. LSP Encoding Type ........................................ 5
3.1.2. Switching-Type ........................................... 5 3.1.2. Switching-Type ........................................... 6
3.1.3. Generalized-PID (G-PID) .................................. 6 3.1.3. Generalized-PID (G-PID) .................................. 6
3.2. G.709 Traffic-Parameters ................................... 7 3.2. G.709 Traffic-Parameters ................................... 7
3.2.1. Signal Type (ST).......................................... 8 3.2.1. Signal Type (ST).......................................... 8
3.2.2. Number of Multiplexed Components (NMC) ................... 8 3.2.2. Number of Multiplexed Components (NMC) ................... 9
3.2.3. Number of Virtual Components (NVC) ....................... 9 3.2.3. Number of Virtual Components (NVC) ....................... 9
3.2.4. Multiplier (MT) .......................................... 9 3.2.4. Multiplier (MT) .......................................... 9
3.2.5. Reserved Fields .......................................... 9 3.2.5. Reserved Fields ......................................... 10
4. Generalized Label ........................................... 10 4. Generalized Label ........................................... 10
4.1. ODUk Label Space .......................................... 10 4.1. ODUk Label Space .......................................... 10
4.2. Label Distribution Rules .................................. 11 4.2. Label Distribution Rules .................................. 12
4.3. OCh Label Space ........................................... 12 4.3. OCh Label Space ........................................... 13
5. Examples .................................................... 13 5. Examples .................................................... 13
6. RSVP-TE Signaling Protocol Extensions ....................... 14 6. RSVP-TE Signaling Protocol Extensions ....................... 15
7. Security Considerations ..................................... 15 7. Security Considerations ..................................... 15
8. IANA Considerations ......................................... 15 8. IANA Considerations ......................................... 15
9. Acknowledgments ............................................. 16 9. Acknowledgments ............................................. 16
10. Intellectual Property Notice ............................... 16 10. References ................................................. 17
11. References ................................................. 17 10.1 Normative References ...................................... 17
11.1 Normative References ...................................... 17 10.2 Informative References .................................... 17
11.2 Informative References .................................... 18 11. Contributors ............................................... 18
12. Contributors ............................................... 18 12. Editor's Address ........................................... 19
13. Editor's Address ........................................... 19
Appendix 1 - Abbreviations ..................................... 20 Appendix 1 - Abbreviations ..................................... 20
Appendix 2 - G.709 Indexes ..................................... 20 Appendix 2 - G.709 Indexes ..................................... 20
Full Copyright Statement ....................................... 22 Intellectual Property Statement ................................ 22
Disclaimer of Validity ......................................... 22
Copyright Statement ............................................ 22
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.
D.Papadimitriou (Editor) et al. - Expires March 2005 2 D.Papadimitriou (Editor) et al. - Expires June 2005 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 four new classes of interfaces and switching: Layer-2 support of four new classes of interfaces and switching: Layer-2
Switching (L2SC), Time-Division Multiplex (TDM), Lambda Switch Switching (L2SC), Time-Division Multiplex (TDM), Lambda Switch
(LSC) and Fiber-Switch (FSC) Capable. A functional description of (LSC) and Fiber-Switch (FSC) Capable. A functional description of
the extensions to MPLS signaling needed to support these new the extensions to MPLS signaling needed to support these new
classes of interfaces and switching is provided in [RFC3471]. classes of interfaces and switching is provided in [RFC3471].
skipping to change at line 134 skipping to change at line 125
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
document. Moreover, the label MUST be encoded as defined in document. Moreover, the label MUST be encoded as defined in
Section 4 when these G.709 traffic parameters are used. Section 4 when these G.709 traffic parameters are used.
Note: in the context of this memo, by pre-OTN developments, one In the context of this memo, by pre-OTN developments, one refers
refers to Optical Channel, Digital Wrapper and Forward Error to Optical Channel, Digital Wrapper and Forward Error Correction
Correction (FEC) solutions that are not fully G.709 compliant. (FEC) solutions that are not fully G.709 compliant. Details
Details concerning pre-OTN Synchronous Optical Network (SONET)/ concerning pre-OTN Synchronous Optical Network (SONET)/
Synchronous Digital Hierarchy (SDH) based solutions including Synchronous Digital Hierarchy (SDH) based solutions including
Optical Sections (OS), Regenerator Section (RS)/Section and Optical Sections (OS), Regenerator Section (RS)/Section and
Multiplex Section (MS)/ Line overhead transparency are covered in Multiplex Section (MS)/ Line overhead transparency are covered in
[GMPLS-SONET-SDH]. [RFC3946].
*** Note on ITU-T G.709 Recommendation ***
The views on the ITU-T G.709 OTN Recommendation presented in this
document are intentionally restricted to the GMPLS perspective
within the IETF CCAMP WG context. Hence, the objective of this
document is not to replicate the content of the ITU-T OTN
recommendations. Therefore, the reader interested in more details
concerning the corresponding technologies is strongly invited to
consult the corresponding ITU-T documents (also referenced in this
memo).
2. GMPLS Extensions for G.709 - Overview 2. GMPLS Extensions for G.709 - Overview
Although G.709 defines several networking layers (OTS, OMS, OPS, [ITUT-G.709] defines several networking layers constituting the
OCh, OChr constituting the optical transport hierarchy and OTUk, optical transport hierarchy:
ODUk constituting the digital transport hierarchy) only the OCh - with full functionality:
(Optical Channel) and the ODUk (Optical Channel Data Unit) layers . Optical Transmission Section (OTS)
are defined as switching layers. Both OCh (but not OChr) and ODUk . Optical Multiplex Section (OMS)
layers include the overhead for supervision and management. The OCh . Optical Channel (OCh)
overhead is transported in a non-associated manner (also referred to - with reduced functionality:
as the non-associated overhead naOH) in the OTM Overhead Signal
D.Papadimitriou (Editor) et al. - Expires June 2005 3
. Optical Physical Section (OPS)
. Optical Channel with reduced functionality (OChr)
It also defines two layers constituting the digital transport
hierarchy:
- Optical Channel Data Unit (OTUk)
- Optical Channel Data Unit (ODUk)
However, only the OCh and the ODUk layers are defined as switching
layers. Both OCh (but not OChr) and ODUk layers include the overhead
for supervision and management. The OCh overhead is transported in a
non-associated manner (also referred to as the non-associated
overhead naOH) in the Optical Transport Module (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-G709] supports ODUk mapping into OTUk (k = 1, 2, 3), G.709 supports ODUk multiplexing.
It refers to the multiplexing of ODUj (j = 1, 2) into an ODUk (k >
D.Papadimitriou (Editor) et al. - Expires March 2005 3 j) signal, in particular:
multiplexing. It refers to the multiplexing of ODUj (j = 1, 2) into
an ODUk (k > j) signal, in particular:
- ODU1 into ODU2 multiplexing - ODU1 into 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
Adapting GMPLS to control G.709 OTN, can be achieved by creating: Adapting GMPLS to control G.709 OTN, can be achieved by creating:
- a Digital Path layer by extending the previously defined - a Digital Path layer by extending the previously defined
"Digital Wrapper" in [RFC3471] 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 [RFC3471] 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 signaling extensions for G.709 need to cover the Thus, the GMPLS signaling 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 [RFC3946] for SONET/SDH networks.
networks. Moreover, since multiplexing in the digital domain (such Moreover, since multiplexing in the digital domain (such as ODUk
as ODUk multiplexing) has been specified in the amended version of multiplexing) has been specified in the amended version of the G.709
the G.709 ITU-T recommendation (October 2001), this document also ITU-T recommendation (October 2001), this document also proposes a
proposes a label space definition suitable for that purpose. Notice label space definition suitable for that purpose. Notice also that
also that one uses the G.709 ODUk (i.e. Digital Path) and OCh (i.e. one uses the G.709 ODUk (i.e. Digital Path) and OCh (i.e. Optical
Optical Path) layers directly in order to define the corresponding Path) layers directly in order to define the corresponding label
label spaces. spaces.
D.Papadimitriou (Editor) et al. - Expires June 2005 4
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. common part (i.e. used for any switching technology) and a
the traffic parameters). In this section, both parts are extended to technology dependent part (i.e. the traffic parameters). In this
accommodate GMPLS Signaling to the G.709 transport plane section, both parts are extended to accommodate GMPLS Signaling to
recommendation (see [ITUT-G709]). the G.709 transport plane recommendation (see [ITUT-G709]).
3.1 Technology Independent Part 3.1 Common 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 common part of the Generalized Label Request. The encoding of
The encoding of the RSVP-TE GENERALIZED_LABEL_REQUEST object is the RSVP-TE GENERALIZED_LABEL_REQUEST object is specified in
specified in [RFC3473] Section 2.1. [RFC3473] Section 2.1.
As mentioned above, this document extends the LSP Encoding Type, the As mentioned above, this document extends the LSP Encoding Type, the
Switching Type and G-PID (Generalized-PID) values to accommodate Switching Type and G-PID (Generalized-PID) values to accommodate
G.709 Recommendation [ITUT-G709]. G.709 Recommendation [ITUT-G709].
3.1.1 LSP Encoding Type 3.1.1 LSP Encoding Type
D.Papadimitriou (Editor) et al. - Expires March 2005 4
Since G.709 Recommendation defines two networking layers (ODUk Since G.709 Recommendation defines two networking layers (ODUk
layers and OCh layer), the LSP Encoding Type code-points can reflect layers and OCh layer), the LSP Encoding Type code-points can reflect
these two layers defined in [RFC3471] Section 3.1 as "Digital these two layers defined in [RFC3471] Section 3.1 as "Digital
Wrapper" and "Lambda" code. The LSP Encoding Type is specified per Wrapper" and "Lambda" code. The LSP Encoding Type is specified per
networking layer or more precisely per group of functional networking layer or more precisely per group of functional
networking layer: the ODUk layers and the OCh layer. networking layer: the ODUk layers and the OCh layer.
Therefore, an additional LSP Encoding Type code-point for the G.709 Therefore, an additional LSP Encoding Type code-point for the G.709
Digital Path layer is defined that enlarges the existing "Digital Digital Path layer is defined that enlarges the existing "Digital
Wrapper" code-point defined in [RFC3471]. The former MUST be Wrapper" code-point defined in [RFC3471]. The former MUST be
skipping to change at line 248 skipping to change at line 263
"Lambda" code-point defined in [RFC3471]. The former MUST be "Lambda" code-point defined in [RFC3471]. The former MUST be
generated when the interface or tunnel on which the traffic will be generated when the interface or tunnel on which the traffic will be
transmitted supports G.709 compliant Optical Channel layer encoding. transmitted supports G.709 compliant Optical Channel layer encoding.
The latter MUST only be used for non-G.709 compliant Lambda layer(s) The latter MUST only be used for non-G.709 compliant Lambda layer(s)
encoding. A transit or an egress node (receiving a Path message encoding. A transit or an egress node (receiving a Path message
containing a GENERALIZED_LABEL_REQUEST object) MUST generate a containing a GENERALIZED_LABEL_REQUEST object) MUST generate a
PathErr message, with a "Routing problem/Unsupported Encoding" PathErr message, with a "Routing problem/Unsupported Encoding"
indication, if the requested LSP Encoding Type cannot be supported indication, if the requested LSP Encoding Type cannot be supported
on the corresponding incoming interface. on the corresponding incoming interface.
D.Papadimitriou (Editor) et al. - Expires June 2005 5
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
----- ---- ----- ----
12 G.709 ODUk (Digital Path) 12 G.709 ODUk (Digital Path)
13 G.709 Optical Channel 13 G.709 Optical Channel
Moreover, the code-point for the G.709 Optical Channel (OCh) layer Moreover, the code-point for the G.709 Optical Channel (OCh) layer
will indicate the requested capability of an end-system to use the will indicate the requested capability of an end-system to use the
skipping to change at line 271 skipping to change at line 287
3.1.2 Switching Type 3.1.2 Switching Type
The Switching Type indicates the type of switching that should be The Switching Type indicates the type of switching that should be
performed at the termination of a particular link (see [GMPLS-RTG]). performed at the termination of a particular link (see [GMPLS-RTG]).
No additional Switching Type values are to be considered in order to No additional Switching Type 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).
D.Papadimitriou (Editor) et al. - Expires March 2005 5
Intermediate and egress nodes MUST verify that the value indicated Intermediate and egress nodes MUST verify that the value indicated
in the Switching Type field is supported on the corresponding in the Switching Type field is supported on the corresponding
incoming interface. If the requested value can not be supported, the incoming interface. If the requested value can not be supported, the
node MUST generate a PathErr message with a "Routing problem/ node MUST generate a PathErr message with a "Routing problem/
Switching Type" indication. Switching Type" indication.
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
skipping to change at line 301 skipping to change at line 316
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.
Mapping of 2.5, 10 and 40 Gbps Bit Stream Mapping of 2.5, 10 and 40 Gbps Bit Stream
- BSNT: non-specific client Bit Stream without Octet Timing i.e. - BSNT: non-specific client Bit Stream without Octet Timing i.e.
Mapping of 2.5, 10 and 40 Gbps Bit Stream Mapping of 2.5, 10 and 40 Gbps Bit Stream
- ODUk: transport of Digital Paths at 2.5, 10 and 40 Gbps - ODUk: transport of Digital Paths at 2.5, 10 and 40 Gbps
- ESCON: Enterprise Systems Connection - ESCON: Enterprise Systems Connection
- FICON: Fiber Connection - FICON: Fiber Connection
D.Papadimitriou (Editor) et al. - Expires June 2005 6
The G-PID can take one of the following values when the client The G-PID can take one of the following values when the client
payload is transported over the Optical Channel layer, in addition payload is transported over the Optical Channel layer, in addition
to the payload identifiers defined in [RFC3471]: to the payload identifiers defined in [RFC3471]:
- CBR: Constant Bit Rate i.e. mapping of STM-16/OC-48, STM-64/OC-192 - CBR: Constant Bit Rate i.e. mapping of STM-16/OC-48, STM-64/OC-192
and STM-256/OC-768 and STM-256/OC-768
- OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps - OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps
Also, when client payloads such as Ethernet MAC/PHY and IP/PPP are Also, when client payloads such as Ethernet MAC/PHY and IP/PPP are
encapsulated through the Generic Framing Procedure (GFP) as encapsulated through the Generic Framing Procedure (GFP) as
described in ITU-T G.7041, dedicated G-PID values are defined. described in ITU-T G.7041, dedicated G-PID values are defined.
In order to include pre-OTN developments, the G-PID field can take In order to include pre-OTN developments, the G-PID field can take
one of the values (currently defined in [RFC3471]) when the one of the values (currently defined in [RFC3471]) when the
skipping to change at line 317 skipping to change at line 332
- OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps - OTUk/OTUkV: transport of Digital Section at 2.5, 10 and 40 Gbps
Also, when client payloads such as Ethernet MAC/PHY and IP/PPP are Also, when client payloads such as Ethernet MAC/PHY and IP/PPP are
encapsulated through the Generic Framing Procedure (GFP) as encapsulated through the Generic Framing Procedure (GFP) as
described in ITU-T G.7041, dedicated G-PID values are defined. described in ITU-T G.7041, dedicated G-PID values are defined.
In order to include pre-OTN developments, the G-PID field can take In order to include pre-OTN developments, the G-PID field can take
one of the values (currently defined in [RFC3471]) when the one of the values (currently defined in [RFC3471]) when the
following client payloads are transported over a so-called lambda following client payloads are transported over a so-called lambda
LSP: LSP:
- Ethernet PHY (1 Gbps and 10 Gbps) - Ethernet PHY (1 Gbps and 10 Gbps)
- Fiber Channel - Fiber Channel
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:
D.Papadimitriou (Editor) et al. - Expires March 2005 6
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
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)
skipping to change at line 357 skipping to change at line 370
----- ---------- ----------------- ----- ---------- -----------------
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
D.Papadimitriou (Editor) et al. - Expires June 2005 7
to as technology dependent (or simply traffic parameters) is carried to as technology dependent (or simply traffic parameters) is carried
additionally to the one included in the Generalized Label Request. additionally to the one included in the Generalized Label Request.
The G.709 traffic parameters are 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at line 379 skipping to change at line 394
| 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 of the G.709 traffic-parameters is detailed in The RSVP-TE encoding of the G.709 traffic-parameters is detailed in
Section 6. Section 6.
D.Papadimitriou (Editor) et al. - Expires March 2005 7
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 Not significant
1 ODU1 (i.e. 2.5 Gbps) 1 ODU1 (i.e. 2.5 Gbps)
2 ODU2 (i.e. 10 Gbps) 2 ODU2 (i.e. 10 Gbps)
3 ODU3 (i.e. 40 Gbps) 3 ODU3 (i.e. 40 Gbps)
4 Reserved (for future use) 4 Reserved (for future use)
5 Reserved (for future use) 5 Reserved (for future use)
6 OCh at 2.5 Gbps 6 OCh at 2.5 Gbps
7 OCh at 10 Gbps 7 OCh at 10 Gbps
8 OCh at 40 Gbps 8 OCh at 40 Gbps
9-255 Reserved (for future use) 9-255 Reserved (for future use)
skipping to change at line 411 skipping to change at line 424
- if the LSP Encoding Type value is the G.709 Digital Path layer - if the LSP Encoding Type value is the G.709 Digital Path layer
then the valid values are the ODUk signals (k = 1, 2 or 3) then the valid values are the ODUk signals (k = 1, 2 or 3)
- if the LSP Encoding Type value is the G.709 Optical Channel layer - if the LSP Encoding Type value is the G.709 Optical Channel layer
then the valid values are the OCh at 2.5, 10 or 40 Gbps then the valid values are the OCh at 2.5, 10 or 40 Gbps
- if the LSP Encoding Type is "Lambda" (which includes the - if the LSP Encoding Type is "Lambda" (which includes the
pre-OTN Optical Channel layer) then the valid value is irrelevant pre-OTN Optical Channel layer) then the valid value is irrelevant
(Signal Type = 0) (Signal Type = 0)
- if the LSP Encoding Type is "Digital Wrapper", then the valid - if the LSP Encoding Type is "Digital Wrapper", then the valid
value is irrelevant (Signal Type = 0) value is irrelevant (Signal Type = 0)
D.Papadimitriou (Editor) et al. - Expires June 2005 8
Several transforms can be sequentially applied on the Elementary Several transforms can be sequentially applied on the Elementary
Signal to build the Final Signal being actually requested for the Signal to build the Final Signal being actually requested for the
LSP. Each transform application is optional and must be ignored if LSP. Each transform application is optional and must be ignored if
zero, except the Multiplier (MT) that cannot be zero and must be zero, except the Multiplier (MT) that cannot be zero and must be
ignored if equal to one. Transforms must be applied strictly in the ignored if equal to one. Transforms must be applied strictly in the
following order: following order:
- First, virtual concatenation (by using the NVC field) can - First, virtual concatenation (by using the NVC field) can
be optionally applied directly on the Elementary Signal to form a be optionally applied directly on the Elementary Signal to form a
Composed Signal Composed Signal
- Second, a multiplication (by using the Multiplier field) can be - Second, a multiplication (by using the Multiplier field) can be
skipping to change at line 434 skipping to change at line 448
3.2.2 Number of Multiplexed Components (NMC) 3.2.2 Number of Multiplexed Components (NMC)
The NMC field (16 bits) indicates the number of ODU tributary slots The NMC field (16 bits) indicates the number of ODU tributary slots
used by an ODUj when multiplexed into an ODUk (k > j) for the used by an ODUj when multiplexed into an ODUk (k > j) for the
requested LSP. This field is not applicable when an ODUk is mapped requested LSP. This field is not applicable when an ODUk is mapped
into an OTUk and irrelevant at the Optical Channel layer. In both into an OTUk and irrelevant at the Optical Channel layer. In both
cases, it MUST be set to zero (NMC = 0) when sent and should be cases, it MUST be set to zero (NMC = 0) when sent and should be
ignored when received. ignored when received.
D.Papadimitriou (Editor) et al. - Expires March 2005 8
When applied at the Digital Path layer, in particular for ODU2 When applied at the Digital Path layer, in particular for ODU2
connections multiplexed into one ODU3 payload, the NMC field connections multiplexed into one ODU3 payload, the NMC field
specifies the number of individual tributary slots (NMC = 4) specifies the number of individual tributary slots (NMC = 4)
constituting the requested connection. These components are still constituting the requested connection. These components are still
processed within the context of a single connection entity. For all processed within the context of a single connection entity. For all
other currently defined multiplexing cases (see Section 2), the NMC other currently defined multiplexing cases (see Section 2), the NMC
field is set to 1. field is set to 1.
3.2.3 Number of Virtual Components (NVC) 3.2.3 Number of Virtual Components (NVC)
skipping to change at line 465 skipping to change at line 478
ODUk LSPs i.e. values greater than zero, are only acceptable for ODUk LSPs i.e. values greater than zero, are only acceptable for
ODUk Signal Types. Therefore, it MUST be set to zero (NVC = 0), and ODUk Signal Types. Therefore, it MUST be set to zero (NVC = 0), and
should be ignored when received, when a G.709 OCh LSP is requested. 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
D.Papadimitriou (Editor) et al. - Expires June 2005 9
elementary Signal Type. GMPLS signaling currently implies that all elementary Signal Type. GMPLS signaling 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 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 in row 3) are The reserved fields (8 bits in row 1 and 32 bits in row 3) are
dedicated for future use. Reserved bits SHOULD be set to zero when dedicated for future use. Reserved bits SHOULD be set to zero when
sent and MUST be ignored when received. sent and MUST be ignored when received.
D.Papadimitriou (Editor) et al. - Expires March 2005 9
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 [RFC3946].
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
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
skipping to change at line 519 skipping to change at line 532
- ODU1 into ODU3 multiplexing - ODU1 into ODU3 multiplexing
- ODU2 into ODU3 multiplexing - ODU2 into ODU3 multiplexing
- ODU1 and ODU2 into ODU3 multiplexing - ODU1 and ODU2 into ODU3 multiplexing
More precisely, ODUj into ODUk multiplexing (k > j) is defined when More precisely, ODUj into ODUk multiplexing (k > j) is defined when
an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an an ODUj is multiplexed into an ODUk Tributary Unit Group (i.e. an
ODTUG constituted by ODU tributary slots) which is mapped into an ODTUG constituted by ODU tributary slots) which is mapped into an
OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is OPUk. The resulting OPUk is mapped into an ODUk and the ODUk is
mapped into an OTUk. mapped into an OTUk.
D.Papadimitriou (Editor) et al. - Expires June 2005 10
Therefore, the label space structure is a tree whose root is an OTUk Therefore, the label space structure is a tree whose root is an OTUk
signal and leaves the ODUj signals (k >= j) that can be transported signal and leaves the ODUj signals (k >= j) that can be transported
via the tributary slots and switched between these slots. A G.709 via the tributary slots and switched between these slots. A G.709
Digital Path layer label identifies the exact position of a Digital Path layer label identifies the exact position of a
particular ODUj signal in an ODUk multiplexing structure. particular ODUj signal in an ODUk multiplexing structure.
The G.709 Digital Path Layer label or ODUk label has the following The G.709 Digital Path Layer label or ODUk label has the following
format: format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | t3 | t2 |t1| | Reserved | t3 | t2 |t1|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reserved bits MUST be set to zero when sent and SHOULD be ignored Reserved bits MUST be set to zero when sent and SHOULD be ignored
when received. when received.
D.Papadimitriou (Editor) et al. - Expires March 2005 10
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 (i.e. - t1 is not significant for the other ODUk signal types (i.e.
t1 value SHOULD be set to 0). t1 value MUST be set to 0 and ignored).
2. t2 (3-bit): 2. t2 (3-bit):
- t2=1 indicates an ODU2 signal that is not further sub- - t2=1 indicates an ODU2 signal that is not further sub-
divided. 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 (i.e. t2 value SHOULD be - t2 is not significant for an ODU3 (i.e. t2 value MUST be
set to 0). set to 0 and ignored).
3. t3 (6-bit): 3. t3 (6-bit):
- t3=1 indicates an ODU3 signal that is not further sub- - t3=1 indicates an ODU3 signal that is not further sub-
divided. divided.
- t3=[2..17] indicates the tributary slot (t3th-1) used by the - t3=[2..17] indicates the tributary slot (t3th-1) used by the
ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3). ODU1 in an ODTUG3 mapped into an ODU3 (via OPU3).
- t3=[18..33] indicates the tributary slot (t3th-17) used by - t3=[18..33] indicates the tributary slot (t3th-17) used by
the ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3). the ODU2 in an ODTUG3 mapped into an ODU3 (via OPU3).
Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required Note: in case of ODU2 into ODU3 multiplexing, 4 labels are required
to identify the 4 tributary slots used by the ODU2; these tributary to identify the 4 tributary slots used by the ODU2; these tributary
time slots have to be allocated in ascending order. time slots have to be allocated in ascending order.
If the label sub-field value t[i]=1 (i, j = 1, 2 or 3) and t[j]=0 (j If the label sub-field value t[i]=1 (i, j = 1, 2 or 3) and t[j]=0 (j
> i), the corresponding ODUk signal ODU[i] is directly mapped into > i), the corresponding ODUk signal ODU[i] is directly mapped into
the corresponding OTUk signal (k=i). This is referred to as the the corresponding OTUk signal (k=i). This is referred to as the
mapping of an ODUk signal into an OTUk of the same order. Therefore, mapping of an ODUk signal into an OTUk of the same order. Therefore,
the numbering starts at 1; zero is used to indicate a non- the numbering starts at 1; zero is used to indicate a non-
significant field. A label field equal to zero is an invalid value. significant field. A label field equal to zero is an invalid value.
D.Papadimitriou (Editor) et al. - Expires June 2005 11
Examples: Examples:
- t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1 - t3=0, t2=0, t1=1 indicates an ODU1 mapped into an OTU1
- t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2 - t3=0, t2=1, t1=0 indicates an ODU2 mapped into an OTU2
- t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3 - t3=1, t2=0, t1=0 indicates an ODU3 mapped into an OTU3
- t3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot - t3=0, t2=3, t1=0 indicates the ODU1 in the second tributary slot
of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2 of the ODTUG2 mapped into an ODU2 (via OPU2) mapped into an OTU2
- t3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot - t3=5, t2=0, t1=0 indicates the ODU1 in the fourth tributary slot
of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3 of the ODTUG3 mapped into an ODU3 (via OPU3) mapped into an OTU3
4.2 Label Distribution Rules 4.2 Label Distribution Rules
In case of ODUk in OTUk mapping, only one of label can appear in the In case of ODUk in OTUk mapping, only one label can appear in the
Generalized Label. The unique label is encoded as a single 32 bit Generalized Label. The unique label is encoded as a single 32 bit
label value (as defined in Section 4.1) of the GENERALIZED_LABEL label value (as defined in Section 4.1) of the GENERALIZED_LABEL
object (Class-Num = 16, C-Type = 2). object (Class-Num = 16, C-Type = 2)
D.Papadimitriou (Editor) et al. - Expires March 2005 11
In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered In case of ODUj in ODUk (k > j) multiplexing, the explicit ordered
list of the labels in the multiplex is given (this list can be list of the labels in the multiplex is given (this list can be
restricted to only one label when NMC = 1). Each label indicates a restricted to only one label when NMC = 1). Each label indicates a
component (ODUj tributary slot) of the multiplexed signal. The order component (ODUj tributary slot) of the multiplexed signal. The order
of the labels must reflect the order of the ODUj into the multiplex of the labels must reflect the order of the ODUj into the multiplex
(not the physical order of tributary slots). This ordered list of (not the physical order of tributary slots). This ordered list of
labels is encoded as a sequence of 32 bit label values (as defined labels is encoded as a sequence of 32 bit label values (as defined
in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C- in Section 4.1) of the GENERALIZED_LABEL object (Class-Num = 16, C-
Type = 2). Type = 2).
skipping to change at line 627 skipping to change at line 640
additionally uses the NMC value to determine the number of labels additionally uses the NMC value to determine the number of labels
per set (equal in size). per set (equal in size).
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
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
D.Papadimitriou (Editor) et al. - Expires June 2005 12
of the second multiplexed virtually concatenated signal, and so on. of the second multiplexed virtually concatenated signal, and so on.
This ordered list of labels is encoded as a sequence of 32 bit label This ordered list of labels is encoded as a sequence of 32 bit label
values (as defined in Section 4.1) of the GENERALIZED_LABEL object values (as defined in Section 4.1) of the GENERALIZED_LABEL object
(Class-Num = 16, C-Type = 2). In case of multiplication of (equal) (Class-Num = 16, C-Type = 2). In case of multiplication of (equal)
ODUk virtual concatenated signals, the number of label values per ODUk virtual concatenated signals, the number of label values per
signal is determined by the NVC value. Multiplication of multiplexed signal is determined by the NVC value. Multiplication of multiplexed
(equal) ODUk virtual concatenation additionally uses the NMC value (equal) ODUk virtual concatenation additionally uses the NMC value
to determine the number of labels per set (equal in size). to determine the number of labels per set (equal in size).
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].
D.Papadimitriou (Editor) et al. - Expires March 2005 12
The OCh label space values are defined by either absolute values The OCh label space values are defined by either absolute values
(i.e. channel identifiers or Channel ID also referred to as (i.e. channel identifiers or Channel ID also referred to as
wavelength identifiers) or relative values (channel spacing also wavelength identifiers) or relative values (channel spacing also
referred to as inter-wavelength spacing). The latter is strictly referred to as inter-wavelength spacing). The latter is strictly
confined to a per-port label space while the former could be defined confined to a per-port label space while the former could be defined
as a local or a global (per node) label space. Such an OCh label as a local or a global (per node) label space. Such an OCh label
space is applicable to both OTN Optical Channel layer and pre-OTN space is applicable to both OTN Optical Channel layer and pre-OTN
Optical Channel layer. Optical Channel layer.
Optical Channel label encoding (and distribution) rules are defined Optical Channel label encoding (and distribution) rules are defined
skipping to change at line 680 skipping to change at line 694
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
2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed 2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed
D.Papadimitriou (Editor) et al. - Expires June 2005 13
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
label which can take for instance one of the following values: label which can take for instance one of the following values:
- t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2 - t3=0,t2=4,t1=0 indicates the ODU1 in the third TS of the ODTUG2
- t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3 - t3=2,t2=0,t1=0 indicates the ODU1 in the first TS of the ODTUG3
- t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3 - t3=7,t2=0,t1=0 indicates the ODU1 in the sixth TS of the ODTUG3
3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is 3. ODU2 into ODU3 multiplexing: when one unstructured ODU2 is
multiplexed into the payload of a structured ODU3, the upstream multiplexed into the payload of a structured ODU3, the upstream
node requests results simply in a ODU2 signal request. node requests results simply in a ODU2 signal request.
D.Papadimitriou (Editor) et al. - Expires March 2005 13
In such conditions, the downstream node has to return four labels In such conditions, the downstream node has to return four labels
since the ODU2 is multiplexed into one ODTUG3. The latter is since the ODU2 is multiplexed into one ODTUG3. The latter is
mapped into an ODU3 (via OPU3) and then mapped into an OTU3. mapped into an ODU3 (via OPU3) and then mapped into an OTU3.
Since an ODU2 multiplexed signal is requested (Signal Type = 2, Since an ODU2 multiplexed signal is requested (Signal Type = 2,
and NMC = 4), the downstream node has to return four ODU labels and NMC = 4), the downstream node has to return four ODU labels
which can take for instance the following values: which can take for instance the following values:
- t3=18, t2=0, t1=0 (first part of ODU2 in first TS of ODTUG3) - t3=18, t2=0, t1=0 (first part of ODU2 in first TS of ODTUG3)
- t3=22, t2=0, t1=0 (second part of ODU2 in fifth TS of ODTUG3) - t3=22, t2=0, t1=0 (second part of ODU2 in fifth TS of ODTUG3)
- t3=23, t2=0, t1=0 (third part of ODU2 in sixth TS of ODTUG3) - t3=23, t2=0, t1=0 (third part of ODU2 in sixth TS of ODTUG3)
skipping to change at line 733 skipping to change at line 748
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 2005 14
6. RSVP-TE Signaling Protocol Extensions 6. RSVP-TE Signaling Protocol Extensions
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 = TBA - G.709 SENDER_TSPEC Object: Class = 12, C-Type = TBA
- G.709 FLOWSPEC Object: Class = 9, C-Type = TBA - G.709 FLOWSPEC Object: Class = 9, C-Type = TBA
There is no Adspec associated with the SONET/SDH SENDER_TSPEC. There is no Adspec associated with the SONET/SDH SENDER_TSPEC.
Either the Adspec is omitted or an Int-serv Adspec with the Either the Adspec is omitted or an Int-serv Adspec with the
Default General Characterization Parameters and Guaranteed Service Default General Characterization Parameters and Guaranteed Service
fragment is used, see [RFC2210]. fragment is used, see [RFC2210].
D.Papadimitriou (Editor) et al. - Expires March 2005 14
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
a "Traffic Control Error/Bad Flowspec value" error SHOULD be a "Traffic Control Error/Bad Flowspec value" error SHOULD be
generated. generated.
Intermediate and egress nodes MUST verify that the node itself and Intermediate and egress nodes MUST verify that the node itself and
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
skipping to change at line 773 skipping to change at line 789
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]).
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
to [RFC3209] for RSVP-TE.
8. IANA Considerations 8. IANA Considerations
Two 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.
- 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 June 2005 15
IANA is also requested to track the code-point spaces extended IANA is also requested to track the code-point spaces extended
and/or updated by this document. For this purpose, the following and/or updated by this document. For this purpose, the following
registry entries are requested: new registry entries are requested in the newly requested registry
entry: http://www.iana.org/assignments/gmpls
- LSP Encoding Type - LSP Encoding Type:
http://www.iana.org/assignments/gmpls/lsp-encoding-type
Name: LSP Encoding Type Name: LSP Encoding Type
Format: 8-bit number Format: 8-bit number
Values: Values:
[1..11] defined in [RFC3471] [1..11] defined in [RFC3471]
12 defined in Section 3.1.1 12 defined in Section 3.1.1
13 defined in Section 3.1.1 13 defined in Section 3.1.1
Allocation Policy: Allocation Policy:
[0..239] Assigned by IANA via IETF Standards Track RFC [0..239] Assigned by IANA via IETF Standards Track RFC
Action. Action.
[240..255] Assigned temporarily for Experimental Usage. [240..255] Assigned temporarily for Experimental Usage.
D.Papadimitriou (Editor) et al. - Expires March 2005 15
these will not be registered with IANA these will not be registered with IANA
- Switching Type - Switching Type:
http://www.iana.org/assignments/gmpls/switching-type
Name: Switching Type Name: Switching Type
Format: 8-bit number Format: 8-bit number
Values: defined in [RFC3471] Values: defined in [RFC3471]
Allocation Policy: Allocation Policy:
[0..255] Assigned by IANA via IETF Standards Track RFC [0..255] Assigned by IANA via IETF Standards Track RFC
Action. Action.
- Generalized PID (G-PID) - Generalized PID (G-PID):
http://www.iana.org/assignments/gmpls/generalized-pid
Name: G-PID Name: G-PID
Format: 16-bit number Format: 16-bit number
Values: Values:
[0..31] defined in [RFC3471] [0..31] defined in [RFC3471]
[32..35] defined in Section 3.1.3 [32..35] defined in [RFC3471] and updated by Section
3.1.3
[36..46] defined in [RFC3471] [36..46] defined in [RFC3471]
[47..58] defined in Section 3.1.3 [47..58] defined in Section 3.1.3
Allocation Policy: Allocation Policy:
[0..31743] Assigned by IANA via IETF Standards Track RFC [0..31743] Assigned by IANA via IETF Standards Track RFC
Action. Action.
[31744..32767] Assigned temporarily for Experimental Usage [31744..32767] Assigned temporarily for Experimental Usage
[32768..65535] Not assigned. Before any assignments can be [32768..65535] Not assigned. Before any assignments can be
made in this range, there MUST be a Standards made in this range, there MUST be a Standards
Track RFC that specifies IANA Considerations Track RFC that specifies IANA Considerations
that covers the range being assigned. that covers the range being assigned.
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
D.Papadimitriou (Editor) et al. - Expires June 2005 16
Sankaranarayanan and Yangguang Xu for their useful feedback. Many Sankaranarayanan and Yangguang Xu for their useful feedback. Many
thanks to Adrian Farrel for having thoroughly reviewing this thanks to Adrian Farrel for having thoroughly reviewing this
document. 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 Consideration 10. References
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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
D.Papadimitriou (Editor) et al. - Expires March 2005 16
of such proprietary rights by implementers or users of this
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.
11. References
11.1 Normative References 10.1 Normative References
[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.,
"Generalized Multiprotocol Label Switching Extensions
for SONET and SDH Control," Internet Draft (work in
progress), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt,
February 2003.
[RFC2026] Bradner, S., "The Internet Standards Process -- [RFC2026] Bradner, S., "The Internet Standards Process --
Revision 3," BCP 9, RFC 2026, October 1996. 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.
skipping to change at line 915 skipping to change at line 903
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.
[RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78,
RFC 3667, February 2004. RFC 3667, February 2004.
D.Papadimitriou (Editor) et al. - Expires March 2005 17
[RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF [RFC3668] Bradner, S., Ed., "Intellectual Property Rights in IETF
Technology", BCP 79, RFC 3668, February 2004. Technology", BCP 79, RFC 3668, February 2004.
11.2 Informative References [RFC3946] Mannie, E. and Papadimitriou, D. (Editors) et al.,
"Generalized Multiprotocol Label Switching Extensions
for SONET and SDH Control," RFC 3946, October 2004.
[GMPLS-ARCH] Mannie, E. (Editor) et al., "Generalized Multi-Protocol 10.2 Informative References
Label Switching (GMPLS) Architecture," Internet Draft
(work in progress), draft-ietf-ccamp-gmpls- D.Papadimitriou (Editor) et al. - Expires June 2005 17
architecture-07.txt, May 2003. [RFC3945] Mannie, E. (Editor) et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Architecture," RFC 3945,
October 2004.
For information on the availability of the following documents, For information on the availability of the following documents,
please see http://www.itu.int please see http://www.itu.int
[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.
12. Contributors 11. 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)
skipping to change at line 969 skipping to change at line 960
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)
1415 N. McDowell Blvd, 1415 N. McDowell Blvd,
Petaluma, CA 94954, USA Petaluma, CA 94954, USA
D.Papadimitriou (Editor) et al. - Expires March 2005 18
Email: dguo@turinnetworks.com Email: dguo@turinnetworks.com
Juergen Heiles (Siemens) Juergen Heiles (Siemens)
Hofmannstr. 51, Hofmannstr. 51,
D-81379 Munich, Germany D-81379 Munich, Germany
Email: juergen.heiles@siemens.com Email: juergen.heiles@siemens.com
D.Papadimitriou (Editor) et al. - Expires June 2005 18
Jim Jones (Alcatel) Jim Jones (Alcatel)
3400 W. Plano Parkway, 3400 W. Plano Parkway,
Plano, TX 75075, USA Plano, TX 75075, USA
Email: jim.d.jones@alcatel.com Email: jim.d.jones@alcatel.com
Zhi-Wei Lin (Lucent) Zhi-Wei Lin (Lucent)
101 Crawfords Corner Rd, Rm 3C-512 101 Crawfords Corner Rd, Rm 3C-512
Holmdel, New Jersey 07733-3030, USA Holmdel, New Jersey 07733-3030, USA
Email: zwlin@lucent.com Email: zwlin@lucent.com
skipping to change at line 1001 skipping to change at line 991
Maarten Vissers (Alcatel) Maarten Vissers (Alcatel)
Lorenzstrasse, 10, Lorenzstrasse, 10,
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. Editor's Address 12. 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 March 2005 19 D.Papadimitriou (Editor) et al. - Expires June 2005 19
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 1065 skipping to change at line 1055
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 March 2005 20 D.Papadimitriou (Editor) et al. - Expires June 2005 20
. 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 1087 skipping to change at line 1077
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 March 2005 21 D.Papadimitriou (Editor) et al. - Expires June 2005 21
Full Copyright Statement Intellectual Property Statement
Copyright (C) The Internet Society (2004). This document is subject The IETF takes no position regarding the validity or scope of any
to the rights, licenses and restrictions contained in BCP 78, and Intellectual Property Rights or other rights that might be claimed
except as set forth therein, the authors retain all their rights. to pertain to the implementation or use of the technology described
in this document or the extent to which any license under such
rights might or might not be available; nor does it represent that
it has made any independent effort to identify any such rights.
Information on the procedures with respect to rights in RFC
documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
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.
Disclaimer of Validity
This document and the information contained herein are provided on This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
D.Papadimitriou (Editor) et al. - Expires March 2005 22 Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
D.Papadimitriou (Editor) et al. - Expires June 2005 22
 End of changes. 

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