draft-ietf-ccamp-gmpls-g709-04.txt   draft-ietf-ccamp-gmpls-g709-05.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: November 2003 May 2003 Expiration Date: June 2004 January 2004
Generalized MPLS Signalling Extensions Generalized MPLS Signalling Extensions
for G.709 Optical Transport Networks Control for G.709 Optical Transport Networks Control
draft-ietf-ccamp-gmpls-g709-04.txt draft-ietf-ccamp-gmpls-g709-05.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of Drafts. Internet-Drafts are draft documents valid for a maximum of
skipping to change at line 53 skipping to change at line 53
In this document, the presented views on ITU-T G.709 OTN In this document, the presented views on ITU-T G.709 OTN
Recommendation (and referenced) are intentionally restricted as Recommendation (and referenced) are intentionally restricted as
needed from the GMPLS perspective within the IETF CCAMP WG context. needed from the GMPLS perspective within the IETF CCAMP WG context.
Hence, the objective of this document is not to replicate the Hence, the objective of this document is not to replicate the
content of the ITU-T OTN recommendations. Therefore, the reader content of the ITU-T OTN recommendations. Therefore, the reader
interested in going into more details concerning the corresponding interested in going into more details concerning the corresponding
technologies is strongly invited to consult the corresponding ITU- technologies is strongly invited to consult the corresponding ITU-
T documents (also referenced in this memo). T documents (also referenced in this memo).
D.Papadimitriou (Editor) et al. - Expires November 2003 1 D.Papadimitriou (Editor) et al. - Expires June 2004 1
Table of Content Table of Content
Status of this Memo ............................................. 1 Status of this Memo ............................................. 1
Abstract ........................................................ 1 Abstract ........................................................ 1
Table of Content ................................................ 2 Table of Content ................................................ 2
1. Introduction ................................................. 2 1. Introduction ................................................. 2
2. GMPLS Extensions for G.709 - Overview ........................ 3 2. GMPLS Extensions for G.709 - Overview ........................ 3
3. Generalized Label Request .................................... 4 3. Generalized Label Request .................................... 4
3.1 Technology Independent Part ................................. 4 3.1 Technology Independent Part ................................. 4
3.1.1. LSP Encoding Type ........................................ 4 3.1.1. LSP Encoding Type ........................................ 5
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) .................................. 6
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) ....................... 9
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 .......................................... 10
4.2. Label Distribution Rules .................................. 11 4.2. Label Distribution Rules .................................. 11
4.3. OCh Label Space ........................................... 12 4.3. OCh Label Space ........................................... 12
5. Examples .................................................... 12 5. Examples .................................................... 12
6. Signalling Protocol Extensions .............................. 13 6. Signalling Protocol Extensions .............................. 13
6.1. RSVP-TE Details ........................................... 13 6.1. RSVP-TE Details ........................................... 13
6.2. CR-LDP Details ............................................ 14 6.2. CR-LDP Details ............................................ 14
7. Security Considerations ..................................... 15 7. Security Considerations ..................................... 15
8. IANA Considerations ......................................... 15 8. IANA Considerations ......................................... 15
9. Acknowledgments ............................................. 15 9. Acknowledgments ............................................. 15
10. Intellectual Property Notice ............................... 15 10. Intellectual Property Notice ............................... 16
11. References ................................................. 16 11. References ................................................. 16
11.1 Normative References ...................................... 16 11.1 Normative References ...................................... 16
12. Contributors ............................................... 17 12. Contributors ............................................... 17
13. Author's Address ........................................... 18 13. Author's Address ........................................... 18
Appendix 1 - Abbreviations ..................................... 19 Appendix 1 - Abbreviations ..................................... 19
Appendix 2 - G.709 Indexes ..................................... 19 Appendix 2 - G.709 Indexes ..................................... 19
Full Copyright Statement ....................................... 21 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], terminology used in ITU-T [ITUT-G709] as well as [RFC3471],
[RFC3473] and [RFC3472]. Abbreviations used in this document are [RFC3473] and [RFC3472]. Abbreviations used in this document are
detailed in Appendix 1. detailed in Appendix 1.
Changes from v03.txt to v04.txt: D.Papadimitriou (Editor) et al. - Expires June 2004 2
Editorial and test clarifications
Reference updates
D.Papadimitriou (Editor) et al. - Expires November 2003 2
Changes from v02.txt to v03.txt:
Editorial and text clarifications
Add G-PID values for ESCON and FICON
1. Introduction 1. Introduction
Generalized MPLS (GMPLS) extends MPLS from supporting Packet Generalized MPLS (GMPLS) extends MPLS from supporting Packet
Switching Capable (PSC) interfaces and switching to include Switching Capable (PSC) interfaces and switching to include
support of three new classes of interfaces and switching: Time- support of three new classes of interfaces and switching: Time-
Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch Division Multiplex (TDM), Lambda Switch (LSC) and Fiber-Switch
(FSC) Capable. A functional description of the extensions to MPLS (FSC) Capable. A functional description of the extensions to MPLS
signaling needed to support these new classes of interfaces and signaling needed to support these new classes of interfaces and
switching is provided in [RFC3471]. [RFC3473] describes RSVP-TE switching is provided in [RFC3471]. [RFC3473] describes RSVP-TE
skipping to change at line 163 skipping to change at line 153
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 (so also referred
to as the non-associated overhead naOH) in the OTM Overhead Signal to as the non-associated overhead naOH) in the OTM Overhead Signal
(OOS), together with the OTS and OMS non-associated overhead. The (OOS), together with the OTS and OMS non-associated overhead. The
OOS is transported via a dedicated wavelength referred to as the OOS is transported via a dedicated wavelength referred to as the
Optical Supervisory Channel (OSC). It should be noticed that the Optical Supervisory Channel (OSC). It should be noticed that the
naOH is only functionally specified and as such open to vendor naOH is only functionally specified and as such open to vendor
D.Papadimitriou (Editor) et al. - Expires November 2003 3
specific solutions. The ODUk overhead is transported in an specific solutions. The ODUk overhead is transported in an
associated manner as part of the digital ODUk frame. associated manner as part of the digital ODUk frame.
As described in [ITUT-G709], in addition to the support of ODUk As described in [ITUT-G709], in addition to the support of ODUk
mapping into OTUk (k = 1, 2, 3), [ITUT-G.709] supports ODUk mapping into OTUk (k = 1, 2, 3), [ITUT-G.709] supports ODUk
D.Papadimitriou (Editor) et al. - Expires June 2004 3
multiplexing. It refers to the multiplexing of ODUj (j = 1, 2) into multiplexing. It refers to the multiplexing of ODUj (j = 1, 2) into
an ODUk (k > j) signal, in particular: an ODUk (k > j) signal, in particular:
- ODU1 into ODU2 multiplexing - ODU1 into ODU2 multiplexing
- ODU1 into ODU3 multiplexing - ODU1 into ODU3 multiplexing
- ODU2 into ODU3 multiplexing - ODU2 into ODU3 multiplexing
- ODU1 and ODU2 into ODU3 multiplexing - ODU1 and ODU2 into ODU3 multiplexing
Therefore, adapting GMPLS to control G.709 OTN, can be achieved by Therefore, adapting GMPLS to control G.709 OTN, can be achieved by
considering that: considering that:
- a Digital Path layer by extending the previously defined - a Digital Path layer by extending the previously defined
skipping to change at line 218 skipping to change at line 208
3.1 Technology Independent Part 3.1 Technology Independent Part
As defined in [RFC3471], the LSP Encoding Type, the Switching Type As defined in [RFC3471], the LSP Encoding Type, the Switching Type
and the Generalized Protocol Identifier (Generalized-PID) constitute and the Generalized Protocol Identifier (Generalized-PID) constitute
the technology independent part of the Generalized Label Request. the technology independent part of the Generalized Label Request.
The encoding of the corresponding RSVP-TE object and CR-LDP TLV is The encoding of the corresponding RSVP-TE object and CR-LDP TLV is
specified in [RFC3473] Section 2.1 and [RFC3472] Section 2.1, specified in [RFC3473] Section 2.1 and [RFC3472] Section 2.1,
respectively. respectively.
D.Papadimitriou (Editor) et al. - Expires November 2003 4
As mentioned here above, this document extends the LSP Encoding As mentioned here above, this document extends the LSP Encoding
Type, Switching Type and G-PID (Generalized-PID) values to Type, Switching Type and G-PID (Generalized-PID) values to
accommodate G.709 recommendation [ITUT-G709]. accommodate G.709 recommendation [ITUT-G709].
D.Papadimitriou (Editor) et al. - Expires June 2004 4
3.1.1 LSP Encoding Type 3.1.1 LSP Encoding Type
Since G.709 defines two networking layers (ODUk layers and OCh Since G.709 defines two networking layers (ODUk layers and OCh
layer), the LSP Encoding Type code-points can reflect these two layer), the LSP Encoding Type code-points can reflect these two
layers currently defined in [RFC3471] as "Digital Wrapper" and layers currently defined in [RFC3471] as "Digital Wrapper" and
"Lambda" code. "Lambda" code.
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.
skipping to change at line 271 skipping to change at line 262
The Switching Type indicates the type of switching that should be The Switching Type indicates the type of switching that should be
performed at the termination of a particular link. This field is performed at the termination of a particular link. This field is
only needed for links that advertise more than one type of switching only needed for links that advertise more than one type of switching
capability (see [GMPLS-RTG]). capability (see [GMPLS-RTG]).
Here, no additional values are to be considered in order to Here, no additional values are to be considered in order to
accommodate G.709 switching types since an ODUk switching (and so accommodate G.709 switching types since an ODUk switching (and so
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 November 2003 5
Moreover, in a strict layered G.709 network, when a downstream node Moreover, in a strict layered G.709 network, when a downstream node
receives a Generalized Label Request including one of these values receives a Generalized Label Request including one of these values
for the Switching Type field, this value SHOULD be ignored. for the Switching Type field, this value SHOULD be ignored.
D.Papadimitriou (Editor) et al. - Expires June 2004 5
3.1.3 Generalized-PID (G-PID) 3.1.3 Generalized-PID (G-PID)
The G-PID (16 bits field) as defined in [RFC3471], identifies the The G-PID (16 bits field) as defined in [RFC3471], identifies the
payload carried by an LSP, i.e. an identifier of the client layer of payload carried by an LSP, i.e. an identifier of the client layer of
that LSP. This identifier is used by the endpoints of the G.709 LSP. that LSP. This identifier is used by the endpoints of the G.709 LSP.
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]:
skipping to change at line 325 skipping to change at line 317
- 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:
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)
D.Papadimitriou (Editor) et al. - Expires November 2003 6
48 G.709 OTUk(v) G.709 OCh 48 G.709 OTUk(v) G.709 OCh
ODUk mapped into OTUk(v) ODUk mapped into OTUk(v)
49 CBR/CBRa G.709 ODUk, G.709 OCh 49 CBR/CBRa G.709 ODUk, G.709 OCh
50 CBRb G.709 ODUk 50 CBRb G.709 ODUk
D.Papadimitriou (Editor) et al. - Expires June 2004 6
51 BSOT G.709 ODUk 51 BSOT G.709 ODUk
52 BSNT G.709 ODUk 52 BSNT G.709 ODUk
53 IP/PPP (GFP) G.709 ODUk (and SDH) 53 IP/PPP (GFP) G.709 ODUk (and SDH)
54 Ethernet MAC (framed GFP) G.709 ODUk (and SDH) 54 Ethernet MAC (framed GFP) G.709 ODUk (and SDH)
55 Ethernet PHY (transparent GFP) G.709 ODUk (and SDH) 55 Ethernet PHY (transparent GFP) G.709 ODUk (and SDH)
56 ESCON G.709 ODUk, Lambda, Fiber 56 ESCON G.709 ODUk, Lambda, Fiber
57 FICON G.709 ODUk, Lambda, Fiber 57 FICON G.709 ODUk, Lambda, Fiber
58 Fiber Channel G.709 ODUk, Lambda, Fiber 58 Fiber Channel G.709 ODUk, Lambda, Fiber
Note: Value 49 and 50 includes mapping of SDH Note: Value 49 and 50 includes mapping of SDH
skipping to change at line 380 skipping to change at line 372
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.
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
D.Papadimitriou (Editor) et al. - Expires November 2003 7
----- ---- ----- ----
0 Irrelevant 0 Irrelevant
1 ODU1 (i.e. 2.5 Gbps) 1 ODU1 (i.e. 2.5 Gbps)
2 ODU2 (i.e. 10 Gbps) 2 ODU2 (i.e. 10 Gbps)
D.Papadimitriou (Editor) et al. - Expires June 2004 7
3 ODU3 (i.e. 40 Gbps) 3 ODU3 (i.e. 40 Gbps)
4 Reserved 4 Reserved
5 Reserved 5 Reserved
6 OCh at 2.5 Gbps 6 OCh at 2.5 Gbps
7 OCh at 10 Gbps 7 OCh at 10 Gbps
8 OCh at 40 Gbps 8 OCh at 40 Gbps
9-255 Reserved 9-255 Reserved
The value of the Signal Type field depends on LSP Encoding Type The value of the Signal Type field depends on LSP Encoding Type
value defined in Section 3.1.1 and [RFC3471]: value defined in Section 3.1.1 and [RFC3471]:
skipping to change at line 434 skipping to change at line 426
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.
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
D.Papadimitriou (Editor) et al. - Expires November 2003 8
other currently defined multiplexing cases (see Section 2), the NMC other currently defined multiplexing cases (see Section 2), the NMC
field is set to 1. field is set to 1.
D.Papadimitriou (Editor) et al. - Expires June 2004 8
3.2.3 Number of Virtual Components (NVC) 3.2.3 Number of Virtual Components (NVC)
The NVC field (16 bits) is dedicated to ODUk virtual concatenation The NVC field (16 bits) is dedicated to ODUk virtual concatenation
(i.e. ODUk Inverse Multiplexing) purposes. It indicates the number (i.e. ODUk Inverse Multiplexing) purposes. It indicates the number
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.
skipping to change at line 489 skipping to change at line 481
when sent and MUST be ignored when received. when sent and MUST be ignored when received.
4. Generalized Label 4. Generalized Label
This section describes the Generalized Label value space for Digital This section describes the Generalized Label value space for Digital
Paths and Optical Channels. The Generalized Label is defined in Paths and Optical Channels. The Generalized Label is defined in
[RFC3471]. The format of the corresponding RSVP-TE object and CR-LDP [RFC3471]. The format of the corresponding RSVP-TE object and CR-LDP
TLV is specified in [RFC3473] Section 2.2 and [RFC3472] Section 2.2, TLV is specified in [RFC3473] Section 2.2 and [RFC3472] Section 2.2,
respectively. respectively.
D.Papadimitriou (Editor) et al. - Expires November 2003 9
The label distribution rules detailed in Section 4.2 follow (when The label distribution rules detailed in Section 4.2 follow (when
applicable) the ones defined in [GMPLS-SONET-SDH]. applicable) the ones defined in [GMPLS-SONET-SDH].
D.Papadimitriou (Editor) et al. - Expires June 2004 9
4.1 ODUk Label Space 4.1 ODUk Label Space
At the Digital Path layer (i.e. ODUk layers), G.709 defines three At the Digital Path layer (i.e. ODUk layers), G.709 defines three
different client payload bit rates. An Optical Data Unit (ODU) frame different client payload bit rates. An Optical Data Unit (ODU) frame
has been defined for each of these bit rates. ODUk refers to the has been defined for each of these bit rates. ODUk refers to the
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
skipping to change at line 543 skipping to change at line 536
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):
D.Papadimitriou (Editor) et al. - Expires November 2003 10
- t2=1 indicates a not further sub-divided ODU2 signal. - t2=1 indicates a not further sub-divided ODU2 signal.
- t2=2->5 indicates the tributary slot (t2th-2) used by the - t2=2->5 indicates the tributary slot (t2th-2) used by the
ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2). ODU1 in an ODTUG2 mapped into an ODU2 (via OPU2).
D.Papadimitriou (Editor) et al. - Expires June 2004 10
- t2 is not significant for an ODU3 (t2=0). - t2 is not significant for an ODU3 (t2=0).
3. t3 (6-bit): 3. t3 (6-bit):
- t3=1 indicates a not further sub-divided ODU3 signal. - t3=1 indicates a not further sub-divided ODU3 signal.
- t3=2->17 indicates the tributary slot (t3th-1) used by the - t3=2->17 indicates the tributary slot (t3th-1) used by the
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
skipping to change at line 598 skipping to change at line 591
(not the physical order of tributary slots). (not the physical order of tributary slots).
In case of ODUk virtual concatenation, the explicit ordered list of In case of ODUk virtual concatenation, the explicit ordered list of
all labels in the concatenation is given. Each label indicates a all labels in the concatenation is given. Each label indicates a
component of the virtually concatenated signal. The order of the component of the virtually concatenated signal. The order of the
labels must reflect the order of the ODUk to concatenate (not the labels must reflect the order of the ODUk to concatenate (not the
physical order of time-slots). This representation limits virtual physical order of time-slots). This representation limits virtual
concatenation to remain within a single (component) link. In case of concatenation to remain within a single (component) link. In case of
multiplexed virtually concatenated signals, the first set of labels multiplexed virtually concatenated signals, the first set of labels
indicates the components (ODUj tributary slots) of the first indicates the components (ODUj tributary slots) of the first
D.Papadimitriou (Editor) et al. - Expires November 2003 11
virtually concatenated signal, the second set of labels indicates virtually concatenated signal, the second set of labels indicates
the components (ODUj tributary slots) of the second virtually the components (ODUj tributary slots) of the second virtually
concatenated signal, and so on. concatenated signal, and so on.
D.Papadimitriou (Editor) et al. - Expires June 2004 11
In case of multiplication (i.e. when using the MT field), the In case of multiplication (i.e. when using the MT field), the
explicit ordered list of all labels taking part in the composed explicit ordered list of all labels taking part in the composed
signal is given. The above representation limits multiplication to signal is given. The above representation limits multiplication to
remain within a single (component) link. In case of multiplication remain within a single (component) link. In case of multiplication
of multiplexed/virtually concatenated signals, the first set of of multiplexed/virtually concatenated signals, the first set of
labels indicates the components of the first multiplexed/virtually labels indicates the components of the first multiplexed/virtually
concatenated signal, the second set of labels indicates components concatenated signal, the second set of labels indicates components
of the second multiplexed/virtually concatenated signal, and so on. of the second multiplexed/virtually concatenated signal, and so on.
Note: as defined in [RFC3471], label field values only have Note: as defined in [RFC3471], label field values only have
skipping to change at line 653 skipping to change at line 645
processing described in the previous sections of this document. processing described in the previous sections of this document.
1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is 1. ODUk in OTUk mapping: when one ODU1 (ODU2 or ODU3) signal is
directly transported in an OTU1 (OTU2 or OTU3), the upstream node directly transported in an OTU1 (OTU2 or OTU3), the upstream node
requests results simply in an ODU1 (ODU2 or ODU3) signal request. requests results simply in an ODU1 (ODU2 or ODU3) signal request.
In such conditions, the downstream node has to return a unique In such conditions, the downstream node has to return a unique
label since the ODU1 (ODU2 or ODU3) is directly mapped into the label since the ODU1 (ODU2 or ODU3) is directly mapped into the
corresponding OTU1 (OTU2 or OTU3). Since a single ODUk signal is corresponding OTU1 (OTU2 or OTU3). Since a single ODUk signal is
requested (Signal Type = 1, 2 or 3), the downstream node has to requested (Signal Type = 1, 2 or 3), the downstream node has to
D.Papadimitriou (Editor) et al. - Expires November 2003 12
return a single ODUk label which can be for instance one of the return a single ODUk label which can be for instance one of the
following when the Signal Type = 1: following when the Signal Type = 1:
D.Papadimitriou (Editor) et al. - Expires June 2004 12
- t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1 - t3=0, t2=0, t1=1 indicating a single ODU1 mapped into an OTU1
- t3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2 - t3=0, t2=1, t1=0 indicating a single ODU2 mapped into an OTU2
- t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3 - t3=1, t2=0, t1=0 indicating a single ODU3 mapped into an OTU3
2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed 2. ODU1 into ODUk multiplexing (k > 1): when one ODU1 is multiplexed
into the payload of a structured ODU2 (or ODU3), the upstream into the payload of a structured ODU2 (or ODU3), the upstream
node requests results simply in a ODU1 signal request. node requests results simply in a ODU1 signal request.
In such conditions, the downstream node has to return a unique In such conditions, the downstream node has to return a unique
label since the ODU1 is multiplexed into one ODTUG2 (or ODTUG3). label since the ODU1 is multiplexed into one ODTUG2 (or ODTUG3).
skipping to change at line 708 skipping to change at line 699
5. When requesting multiple ODUk LSP (i.e. with a multiplier (MT) 5. When requesting multiple ODUk LSP (i.e. with a multiplier (MT)
value > 1), an explicit list of labels is returned to the value > 1), an explicit list of labels is returned to the
requestor node. requestor node.
When the downstream node receives a request for a 4 x ODU1 signal When the downstream node receives a request for a 4 x ODU1 signal
(Signal Type = 1, NMC = 1 and MT = 4) multiplexed into a ODU3, it (Signal Type = 1, NMC = 1 and MT = 4) multiplexed into a ODU3, it
returns an ordered list of four labels to the upstream node: the returns an ordered list of four labels to the upstream node: the
first ODU1 label corresponding to the first signal of the LSP, first ODU1 label corresponding to the first signal of the LSP,
the second ODU1 label corresponding to the second signal of the the second ODU1 label corresponding to the second signal of the
LSP, etc. For instance, the corresponding labels can take the LSP, etc. For instance, the corresponding labels can take the
D.Papadimitriou (Editor) et al. - Expires November 2003 13
following values: following values:
- First ODU1: t3=2, t2=0, t1=0 (in first TS of ODTUG3) - First ODU1: t3=2, t2=0, t1=0 (in first TS of ODTUG3)
D.Papadimitriou (Editor) et al. - Expires June 2004 13
- Second ODU1: t3=10, t2=0, t1=0 (in ninth TS of ODTUG3) - Second ODU1: t3=10, t2=0, t1=0 (in ninth TS of ODTUG3)
- Third ODU1: t3=7, t2=0, t1=0 (in sixth TS of ODTUG3) - Third ODU1: t3=7, t2=0, t1=0 (in sixth TS of ODTUG3)
- Fourth ODU1: t3=6, t2=0, t1=0 (in fifth TS of ODTUG3) - Fourth ODU1: t3=6, t2=0, t1=0 (in fifth TS of ODTUG3)
6. Signalling Protocol Extensions 6. Signalling Protocol Extensions
This section specifies the [RFC3473] and [RFC3472] protocol This section specifies the [RFC3473] and [RFC3472] protocol
extensions needed to accommodate G.709 traffic parameters. extensions needed to accommodate G.709 traffic parameters.
6.1 RSVP-TE Details 6.1 RSVP-TE Details
skipping to change at line 763 skipping to change at line 754
Error/Bad Tspec value" indication (see [RFC2205]). Error/Bad Tspec value" indication (see [RFC2205]).
6.2 CR-LDP Details 6.2 CR-LDP Details
For CR-LDP, the G.709 traffic parameters are carried in the G.709 For CR-LDP, the G.709 traffic parameters are carried in the G.709
Traffic Parameters TLV. The content of the TLV is defined in Traffic Parameters TLV. The content of the TLV is defined in
Section 3.2. The header of the TLV has the following format: Section 3.2. The header of the TLV has the following format:
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
D.Papadimitriou (Editor) et al. - Expires November 2003 14
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|U|F| Type | Length | |U|F| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
D.Papadimitriou (Editor) et al. - Expires June 2004 14
The type field indicates G.709 traffic parameters: 0xTBA The type field indicates G.709 traffic parameters: 0xTBA
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
Section 3.2). If the requested value(s) can not be supported, the Section 3.2). If the requested value(s) can not be supported, the
receiver node MUST generate a NOTIFICATION message with a receiver node MUST generate a NOTIFICATION message with a
"Resource Unavailable" status code (see [RFC3212]). "Resource Unavailable" status code (see [RFC3212]).
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
skipping to change at line 817 skipping to change at line 807
- A Type field value for the G.709 Traffic Parameters - A Type field value for the G.709 Traffic Parameters
TLV (see section 6.2). TLV (see section 6.2).
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.
D.Papadimitriou (Editor) et al. - Expires November 2003 15
This draft incorporates (upon agreement) material and ideas from This draft incorporates (upon agreement) material and ideas from
draft-lin-ccamp-ipo-common-label-request-00.txt draft-lin-ccamp-ipo-common-label-request-00.txt.
D.Papadimitriou (Editor) et al. - Expires June 2004 15
10. Intellectual Property Notice 10. Intellectual Property Notice
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
skipping to change at line 863 skipping to change at line 854
February 2001 (October 2001). February 2001 (October 2001).
[ITUT-G798] ITU-T, "Characteristics of Optical Transport Network [ITUT-G798] ITU-T, "Characteristics of Optical Transport Network
Hierarchy Equipment Functional Blocks," G.798 Hierarchy Equipment Functional Blocks," G.798
Recommendation, October 2001. Recommendation, October 2001.
[ITUT-G872] ITU-T, version 2.0, "Architecture of Optical Transport [ITUT-G872] ITU-T, version 2.0, "Architecture of Optical Transport
Network," G.872 Recommendation, October 2001. Network," G.872 Recommendation, October 2001.
[GMPLS-ARCH] Mannie, E. (Editor) et al., "Generalized Multi-Protocol [GMPLS-ARCH] Mannie, E. (Editor) et al., "Generalized Multi-Protocol
Label Switching (GMPLS) Architecture," Internet Draft, Label Switching (GMPLS) Architecture," Internet Draft
Work in progress, draft-ietf-ccamp-gmpls-architecture- (work in progress), draft-ietf-ccamp-gmpls-
07.txt, May 2003. architecture-07.txt, May 2003.
[GMPLS-RTG] Kompella, K. (Editor) et al., "Routing Extensions in [GMPLS-RTG] Kompella, K. (Editor) et al., "Routing Extensions in
Support of Generalized MPLS," Internet Draft, Work in Support of Generalized MPLS," Internet Draft (work in
Progress, draft-ietf-ccamp-gmpls-routing-05.txt, progress), draft-ietf-ccamp-gmpls-routing-09.txt,
September 2002. October 2003.
D.Papadimitriou (Editor) et al. - Expires November 2003 16
[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
progress, draft-ietf-ccamp-gmpls-sonet-sdh-08.txt, D.Papadimitriou (Editor) et al. - Expires June 2004 16
for SONET and SDH Control," Internet Draft (work in
progress), draft-ietf-ccamp-gmpls-sonet-sdh-08.txt,
February 2003. February 2003.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997. Requirement Levels," BCP 14, RFC 2119, March 1997.
[RFC2205] Braden, R., et al., "Resource ReSerVation Protocol [RFC2205] Braden, R., et al., "Resource ReSerVation Protocol
(RSVP) -- Version 1 Functional Specification," RFC (RSVP) -- Version 1 Functional Specification," RFC
2205, September 1997. 2205, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services," Internet RFC 2210, IETF Standard Track, Services," RFC 2210, September 1997
September 1997.
[RFC3036] Andersson, L. et al., "LDP Specification," Internet RFC [RFC3036] Andersson, L. et al., "LDP Specification," RFC 3036,
3036, IETF Proposed Standard, January 2001. January 2001.
[RFC3209] Awduche, D. et al., "RSVP-TE: Extensions to RSVP for [RFC3209] Awduche, D. et al., "RSVP-TE: Extensions to RSVP for
LSP Tunnels," Internet RFC 3209, IETF Proposed LSP Tunnels," RFC 3209, December 2001.
Standard, December 2001.
[RFC3212] Jamoussi, B. (Editor) et al., "Constraint-Based LSP [RFC3212] Jamoussi, B. (Editor) et al., "Constraint-Based LSP
Setup using LDP," Internet RFC 3212, IETF Proposed Setup using LDP," RFC 3212, January 2002.
Standard, January 2002.
[RFC3471] Berger, L. (Editor) et al., "Generalized MPLS - [RFC3471] Berger, L. (Editor) et al., "Generalized Multi-
Signaling Functional Description," IETF RFC 3471, Protocol Label Switching (GMPLS) Signaling -
January 2003. Functional Description," RFC 3471, January 2003.
[RFC3472] Berger, L. (Editor) et al., "Generalized MPLS [RFC3472] Berger, L. (Editor) et al., "Generalized Multi-
Signaling - CR-LDP Extensions," IETF RFC 3472, Protocol Label Switching (GMPLS) Signaling -
January 2003. Constraint-based Routed Label Distribution Protocol
(CR-LDP) Extensions," RFC 3472, January 2003.
[RFC3473] Berger, L. (Editor) et al., "Generalized MPLS [RFC3473] Berger, L. (Editor) et al., "Generalized Multi-
Signaling - RSVP-TE Extensions," IETF RFC 3473, Protocol Label Switching (GMPLS) Signaling Resource
January 2003. ReserVation Protocol-Traffic Engineering (RSVP-TE)
Extensions," RFC 3473, January 2003.
12. Contributors 12. Contributors
Alberto Bellato (Alcatel) Alberto Bellato (Alcatel)
Via Trento 30, Via Trento 30,
I-20059 Vimercate, Italy I-20059 Vimercate, Italy
Email: alberto.bellato@alcatel.it Email: alberto.bellato@alcatel.it
Sudheer Dharanikota (Consult) Sudheer Dharanikota (Consult)
Email: sudheer@ieee.org Email: sudheer@ieee.org
Michele Fontana (Alcatel) Michele Fontana (Alcatel)
Via Trento 30, Via Trento 30,
I-20059 Vimercate, Italy I-20059 Vimercate, Italy
D.Papadimitriou (Editor) et al. - Expires November 2003 17
Email: michele.fontana@alcatel.it Email: michele.fontana@alcatel.it
Nasir Ghani (Sorrento Networks) Nasir Ghani (Sorrento Networks)
D.Papadimitriou (Editor) et al. - Expires June 2004 17
9990 Mesa Rim Road, 9990 Mesa Rim Road,
San Diego, CA 92121, USA San Diego, CA 92121, USA
Email: nghani@sorrentonet.com Email: nghani@sorrentonet.com
Gert Grammel (Alcatel) Gert Grammel (Alcatel)
Lorenzstrasse, 10, Lorenzstrasse, 10,
70435 Stuttgart, Germany 70435 Stuttgart, Germany
Email: gert.grammel@alcatel.de Email: gert.grammel@alcatel.de
Dan Guo (Turin Networks) Dan Guo (Turin Networks)
skipping to change at line 981 skipping to change at line 972
Email: yong.xue@wcom.com Email: yong.xue@wcom.com
13. Author's Address 13. Author's Address
Dimitri Papadimitriou (Alcatel) Dimitri Papadimitriou (Alcatel)
Francis Wellesplein 1, Francis Wellesplein 1,
B-2018 Antwerpen, Belgium B-2018 Antwerpen, Belgium
Phone: +32 3 240-8491 Phone: +32 3 240-8491
Email: dimitri.papadimitriou@alcatel.be Email: dimitri.papadimitriou@alcatel.be
D.Papadimitriou (Editor) et al. - Expires November 2003 18 D.Papadimitriou (Editor) et al. - Expires June 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 1037 skipping to change at line 1028
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 November 2003 19 D.Papadimitriou (Editor) et al. - Expires June 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
skipping to change at line 1059 skipping to change at line 1050
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 November 2003 20 D.Papadimitriou (Editor) et al. - Expires June 2004 20
Full Copyright Statement Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. "Copyright (C) The Internet Society (date). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph
are included on all such copies and derivative works. However, this are included on all such copies and derivative works. However, this
skipping to change at line 1088 skipping to change at line 1079
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
D.Papadimitriou (Editor) et al. - Expires November 2003 21 D.Papadimitriou (Editor) et al. - Expires June 2004 21
 End of changes. 

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