draft-ietf-ccamp-gmpls-signaling-g709v3-07.txt   draft-ietf-ccamp-gmpls-signaling-g709v3-08.txt 
Network Working Group Fatai Zhang, Ed. Network Working Group Fatai Zhang, Ed.
Internet Draft Huawei Internet Draft Huawei
Updates: 4328 Guoying Zhang Updates: 4328 Guoying Zhang
Category: Standards Track CATR Category: Standards Track CATR
Sergio Belotti Sergio Belotti
Alcatel-Lucent Alcatel-Lucent
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
Khuzema Pithewan Khuzema Pithewan
Infinera Infinera
Expires: August 21, 2013 February 21, 2013 Expires: October 8, 2013 April 8, 2013
Generalized Multi-Protocol Label Switching (GMPLS) Signaling Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Extensions for the evolving G.709 Optical Transport Networks Control Extensions for the evolving G.709 Optical Transport Networks Control
draft-ietf-ccamp-gmpls-signaling-g709v3-07.txt draft-ietf-ccamp-gmpls-signaling-g709v3-08.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
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. Drafts.
skipping to change at page 1, line 40 skipping to change at page 1, line 40
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 21, 2013. This Internet-Draft will expire on October 8, 2013.
Abstract Abstract
ITU-T Recommendation G.709 [G709-2012] has introduced new Optical ITU-T Recommendation G.709 [G709-2012] has introduced new Optical
channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e and ODUflex) channel Data Unit (ODU) containers (ODU0, ODU4, ODU2e and ODUflex)
and enhanced Optical Transport Networking (OTN) flexibility. and enhanced Optical Transport Networking (OTN) flexibility.
This document updates RFC4328 to provide the extensions to the This document updates RFC4328 to provide the extensions to the
Generalized Multi-Protocol Label Switching (GMPLS) signaling to Generalized Multi-Protocol Label Switching (GMPLS) signaling to
control the evolving OTN addressing ODUk multiplexing and new control the evolving OTN addressing ODUk multiplexing and new
skipping to change at page 2, line 24 skipping to change at page 2, line 24
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction .................................................. 3 1. Introduction .................................................. 3
2. Terminology ................................................... 3 2. Terminology ................................................... 3
3. GMPLS Extensions for the Evolving G.709 - Overview ............ 3 3. GMPLS Extensions for the Evolving G.709 - Overview ............ 3
4. Generalized Label Request ..................................... 4 4. Generalized Label Request ..................................... 4
5. Extensions for Traffic Parameters for the Evolving G.709 ...... 6 5. Extensions for Traffic Parameters for the Evolving G.709 ...... 6
5.1. Usage of ODUflex(CBR) Traffic Parameters ................. 8 5.1. Usage of ODUflex(CBR) Traffic Parameters ................. 7
5.2. Usage of ODUflex(GFP) Traffic Parameters ................ 10 5.2. Usage of ODUflex(GFP) Traffic Parameters ................ 10
5.3. Notification on Errors of OTN-TDM Traffic Parameters .... 10 5.3. Notification on Errors of OTN-TDM Traffic Parameters .... 10
6. Generalized Label ............................................ 11 6. Generalized Label ............................................ 11
6.1. OTN-TDM Switching Type Generalized Label ................ 11 6.1. OTN-TDM Switching Type Generalized Label ................ 11
6.2. Procedures .............................................. 13 6.2. Procedures .............................................. 13
6.2.1. Notification on Label Error ........................ 15 6.2.1. Notification on Label Error ........................ 15
6.3. Supporting Virtual Concatenation and Multiplication ..... 16 6.3. Supporting Virtual Concatenation and Multiplication ..... 16
6.4. Examples ................................................ 16 6.4. Examples ................................................ 16
7. Supporting Hitless Adjustment of ODUflex (GFP) ............... 18 7. Supporting Hitless Adjustment of ODUflex (GFP) ............... 18
8. Control Plane Backward Compatibility Considerations........... 19 8. Control Plane Backward Compatibility Considerations........... 19
9. Security Considerations ...................................... 20 9. Security Considerations ...................................... 20
10. IANA Considerations.......................................... 20 10. IANA Considerations.......................................... 20
11. References .................................................. 22 11. References .................................................. 21
11.1. Normative References ................................... 22 11.1. Normative References ................................... 21
11.2. Informative References ................................. 22 11.2. Informative References ................................. 22
12. Contributors ................................................ 23 12. Contributors ................................................ 23
13. Authors' Addresses .......................................... 24 13. Authors' Addresses .......................................... 24
14. Acknowledgment .............................................. 26 14. Acknowledgment .............................................. 26
1. Introduction 1. Introduction
With the evolution and deployment of OTN technology, it is necessary With the evolution and deployment of OTN technology, it is necessary
that appropriate enhanced control technology support be provided for that appropriate enhanced control technology support be provided for
[G709-2012]. [G709-2012].
skipping to change at page 3, line 33 skipping to change at page 3, line 33
2. Terminology 2. Terminology
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 this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. GMPLS Extensions for the Evolving G.709 - Overview 3. GMPLS Extensions for the Evolving G.709 - Overview
New features for the evolving OTN, for example, new ODU0, ODU2e, ODU4 New features for the evolving OTN, for example, new ODU0, ODU2e, ODU4
and ODUflex containers are specified in [G709-2012]. The and ODUflex containers are specified in [G709-2012]. The
corresponding new signal types are summarized below: corresponding new Signal Types are summarized below:
- Optical Channel Transport Unit (OTUk): - Optical Channel Transport Unit (OTUk):
. OTU4 . OTU4
- Optical Channel Data Unit (ODUk): - Optical Channel Data Unit (ODUk):
. ODU0 . ODU0
. ODU2e . ODU2e
. ODU4 . ODU4
. ODUflex . ODUflex
skipping to change at page 4, line 21 skipping to change at page 4, line 21
Section 3.1.2 of [OTN-FWK]. Section 3.1.2 of [OTN-FWK].
Virtual Concatenation (VCAT) of Optical channel Payload Unit-k (OPUk) Virtual Concatenation (VCAT) of Optical channel Payload Unit-k (OPUk)
(OPUk-Xv, k = 1/2/3, X = 1...256) is also supported by [G709-2012]. (OPUk-Xv, k = 1/2/3, X = 1...256) is also supported by [G709-2012].
Note that VCAT of OPU0 / OPU2e / OPU4 / OPUflex is not supported per Note that VCAT of OPU0 / OPU2e / OPU4 / OPUflex is not supported per
[G709-2012]. [G709-2012].
[RFC4328] describes GMPLS signaling extensions to support the control [RFC4328] describes GMPLS signaling extensions to support the control
for the 2001 revision of the G.709 specification. However, [RFC4328] for the 2001 revision of the G.709 specification. However, [RFC4328]
needs to be updated because it does not provide the means to signal needs to be updated because it does not provide the means to signal
all the new signal types and related mapping and multiplexing all the new Signal Types and related mapping and multiplexing
functionalities. Moreover, it supports only the deprecated auto- functionalities. Moreover, it supports only the deprecated auto-
Multiframe Structure Identifier (MSI) mode which assumes that the Multiframe Structure Identifier (MSI) mode which assumes that the
Tributary Port Number (TPN) is automatically assigned in the transmit Tributary Port Number (TPN) is automatically assigned in the transmit
direction and not checked in the receive direction. direction and not checked in the receive direction.
This document extends the G.709 Traffic Parameters described in This document extends the G.709 Traffic Parameters described in
[RFC4328] and presents a new flexible and scalable OTN label format. [RFC4328] and presents a new flexible and scalable OTN label format.
Additionally, procedures about Tributary Port Number assignment Additionally, procedures about Tributary Port Number assignment
through control plane are also provided in this document. through control plane are also provided in this document.
skipping to change at page 6, line 26 skipping to change at page 6, line 26
Value G-PID Type LSP Encoding Type Value G-PID Type LSP Encoding Type
----- ---------- ----------------- ----- ---------- -----------------
59(TBA) G.709 ODU-1.25G G.709 ODUk 59(TBA) G.709 ODU-1.25G G.709 ODUk
60(TBA) G.709 ODU-any G.709 ODUk 60(TBA) G.709 ODU-any G.709 ODUk
61(TBA) CBRc G.709 ODUk 61(TBA) CBRc G.709 ODUk
62(TBA) 1000BASE-X G.709 ODUk (k=0) 62(TBA) 1000BASE-X G.709 ODUk (k=0)
63(TBA) FC-1200 G.709 ODUk (k=2e) 63(TBA) FC-1200 G.709 ODUk (k=2e)
Note: Values 59 and 60 include mapping of SDH. Note: Values 59 and 60 include mapping of SDH.
Note that the mapping types for ODUj into OPUk are unambiguously per
Table 7-10 of [G709-2012], so it does not need to carry mapping type
information in the signaling.
5. Extensions for Traffic Parameters for the Evolving G.709 5. Extensions for Traffic Parameters for the Evolving G.709
The Traffic Parameters for OTN-TDM capable Switching Type are carried The Traffic Parameters for OTN-TDM capable Switching Type are carried
in the OTN-TDM SENDER_TSPEC and FLOWSPEC objects. The objects have in the OTN-TDM SENDER_TSPEC and FLOWSPEC objects. The objects have
the following class and type: the following class and type:
- OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (TBA) - OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (TBA)
- OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (TBA) - OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (TBA)
The format of Traffic Parameters in these two objects is defined as The format of Traffic Parameters in these two objects is defined as
follows: 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 | Tolerance | | Signal Type | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) | | NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit_Rate | | Bit_Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Signal Type: 8 bits Signal Type: 8 bits
As defined in [RFC4328] Section 3.2.1, with the following As defined in [RFC4328] Section 3.2.1, with the following
additional values: additional values:
Value Type Value Type
----- ---- ----- ----
4 ODU4 (i.e., 100 Gbps) 4 ODU4 (i.e., 100 Gbps)
9 OCh at 100 Gbps 9 OCh at 100 Gbps
10 ODU0 (i.e., 1.25 Gbps) 10 ODU0 (i.e., 1.25 Gbps)
11 ODU2e (i.e., 10Gbps for FC1200 and GE LAN) 11 ODU2e (i.e., 10Gbps for FC1200 and GE LAN)
12~19 Reserved (for future use) 12~19 Reserved (for future use)
skipping to change at page 7, line 22 skipping to change at page 7, line 25
11 ODU2e (i.e., 10Gbps for FC1200 and GE LAN) 11 ODU2e (i.e., 10Gbps for FC1200 and GE LAN)
12~19 Reserved (for future use) 12~19 Reserved (for future use)
20 ODUflex(CBR) (i.e., 1.25*N Gbps) 20 ODUflex(CBR) (i.e., 1.25*N Gbps)
21 ODUflex(Generic Framing Procedure-Framed (GFP-F)), 21 ODUflex(Generic Framing Procedure-Framed (GFP-F)),
resizable (i.e., 1.25*N Gbps) resizable (i.e., 1.25*N Gbps)
22 ODUflex(GFP-F), non resizable (i.e., 1.25*N Gbps) 22 ODUflex(GFP-F), non resizable (i.e., 1.25*N Gbps)
23~255 Reserved (for future use) 23~255 Reserved (for future use)
NVC: 16 bits NVC: 16 bits
As defined in [RFC4328] Section 3.2.3. As defined in [RFC4328] Section 3.2.3. This field MUST be set to
0 for ODUflex Signal Types.
Multiplier (MT): 16 bits Multiplier (MT): 16 bits
As defined in [RFC4328] Section 3.2.4. As defined in [RFC4328] Section 3.2.4. This field MUST be set to
1 for ODUflex Signal Types.
Bit_Rate: 32 bits Bit_Rate: 32 bits
In case of ODUflex including ODUflex(CBR) and ODUflex(GFP) signal In case of ODUflex including ODUflex(CBR) and ODUflex(GFP) Signal
types, this field indicates the nominal bit rate of ODUflex Types, this field indicates the nominal bit rate of ODUflex
expressed in bytes per second, encoded as a 32-bit IEEE single- expressed in bytes per second, encoded as a 32-bit IEEE single-
precision floating-point number (referring to [RFC4506] and precision floating-point number (referring to [RFC4506] and
[IEEE]). For other signal types, this field is not necessary and [IEEE]). For other Signal Types, this field MUST be set to zero
MUST be set to 0. on transmission and MUST be ignored on receipt and SHOULD be
passed unmodified by transit nodes.
Tolerance: 16 bits
In case of ODUflex(CBR) signal type, this field indicates the bit
rate tolerance (part per million, ppm) of the ODUflex(CBR)
encoded as an unsigned integer. The ODUflex(CBR) bit rate
tolerance is always specified as 100 ppm per Table 7-2 of [G709-
2012], so it MUST be set to 100ppm. For other signal types, this
field is not necessary and MUST be set to 0.
5.1. Usage of ODUflex(CBR) Traffic Parameters 5.1. Usage of ODUflex(CBR) Traffic Parameters
In case of ODUflex(CBR), the information of Bit_Rate and Tolerance in In case of ODUflex(CBR), the information of Bit_Rate carried in the
the ODUflex Traffic Parameters MUST be used to determine the actual ODUflex Traffic Parameters MUST be used to determine the actual
bandwidth of ODUflex(CBR) (i.e., Bit_Rate * (1 +/- Tolerance)). bandwidth of ODUflex(CBR) (i.e., Bit_Rate * (1 +/- Tolerance)).
Therefore the total number of tributary slots N in the HO ODUk link Therefore the total number of tributary slots N in the HO ODUk link
can be reserved correctly. Here: can be reserved correctly. Here:
N = Ceiling of N = Ceiling of
ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance) ODUflex(CBR) nominal bit rate * (1 + ODUflex(CBR) bit rate tolerance)
--------------------------------------------------------------------- ---------------------------------------------------------------------
ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance)
skipping to change at page 8, line 50 skipping to change at page 8, line 42
Note that: Note that:
Minimum bit rate of ODUTk.ts = Minimum bit rate of ODUTk.ts =
ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance) ODTUk.ts nominal bit rate * (1 - HO OPUk bit rate tolerance)
Maximum bit rate of ODTUk.ts = Maximum bit rate of ODTUk.ts =
ODTUk.ts nominal bit rate * (1 + HO OPUk bit rate tolerance) ODTUk.ts nominal bit rate * (1 + HO OPUk bit rate tolerance)
Where: HO OPUk bit rate tolerance = 20ppm Where: HO OPUk bit rate tolerance = 20ppm
Note that the bit rate tolerance is implicit in Signal Type and the
ODUflex(CBR) bit rate tolerance is fixed and it is equal to 100ppm as
described in Table 7-2 of [G709-2012].
Therefore, a node receiving a PATH message containing ODUflex(CBR) Therefore, a node receiving a PATH message containing ODUflex(CBR)
nominal bit rate and tolerance can allocate precise number of nominal bit rate can allocate precise number of tributary slots and
tributary slots and set up the cross-connection for the ODUflex set up the cross-connection for the ODUflex service.
service.
Note that for different ODUk, the bit rates of the tributary slots Note that for different ODUk, the bit rates of the tributary slots
are different, and so the total number of tributary slots to be are different, and so the total number of tributary slots to be
reserved for the ODUflex(CBR) MAY not be the same on different HO reserved for the ODUflex(CBR) MAY not be the same on different HO
ODUk links. ODUk links.
An example is given below to illustrate the usage of ODUflex(CBR) An example is given below to illustrate the usage of ODUflex(CBR)
Traffic Parameters. Traffic Parameters.
As shown in Figure 1, assume there is an ODUflex(CBR) service As shown in Figure 1, assume there is an ODUflex(CBR) service
skipping to change at page 10, line 45 skipping to change at page 10, line 41
There is no Adspec associated with the OTN-TDM SENDER_TSPEC. Either There is no Adspec associated with the OTN-TDM SENDER_TSPEC. Either
the Adspec is omitted or an Int-serv Adspec with the Default General the Adspec is omitted or an Int-serv Adspec with the Default General
Characterization Parameters and Guaranteed Service fragment is used, Characterization Parameters and Guaranteed Service fragment is used,
see [RFC2210]. see [RFC2210].
For a particular sender in a session, the contents of the FLOWSPEC For a particular sender in a session, the contents of the FLOWSPEC
object received in a Resv message SHOULD be identical to the contents object received in a Resv message SHOULD be identical to the contents
of the SENDER_TSPEC object received in the corresponding Path of the SENDER_TSPEC object received in the corresponding Path
message. If the objects do not match, a ResvErr message with a message. If the objects do not match, a ResvErr message with a
"Traffic Control Error/Bad Flowspec value" error SHOULD be generated. "Traffic Control Error/Bad Flowspec value" error MUST be 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 the interfaces on which the LSP will be established, can support the
requested Signal Type, NVC, Tolerance and Bit_Rate values. If the requested Signal Type, NVC and Bit_Rate values. If the requested
requested value(s) cannot be supported, the receiver node MUST value(s) cannot be supported, the receiver node MUST generate a
generate a PathErr message with a "Traffic Control Error/Service PathErr message with a "Traffic Control Error/Service unsupported"
unsupported" indication (see [RFC2205]). indication (see [RFC2205]).
In addition, if the MT field is received with a zero value, the node In addition, if the MT field is received with a zero value, the node
MUST generate a PathErr message with a "Traffic Control Error/Bad MUST generate a PathErr message with a "Traffic Control Error/Bad
Tspec value" indication (see [RFC2205]). Tspec value" indication (see [RFC2205]).
Further, if the Signal Type is not ODU1, ODU2 or ODU3, and the NVC Further, if the Signal Type is not ODU1, ODU2 or ODU3, and the NVC
field is not 0, the node MUST generate a PathErr message with a field is not 0, the node MUST generate a PathErr message with a
"Traffic Control Error/Bad Tspec value" indication (see [RFC2205]). "Traffic Control Error/Bad Tspec value" indication (see [RFC2205]).
6. Generalized Label 6. Generalized Label
skipping to change at page 14, line 14 skipping to change at page 14, line 10
The ingress node or upstream node MAY also generate Suggested Label The ingress node or upstream node MAY also generate Suggested Label
to indicate the preference of TS resource and TPN value on the to indicate the preference of TS resource and TPN value on the
outgoing interface in the downstream direction. The downstream node outgoing interface in the downstream direction. The downstream node
is not REQUIRED to use the Suggested Label and MAY use another label is not REQUIRED to use the Suggested Label and MAY use another label
based on local decision and send it to the upstream node, as based on local decision and send it to the upstream node, as
described in [RFC3473]. described in [RFC3473].
When an upstream node receives a Resv message containing an LABEL When an upstream node receives a Resv message containing an LABEL
object with an OTN-TDM label, it MUST firstly identify which ODU object with an OTN-TDM label, it MUST firstly identify which ODU
signal type is multiplexed or mapped into which ODU signal type Signal Type is multiplexed or mapped into which ODU Signal Type
accordingly to the Traffic Parameters and the IF_ID RSVP_HOP Object accordingly to the Traffic Parameters and the IF_ID RSVP_HOP Object
in the received message. in the received message.
- In case of ODUj to ODUk multiplexing, the node MUST retrieve the - In case of ODUj to ODUk multiplexing, the node MUST retrieve the
reserved tributary slots in the ODUk by its downstream neighbor reserved tributary slots in the ODUk by its downstream neighbor
node according to the position of the bits that are set to 1 in node according to the position of the bits that are set to 1 in
the Bit Map field. The node determines the TS type (according to the Bit Map field. The node determines the TS type (according to
the total TS number of the ODUk, or pre-configured TS type), so the total TS number of the ODUk, or pre-configured TS type), so
that the node can multiplex the ODUj into the ODUk based on the TS that the node can multiplex the ODUj into the ODUk based on the TS
type. The node MUST also retrieve the TPN value assigned by its type. The node MUST also retrieve the TPN value assigned by its
skipping to change at page 14, line 46 skipping to change at page 14, line 42
label format. For example, for HO ODU2 link, the value of the label format. For example, for HO ODU2 link, the value of the
length filed will be 4 or 8, which indicates the TS granularity is length filed will be 4 or 8, which indicates the TS granularity is
2.5Gbps or 1.25Gbps, respectively. 2.5Gbps or 1.25Gbps, respectively.
- In case of ODUk to OTUk mapping, the size of Bit Map field MUST be - In case of ODUk to OTUk mapping, the size of Bit Map field MUST be
0 and no additional procedure is needed. 0 and no additional procedure is needed.
When a downstream node or egress node receives a Path message When a downstream node or egress node receives a Path message
containing Generalized Label Request object for setting up an ODUj containing Generalized Label Request object for setting up an ODUj
LSP from its upstream neighbor node, the node MUST generate an OTN- LSP from its upstream neighbor node, the node MUST generate an OTN-
TDM label according to the signal type of the requested LSP and the TDM label according to the Signal Type of the requested LSP and the
free resources (i.e., free tributary slots of ODUk) that will be free resources (i.e., free tributary slots of ODUk) that will be
reserved for the LSP, and send the label to its upstream neighbor reserved for the LSP, and send the label to its upstream neighbor
node. node.
- In case of ODUj to ODUk multiplexing, the node MUST firstly - In case of ODUj to ODUk multiplexing, the node MUST firstly
determine the size of the Bit Map field according to the signal determine the size of the Bit Map field according to the Signal
type and the tributary slot type of ODUk, and then set the bits to Type and the tributary slot type of ODUk, and then set the bits to
1 in the Bit Map field corresponding to the reserved tributary 1 in the Bit Map field corresponding to the reserved tributary
slots. The node MUST also assign a valid TPN, which MUST NOT slots. The node MUST also assign a valid TPN, which MUST NOT
collide with other TPN value used by existing LO ODU connections collide with other TPN value used by existing LO ODU connections
in the selected HO ODU link, and configure the Expected MSI in the selected HO ODU link, and configure the Expected MSI
(ExMSI) using this TPN. Then, the assigned TPN MUST be filled into (ExMSI) using this TPN. Then, the assigned TPN MUST be filled into
the label. the label.
- In case of ODUk to OTUk mapping, TPN field MUST be set to 0. Bit - In case of ODUk to OTUk mapping, TPN field MUST be set to 0. Bit
Map information is not REQUIRED and MUST NOT be included, so Map information is not REQUIRED and MUST NOT be included, so
Length field MUST be set to 0 as well. Length field MUST be set to 0 as well.
skipping to change at page 15, line 47 skipping to change at page 15, line 42
and of ACCEPTABLE_LABEL_SET objects is not modified by this document. and of ACCEPTABLE_LABEL_SET objects is not modified by this document.
A received label SHALL be considered unacceptable when one of the A received label SHALL be considered unacceptable when one of the
following cases occurs: following cases occurs:
- The received label doesn't conform to local policy; - The received label doesn't conform to local policy;
- Invalid value in the length field; - Invalid value in the length field;
- The selected link only supports 2.5Gbps TS granularity while the - The selected link only supports 2.5Gbps TS granularity while the
Length field in the label along with ODUk signal type indicates Length field in the label along with ODUk Signal Type indicates
the 1.25Gbps TS granularity; the 1.25Gbps TS granularity;
- The label includes an invalid TPN value that breaks the TPN - The label includes an invalid TPN value that breaks the TPN
assignment rules; assignment rules;
- The indicated resources (i.e., the number of "1" in the Bit Map - The indicated resources (i.e., the number of "1" in the Bit Map
field) are inconsistent with the Traffic Parameters. field) are inconsistent with the Traffic Parameters.
6.3. Supporting Virtual Concatenation and Multiplication 6.3. Supporting Virtual Concatenation and Multiplication
skipping to change at page 16, line 25 skipping to change at page 16, line 22
In case of multiplexed virtually concatenated signals (NVC > 1), the In case of multiplexed virtually concatenated signals (NVC > 1), the
first label MUST indicate the components of the first virtually first label MUST indicate the components of the first virtually
concatenated signal; the second label MUST indicate the components of concatenated signal; the second label MUST indicate the components of
the second virtually concatenated signal; and so on. In case of the second virtually concatenated signal; and so on. In case of
multiplication of multiplexed virtually concatenated signals (MT > multiplication of multiplexed virtually concatenated signals (MT >
1), the first label MUST indicate the components of the first 1), the first label MUST indicate the components of the first
multiplexed virtually concatenated signal; the second label MUST multiplexed virtually concatenated signal; the second label MUST
indicate components of the second multiplexed virtually concatenated indicate components of the second multiplexed virtually concatenated
signal; and so on. signal; and so on.
Support for Virtual Concatenation of ODU1, ODU2 and ODU3 signal Support for Virtual Concatenation of ODU1, ODU2 and ODU3 Signal
types, as defined by [RFC6344], is not modified by this document. Types, as defined by [RFC6344], is not modified by this document.
Virtual Concatenation of other signal types is not supported by Virtual Concatenation of other Signal Types is not supported by
[G709-2012]. [G709-2012].
Multiplier (MT) usage is as defined in [RFC6344] and [RFC4328]. Multiplier (MT) usage is as defined in [RFC6344] and [RFC4328].
6.4. Examples 6.4. Examples
The following examples are given in order to illustrate the label The following examples are given in order to illustrate the label
format described in Section 6.1 of this document. format described in Section 6.1 of this document.
(1) ODUk into OTUk mapping: (1) ODUk into OTUk mapping:
skipping to change at page 20, line 22 skipping to change at page 20, line 22
plane. plane.
10. IANA Considerations 10. IANA Considerations
Three RSVP C-Types are defined for OTN-TDM Traffic Parameters and Three RSVP C-Types are defined for OTN-TDM Traffic Parameters and
OTN-TDM Generalized Label in this document: OTN-TDM Generalized Label in this document:
http://www.iana.org/assignments/rsvp-parameters http://www.iana.org/assignments/rsvp-parameters
- OTN-TDM SENDER_TSPEC and FLOWSPEC objects: - OTN-TDM SENDER_TSPEC and FLOWSPEC objects:
o OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (see o OTN-TDM SENDER_TSPEC Object: Class = 12, C-Type = 7 (see
Section 5) Section 5)
o OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (see Section 5)
- OTN-TDM Generalized Label Object:
o OTN-TDM Generalized Label Object: Class = 16, C-Type = 2 (see o OTN-TDM FLOWSPEC Object: Class = 9, C-Type = 7 (see Section 5)
Section 6.1)
IANA maintains the "Generalized Multi-Protocol Label Switching IANA maintains the "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Parameters" registry (see (GMPLS) Signaling Parameters" registry (see
http://www.iana.org/assignments/gmpls-sig-parameters). "Generalized http://www.iana.org/assignments/gmpls-sig-parameters). "Generalized
PIDs (G-PID)" subregistry is included in this registry, which will be PIDs (G-PID)" subregistry is included in this registry, which will be
extended and updated by this document as below: extended and updated by this document as below:
- Generalized PID (G-PID): - Generalized PID (G-PID):
Name: G-PID Name: G-PID
skipping to change at page 22, line 43 skipping to change at page 22, line 36
[RFC6344] G. Bernstein et al, "Operating Virtual Concatenation (VCAT) [RFC6344] G. Bernstein et al, "Operating Virtual Concatenation (VCAT)
and the Link Capacity Adjustment Scheme (LCAS) with and the Link Capacity Adjustment Scheme (LCAS) with
Generalized Multi-Protocol Label Switching (GMPLS)", Generalized Multi-Protocol Label Switching (GMPLS)",
RFC6344, August 2011. RFC6344, August 2011.
11.2. Informative References 11.2. Informative References
[OTN-FWK] Fatai Zhang et al, "Framework for GMPLS and PCE Control of [OTN-FWK] Fatai Zhang et al, "Framework for GMPLS and PCE Control of
G.709 Optical Transport Networks", Work in Progress: draft- G.709 Optical Transport Networks", Work in Progress: draft-
ietf-ccamp-gmpls-g709-framework, November 2012. ietf-ccamp-gmpls-g709-framework, February 2013.
[OTN-INFO] S. Belotti et al, "Information model for G.709 Optical [OTN-INFO] S. Belotti et al, "Information model for G.709 Optical
Transport Networks (OTN)", Work in Progress: draft-ietf- Transport Networks (OTN)", Work in Progress: draft-ietf-
ccamp-otn-g709-info-model, January 2013. ccamp-otn-g709-info-model, April 2013.
[OTN-OSPF] D. Ceccarelli et al, "Traffic Engineering Extensions to [OTN-OSPF] D. Ceccarelli et al, "Traffic Engineering Extensions to
OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709
OTN Networks", Work in Progress: draft-ietf-ccamp-gmpls- OTN Networks", Work in Progress: draft-ietf-ccamp-gmpls-
ospf-g709v3, January 2013. ospf-g709v3, April 2013.
[G709-2012] ITU-T, "Interfaces for the Optical Transport Network [G709-2012] ITU-T, "Interfaces for the Optical Transport Network
(OTN)", G.709/Y.1331 Recommendation, February 2012. (OTN)", G.709/Y.1331 Recommendation, February 2012.
[G7044] ITU-T, "Hitless adjustment of ODUflex", G.7044/Y.1347, [G7044] ITU-T, "Hitless adjustment of ODUflex", G.7044/Y.1347,
October 2011. October 2011.
[RFC4506] M. Eisler, Ed., "XDR: External Data Representation [RFC4506] M. Eisler, Ed., "XDR: External Data Representation
Standard", RFC 4506, May 2006. Standard", RFC 4506, May 2006.
skipping to change at page 27, line 44 skipping to change at line 1182
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
 End of changes. 30 change blocks. 
53 lines changed or deleted 50 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/