draft-ietf-ccamp-gmpls-signaling-g709v3-00.txt   draft-ietf-ccamp-gmpls-signaling-g709v3-01.txt 
Network Working Group Fatai Zhang, Ed. Network Working Group Fatai Zhang, Ed.
Internet Draft Huawei Internet Draft Huawei
Category: Standards Track Guoying Zhang Category: Standards Track Guoying Zhang
CATR CATR
Sergio Belotti Sergio Belotti
Alcatel-Lucent Alcatel-Lucent
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
Khuzema Pithewan Khuzema Pithewan
Infinera Infinera
Expires: April 17, 2012 October 17, 2011 Expires: April 26, 2012 October 26, 2011
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-00.txt draft-ietf-ccamp-gmpls-signaling-g709v3-01.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 April 17, 2012. This Internet-Draft will expire on April 26, 2012.
Abstract Abstract
Recent progress in ITU-T Recommendation G.709 standardization has Recent progress in ITU-T Recommendation G.709 standardization has
introduced new ODU containers (ODU0, ODU4, ODU2e and ODUflex) and introduced new ODU containers (ODU0, ODU4, ODU2e and ODUflex) and
enhanced Optical Transport Networking (OTN) flexibility. Several enhanced Optical Transport Networking (OTN) flexibility. Several
recent documents have proposed ways to modify GMPLS signaling recent documents have proposed ways to modify GMPLS signaling
protocols to support these new OTN features. protocols to support these new OTN features.
It is important that a single solution is developed for use in GMPLS It is important that a single solution is developed for use in GMPLS
skipping to change at page 2, line 30 skipping to change at page 2, line 30
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].
Table of Contents Table of Contents
1. Introduction .................................................. 3 1. Introduction .................................................. 3
2. Terminology ................................................... 4 2. Terminology ................................................... 4
3. GMPLS Extensions for the Evolving G.709 - Overview ............ 4 3. GMPLS Extensions for the Evolving G.709 - Overview ............ 4
4. Extensions for Traffic Parameters for the Evolving G.709 ...... 5 4. Generalized Label Request ..................................... 5
4.1. Usage of ODUflex(CBR) Traffic Parameter .................. 6 5. Extensions for Traffic Parameters for the Evolving G.709 ...... 5
4.2. Example of ODUflex(CBR) Traffic Parameter ................ 7 5.1. Usage of ODUflex(CBR) Traffic Parameter .................. 7
5. Generalized Label ............................................. 8 5.2. Usage of ODUflex(GFP) Traffic Parameters ................. 9
5.1. New definition of ODU Generalized Label .................. 8 6. Generalized Label ............................................. 9
5.2. Examples ................................................ 11 6.1. New definition of ODU Generalized Label ................. 10
5.3. Label Distribution Procedure ............................ 12 6.2. Examples ................................................ 12
5.3.1. Notification on Label Error ........................ 13 6.3. Label Distribution Procedure ............................ 14
5.4. Supporting Virtual Concatenation and Multiplication ..... 14 6.3.1. Notification on Label Error ........................ 15
5.5. Control Plane Backward Compatibility Considerations ..... 14 6.4. Supporting Virtual Concatenation and Multiplication ..... 15
6. Supporting Multiplexing Hierarchy ............................ 15 6.5. Control Plane Backward Compatibility Considerations ..... 16
6.1. ODU FA-LSP Creation ..................................... 17 7. Supporting Multiplexing Hierarchy ............................ 17
7. Security Considerations ...................................... 17 7.1. ODU FA-LSP Creation ..................................... 18
8. IANA Considerations .......................................... 17 8. Security Considerations ...................................... 18
9. References ................................................... 17 9. IANA Considerations .......................................... 18
9.1. Normative References .................................... 17 10. References .................................................. 19
9.2. Informative References .................................. 19 10.1. Normative References ................................... 19
10.2. Informative References ................................. 20
10. Contributors ............................................... 19 11. Contributors ................................................ 21
11. Authors' Addresses ......................................... 20 12. Authors' Addresses .......................................... 21
12. Acknowledgment ............................................. 22 13. Acknowledgment .............................................. 24
1. Introduction 1. Introduction
Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends Generalized Multi-Protocol Label Switching (GMPLS) [RFC3945] extends
MPLS to include Layer-2 Switching (L2SC), Time-Division Multiplex MPLS to include Layer-2 Switching (L2SC), Time-Division Multiplex
(e.g., SONET/SDH, PDH, and ODU), Wavelength (OCh, Lambdas) Switching, (e.g., SONET/SDH, PDH, and ODU), Wavelength (OCh, Lambdas) Switching,
and Spatial Switching (e.g., incoming port or fiber to outgoing port and Spatial Switching (e.g., incoming port or fiber to outgoing port
or fiber). [RFC3471] presents a functional description of the or fiber). [RFC3471] presents a functional description of the
extensions to Multi-Protocol Label Switching (MPLS) signaling extensions to Multi-Protocol Label Switching (MPLS) signaling
required to support Generalized MPLS. RSVP-TE-specific formats and required to support Generalized MPLS. RSVP-TE-specific formats and
skipping to change at page 4, line 17 skipping to change at page 4, line 17
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-V3]. The corresponding and ODUflex containers are specified in [G709-V3]. The corresponding
new signal types are summarized below: 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
A new Tributary Slot (TS) granularity (i.e., 1.25 Gbps) is also A new Tributary Slot (TS) granularity (i.e., 1.25 Gbps) is also
described in [G709-V3]. Thus, there are now two TS granularities for described in [G709-V3]. Thus, there are now two TS granularities for
the foundation OTN ODU1, ODU2 and ODU3 containers. The TS granularity the foundation OTN ODU1, ODU2 and ODU3 containers. The TS granularity
at 2.5 Gbps is used on legacy interfaces while the new 1.25 Gbps is at 2.5 Gbps is used on legacy interfaces while the new 1.25 Gbps is
used on the new interfaces. used on the new interfaces.
In addition to the support of ODUk mapping into OTUk (k = 1, 2, 3, 4), In addition to the support of ODUk mapping into OTUk (k = 1, 2, 3, 4),
the evolving OTN [G.709-V3] encompasses the multiplexing of ODUj (j = the evolving OTN [G.709-V3] encompasses the multiplexing of ODUj (j =
0, 1, 2, 2e, 3, flex) into an ODUk (k > j), as described in Section 0, 1, 2, 2e, 3, flex) into an ODUk (k > j), as described in Section
3.1.2 of [OTN-frwk]. 3.1.2 of [OTN-FWK].
Virtual Concatenation (VCAT) of OPUk (OPUk-Xv, k = 1/2/3, X = 1...256) Virtual Concatenation (VCAT) of OPUk (OPUk-Xv, k = 1/2/3, X = 1...256)
is also supported by [OTN-V3]. Note that VCAT of OPU0 / OPU2e / OPU4 is also supported by [OTN-V3]. Note that VCAT of OPU0 / OPU2e / OPU4
/ OPUflex is not supported per [OTN-V3]. / OPUflex is not supported per [OTN-V3].
[RFC4328] describes GMPLS signaling extensions to support the control [RFC4328] describes GMPLS signaling extensions to support the control
for G.709 Optical Transport Networks (OTN) [G709-V1]. However, for G.709 Optical Transport Networks (OTN) [G709-V1]. However,
[RFC4328] needs to be updated because it does not provide the means [RFC4328] needs to be updated because it does not provide the means
to signal all the new signal types and related mapping and to signal all the new signal types and related mapping and
multiplexing functionalities. Moreover, it supports only the multiplexing functionalities. Moreover, it supports only the
deprecated auto-MSI mode which assumes that the Tributary Port Number deprecated auto-MSI mode which assumes that the Tributary Port Number
is automatically assigned in the transmit direction and not checked is automatically assigned in the transmit direction and not checked
in the receive direction. 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.
4. Extensions for Traffic Parameters for the Evolving G.709 4. Generalized Label Request
The Generalized Label Request, as described in [RFC3471], carries the
LSP Encoding Type, the Switching Type and the Generalized Protocol
Identifier (G-PID).
[RFC4328] extends the Generalized Label Request, introducing two new
code-points for the LSP Encoding Type (i.e., G.709 ODUk (Digital Path)
and G.709 Optical Channel) and adding a list of G-PID values in order
to accommodate [G709-v1].
This document follows these extensions and a new Switching Type is
introduced to indicate the ODUk switching capability [G709-V3] in
order to support backward compatibility with [RFC4328], as described
in [OTN-FWK]. The new Switching Type (101, TBA by IANA) is defined
in [OTN-OSPF].
5. Extensions for Traffic Parameters for the Evolving G.709
The traffic parameters for G.709 are defined as follows: The traffic parameters for G.709 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 | Tolerance | NMC | | Signal Type | Reserved | NMC/ Tolerance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NVC | Multiplier (MT) | | NVC | Multiplier (MT) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bit_Rate | | Bit_Rate |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Signal Type needs to be extended in order to cover the new Signal The Signal Type needs to be extended in order to cover the new Signal
Type introduced by the evolving OTN. The new Signal Type values are Type introduced by the evolving OTN. The new Signal Type values are
extended as follows: extended as follows:
skipping to change at page 5, line 46 skipping to change at page 6, line 18
8 OCh at 40 Gbps 8 OCh at 40 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)
20 ODUflex(CBR) (i.e., 1.25*N Gbps) 20 ODUflex(CBR) (i.e., 1.25*N Gbps)
21 ODUflex(GFP-F), resizable (i.e., 1.25*N Gbps) 21 ODUflex(GFP-F), 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)
NMC/Tolerance:
This field is redefined from the original definition in [RFC4328].
NMC field defined in [RFC4328] cannot be fixed value for an end-to-
end circuit involving dissimilar OTN link types. For example, ODU2e
requires 9 TS on ODU3 and 8 TS on ODU4. Usage of NMC field is
deprecated and should be used only with [RFC4328] generalized label
format for backwards compatibility reasons. For the new generalized
label format as defined in this document this field is interpreted as
Tolerance.
In case of ODUflex(CBR), the Bit_Rate and Tolerance fields MUST be In case of ODUflex(CBR), the Bit_Rate and Tolerance fields MUST be
used together to represent the actual bandwidth of ODUflex, where: used together to represent the actual bandwidth of ODUflex, where:
- The Bit_Rate field indicates the nominal bit rate of ODUflex(CBR) - The Bit_Rate field indicates the nominal bit rate of ODUflex(CBR)
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]). [IEEE]). The value contained in the Bit Rate field has to keep
into account both 239/238 factor and the Transcoding factor.
- The Tolerance field indicates the bit rate tolerance (part per - The Tolerance field indicates the bit rate tolerance (part per
million, ppm) of the ODUflex(CBR) encoded as an unsigned integer, million, ppm) of the ODUflex(CBR) encoded as an unsigned integer,
which is bounded in 0~100ppm. which is bounded in 0~100ppm.
For example, for an ODUflex(CBR) service with Bit_Rate = 2.5Gbps and For example, for an ODUflex(CBR) service with Bit_Rate = 2.5Gbps and
Tolerance = 100ppm, the actual bandwidth of the ODUflex is: Tolerance = 100ppm, the actual bandwidth of the ODUflex is:
2.5Gbps * (1 +/- 100ppm) 2.5Gbps * (1 +/- 100ppm)
In case of ODUflex(GFP), the Bit_Rate field is used to indicate the
nominal bit rate of the ODUflex(GFP), which implies the number of
tributary slots requested for the ODUflex(GFP). Since the tolerance
of ODUflex(GFP) makes no sense on tributary slot resource reservation,
the Tolerance field for ODUflex(GFP) is not necessary and MUST be
filled with 0.
In case of other ODUk signal types, the Bit_Rate and Tolerance fields In case of other ODUk signal types, the Bit_Rate and Tolerance fields
are not necessary and MUST be set to 0. are not necessary and MUST be set to 0.
The usage of the NMC, NVC and Multiplier (MT) fields are the same as The usage of the NVC and Multiplier (MT) fields are the same as
[RFC4328]. [RFC4328].
4.1. Usage of ODUflex(CBR) Traffic Parameter 5.1. Usage of ODUflex(CBR) Traffic Parameter
In case of ODUflex(CBR), the information of Bit_Rate and Tolerance in In case of ODUflex(CBR), the information of Bit_Rate and Tolerance in
the ODUflex traffic parameter MUST be used to determine the total the ODUflex traffic parameter MUST be used to determine the total
number of tributary slots N in the HO ODUk link to be reserved. Here: number of tributary slots N in the HO ODUk link to be reserved. 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)
Therefore, a node receiving a PATH message containing ODUflex(CBR) In this formula, the ODUflex(CBR) nominal bit rate is the bit rate of
traffic parameter can allocate precise number of tributary slots and the ODUflex(CBR) on the line side, i.e., the client signal bit rate
set up the cross-connection for the ODUflex service. after applying the 239/238 factor (according to clause 7.3 table 7.2
of [G709-V3]) and the transcoding factor T (if needed) on the CBR
client. According to clauses 17.7.3, 17.7.4 and 17.7.5 of [G709-V3]:
Table 1 below shows the actual bandwidth of the tributary slot of ODUflex(CBR) nominal bit rate = CBR client bit rate * (239/238) / T
ODUk (in Gbps), referring to [G709-V3].
Table 1 - Actual TS bandwidth of ODUk The ODTUk.ts nominal bit rate is the nominal bit rate of the
tributary slot of ODUk, as shown in Table 1 (referring to [G709-V3]).
Table 1 - Actual TS bit rate of ODUk (in Gbps)
ODUk.ts Minimum Nominal Maximum
----------------------------------------------------------
ODU2.ts 1.249 384 632 1.249 409 620 1.249 434 608
ODU3.ts 1.254 678 635 1.254 703 729 1.254 728 823
ODU4.ts 1.301 683 217 1.301 709 251 1.301 735 285
ODUk Minimum Nominal Maximum
-------------------------------------------------------
ODU2 1.249 384 632 1.249 409 620 1.249 434 608
ODU3 1.254 678 635 1.254 703 729 1.254 728 823
ODU4 1.301 683 217 1.301 709 251 1.301 735 285
Note that: Note that:
Minimum bandwidth 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 bandwidth 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
For different ODUk, the bandwidths of the tributary slot are Therefore, a node receiving a PATH message containing ODUflex(CBR)
different, and so the total number of tributary slots to be reserved nominal bit rate and tolerance can allocate precise number of
for the ODUflex(CBR) may not be the same on different HO ODUk links. tributary slots and set up the cross-connection for the ODUflex
This is why the traffic parameter should bring the actual bandwidth service.
information other than the NMC field.
4.2. Example of ODUflex(CBR) Traffic Parameter Note that for different ODUk, the bit rates of the tributary slots
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
ODUk links.
This section gives an example to illustrate the usage of ODUflex(CBR) An example is given below to illustrate the usage of ODUflex(CBR)
traffic parameter. traffic parameter.
As shown in Figure 1, assume there is an ODUflex(CBR) service As shown in Figure 1, assume there is an ODUflex(CBR) service
requesting a bandwidth of (2.5Gbps, +/-100ppm) from node A to node C. requesting a bandwidth of (2.5Gbps, +/-100ppm) from node A to node C.
In other words, the ODUflex traffic parameter indicates that Signal In other words, the ODUflex traffic parameters indicate that Signal
Type is 33 (ODUflex(CBR)), Bit_Rate is 2.5Gbps and Tolerance is Type is 20 (ODUflex(CBR)), Bit_Rate is 2.5Gbps and Tolerance is
100ppm. 100ppm.
+-----+ +---------+ +-----+ +-----+ +---------+ +-----+
| +-------------+ +-----+ +-------------+ | | +-------------+ +-----+ +-------------+ |
| +=============+\| ODU |/+=============+ | | +=============+\| ODU |/+=============+ |
| +=============+/| flex+-+=============+ | | +=============+/| flex+-+=============+ |
| +-------------+ | |\+=============+ | | +-------------+ | |\+=============+ |
| +-------------+ +-----+ +-------------+ | | +-------------+ +-----+ +-------------+ |
| | | | | | | | | | | |
| | ....... | | ....... | | | | ....... | | ....... | |
| A +-------------+ B +-------------+ C | | A +-------------+ B +-------------+ C |
+-----+ HO ODU4 +---------+ HO ODU2 +-----+ +-----+ HO ODU4 +---------+ HO ODU2 +-----+
=========: TS occupied by ODUflex =========: TS occupied by ODUflex
---------: free TS ---------: free TS
Figure 1 - Example of ODUflex(CBR) Traffic Parameter Figure 1 - Example of ODUflex(CBR) Traffic Parameters
- On the HO ODU4 link between node A and B: - On the HO ODU4 link between node A and B:
The maximum bandwidth of the ODUflex equals 2.5Gbps * (1 + The maximum bit rate of the ODUflex(CBR) equals 2.5Gbps * (1 +
100ppm), and the minimum bandwidth of the tributary slot of ODU4 100ppm), and the minimum bit rate of the tributary slot of ODU4
equals 1.301 683 217Gbps, so the total number of tributary slots equals 1.301 683 217Gbps, so the total number of tributary slots
N1 to be reserved on this link is: N1 to be reserved on this link is:
N1 = ceiling (2.5Gbps * (1 + 100ppm) / 1.301 683 217) = 2 N1 = ceiling (2.5Gbps * (1 + 100ppm) / 1.301 683 217Gbps) = 2
- On the HO ODU2 link between node B and C: - On the HO ODU2 link between node B and C:
The maximum bandwidth of the ODUflex equals 2.5Gbps * (1 + The maximum bit rate of the ODUflex equals 2.5Gbps * (1 + 100ppm),
100ppm), and the minimum bandwidth of the tributary slot of ODU2 and the minimum bit rate of the tributary slot of ODU2 equals
equals 1.249 384 632Gbps, so the total number of tributary slots 1.249 384 632Gbps, so the total number of tributary slots N2 to
N2 to be reserved on this link is: be reserved on this link is:
N2 = ceiling (2.5Gbps * (1 + 100ppm) / 1.249 384 632) = 3 N2 = ceiling (2.5Gbps * (1 + 100ppm) / 1.249 384 632Gbps) = 3
5. Generalized Label 5.2. Usage of ODUflex(GFP) Traffic Parameters
[G709-V3-A2] recommends that the ODUflex(GFP) will fill an integral
number of tributary slots of the smallest HO ODUk path over which the
ODUflex(GFP) may be carried, as shown in Table 2.
Table 2 - Recommended ODUflex(GFP) bit rates and tolerance
ODU type | Nominal bit-rate | Tolerance
--------------------------------+------------------+-----------
ODUflex(GFP) of n TS, 1<=n<=8 | n * ODU2.ts | +/-100 ppm
ODUflex(GFP) of n TS, 9<=n<=32 | n * ODU3.ts | +/-100 ppm
ODUflex(GFP) of n TS, 33<=n<=80 | n * ODU4.ts | +/-100 ppm
Accoding to this table, the Bit_Rate field for ODUflex(GFP) MUST
equal to one of the 80 values listed below:
1 * ODU2.ts; 2 * ODU2.ts; ...; 8 * ODU2.ts;
9 * ODU3.ts; 10 * ODU3.ts, ...; 32 * ODU3.ts;
33 * ODU4.ts; 34 * ODU4.ts; ...; 80 * ODU4.ts.
In this way, the number of required tributary slots for the
ODUflex(GFP) (i.e., the value of "n" in Table 2) can be deduced from
the Bit_Rate field.
6. Generalized Label
[RFC3471] has defined the Generalized Label which extends the [RFC3471] has defined the Generalized Label which extends the
traditional label by allowing the representation of not only labels traditional label by allowing the representation of not only labels
which are sent in-band with associated data packets, but also labels which are sent in-band with associated data packets, but also labels
which identify time-slots, wavelengths, or space division multiplexed which identify time-slots, wavelengths, or space division multiplexed
positions. The format of the corresponding RSVP-TE Generalized Label positions. The format of the corresponding RSVP-TE Generalized Label
object is defined in the Section 2.3 of [RFC3473]. object is defined in the Section 2.3 of [RFC3473].
However, for different technologies, we usually need use specific However, for different technologies, we usually need use specific
label rather than the Generalized Label. For example, the label label rather than the Generalized Label. For example, the label
format described in [RFC4606] could be used for SDH/SONET, the label format described in [RFC4606] could be used for SDH/SONET, the label
format in [RFC4328] for G.709. format in [RFC4328] for G.709.
5.1. New definition of ODU Generalized Label 6.1. New definition of ODU Generalized Label
In order to be compatible with new types of ODU signal and new types In order to be compatible with new types of ODU signal and new types
of tributary slot, the following new ODU label format MUST be used: of tributary slot, the following new ODU label format MUST be used:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN | Reserved | Length | | TPN | Reserved | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Bit Map ......... ~ ~ Bit Map ......... ~
skipping to change at page 9, line 35 skipping to change at page 11, line 13
in the data plane. When an LO ODUj is multiplexed into HO ODUk in the data plane. When an LO ODUj is multiplexed into HO ODUk
occupying one or more TSs, a new TPN value is configured at the two occupying one or more TSs, a new TPN value is configured at the two
ends of the HO ODUk link and is put into the related MSI byte(s) in ends of the HO ODUk link and is put into the related MSI byte(s) in
the OPUk overhead at the (traffic) ingress end of the link, so that the OPUk overhead at the (traffic) ingress end of the link, so that
the other end of the link can learn which TS(s) is/are used by the LO the other end of the link can learn which TS(s) is/are used by the LO
ODUj in the data plane. ODUj in the data plane.
According to [G709-V3], the TPN field MUST be set as according to the According to [G709-V3], the TPN field MUST be set as according to the
following tables: following tables:
Table 2 - TPN Assignment Rules (2.5Gbps TS granularity) Table 3 - TPN Assignment Rules (2.5Gbps TS granularity)
+-------+-------+----+----------------------------------------------+ +-------+-------+----+----------------------------------------------+
|HO ODUk|LO ODUj|TPN | TPN Assignment Rules | |HO ODUk|LO ODUj|TPN | TPN Assignment Rules |
+-------+-------+----+----------------------------------------------+ +-------+-------+----+----------------------------------------------+
| ODU2 | ODU1 |1~4 |Fixed, = TS# occupied by ODU1 | | ODU2 | ODU1 |1~4 |Fixed, = TS# occupied by ODU1 |
+-------+-------+----+----------------------------------------------+ +-------+-------+----+----------------------------------------------+
| | ODU1 |1~16|Fixed, = TS# occupied by ODU1 | | | ODU1 |1~16|Fixed, = TS# occupied by ODU1 |
| ODU3 +-------+----+----------------------------------------------+ | ODU3 +-------+----+----------------------------------------------+
| | ODU2 |1~4 |Flexible, != other existing LO ODU2s' TPNs | | | ODU2 |1~4 |Flexible, != other existing LO ODU2s' TPNs |
+-------+-------+----+----------------------------------------------+ +-------+-------+----+----------------------------------------------+
Table 3 - TPN Assignment Rules (1.25Gbps TS granularity)
Table 4 - TPN Assignment Rules (1.25Gbps TS granularity)
+-------+-------+----+----------------------------------------------+ +-------+-------+----+----------------------------------------------+
|HO ODUk|LO ODUj|TPN | TPN Assignment Rules | |HO ODUk|LO ODUj|TPN | TPN Assignment Rules |
+-------+-------+----+----------------------------------------------+ +-------+-------+----+----------------------------------------------+
| ODU1 | ODU0 |1~2 |Fixed, = TS# occupied by ODU0 | | ODU1 | ODU0 |1~2 |Fixed, = TS# occupied by ODU0 |
+-------+-------+----+----------------------------------------------+ +-------+-------+----+----------------------------------------------+
| | ODU1 |1~4 |Flexible, != other existing LO ODU1s' TPNs | | | ODU1 |1~4 |Flexible, != other existing LO ODU1s' TPNs |
| ODU2 +-------+----+----------------------------------------------+ | ODU2 +-------+----+----------------------------------------------+
| |ODU0 & |1~8 |Flexible, != other existing LO ODU0s and | | |ODU0 & |1~8 |Flexible, != other existing LO ODU0s and |
| |ODUflex| |ODUflexes' TPNs | | |ODUflex| |ODUflexes' TPNs |
+-------+-------+----+----------------------------------------------+ +-------+-------+----+----------------------------------------------+
skipping to change at page 11, line 9 skipping to change at page 12, line 32
Note that the Length field in the label format can also be used to Note that the Length field in the label format can also be used to
indicate the TS type of the HO ODUk (i.e., TS granularity at 1.25Gbps indicate the TS type of the HO ODUk (i.e., TS granularity at 1.25Gbps
or 2.5Gbps) since the HO ODUk type can be known from IF_ID RSVP_HOP or 2.5Gbps) since the HO ODUk type can be known from IF_ID RSVP_HOP
Object. In some cases when there is no LMP or routing to make the two Object. In some cases when there is no LMP or routing to make the two
end points of the link to know the TSG, the TSG information used by end points of the link to know the TSG, the TSG information used by
another end can be deduced from the label format. For example, for HO another end can be deduced from the label format. For example, for HO
ODU2 link, the value of the length filed will be 4 or 8, which ODU2 link, the value of the length filed will be 4 or 8, which
indicates the TS granularity is 2.5Gbps or 1.25Gbps, respectively. indicates the TS granularity is 2.5Gbps or 1.25Gbps, respectively.
5.2. Examples 6.2. 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 the previous sections of this document. format described in the previous sections of this document.
(1) ODUk into OTUk mapping: (1) ODUk into OTUk mapping:
In such conditions, the downstream node along an LSP returns a label In such conditions, the downstream node along an LSP returns a label
indicating that the ODUk (k=1, 2, 3, 4) is directly mapped into the indicating that the ODUk (k=1, 2, 3, 4) is directly mapped into the
corresponding OTUk. The following example label indicates an ODU1 corresponding OTUk. The following example label indicates an ODU1
mapped into OTU1. mapped into OTU1.
skipping to change at page 12, line 31 skipping to change at page 14, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TPN = 1 | Reserved | Length = 16 | | TPN = 1 | Reserved | Length = 16 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0| Padded Bits (0) | |0 1 1 0 1 0 1 0 0 0 0 0 0 0 0 0| Padded Bits (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This above label indicates an ODU2 multiplexed into the 2nd, 3rd, 5th This above label indicates an ODU2 multiplexed into the 2nd, 3rd, 5th
and 7th tributary slot of ODU3, wherein there are 16 TS in ODU3 (i.e., and 7th tributary slot of ODU3, wherein there are 16 TS in ODU3 (i.e.,
the type of the tributary slot is 2.5Gbps), and the TPN value is 1. the type of the tributary slot is 2.5Gbps), and the TPN value is 1.
5.3. Label Distribution Procedure 6.3. Label Distribution Procedure
This document does not change the existing label distribution This document does not change the existing label distribution
procedures [RFC4328] for GMPLS except that the new ODUk label MUST be procedures [RFC4328] for GMPLS except that the new ODUk label MUST be
processed as follows. processed as follows.
When a node receives a generalized label request for setting up an When a node receives a generalized label request for setting up an
ODUj LSP from its upstream neighbor node, the node MUST generate an ODUj LSP from its upstream neighbor node, the node MUST generate an
ODU label according to the signal type of the requested LSP and the ODU 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
skipping to change at page 13, line 36 skipping to change at page 15, line 11
In case of ODUk to OTUk mapping, the size of Bit Map field MUST be 0 In case of ODUk to OTUk mapping, the size of Bit Map field MUST be 0
and no additional procedure is needed. and no additional procedure is needed.
Note that the procedures of other label related objects (e.g., Note that the procedures of other label related objects (e.g.,
Upstream Label, Label Set) are similar to the one described above. Upstream Label, Label Set) are similar to the one described above.
Note also that the TPN in the label_ERO MAY not be assigned (i.e., Note also that the TPN in the label_ERO MAY not be assigned (i.e.,
TPN field = 0) if the TPN is requested to be assigned locally. TPN field = 0) if the TPN is requested to be assigned locally.
5.3.1. Notification on Label Error 6.3.1. Notification on Label Error
When receiving an ODUk label from the neighbor node, the node SHOULD When receiving an ODUk label from the neighbor node, the node SHOULD
check the integrity of the label. An error message containing an check the integrity of the label. An error message containing an
"Unacceptable label value" indication ([RFC3209]) SHOULD be sent if "Unacceptable label value" indication ([RFC3209]) SHOULD be sent if
one of the following cases occurs: one of the following cases occurs:
- 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 reserved resources (i.e., the number of "1" in the Bit Map - The reserved resources (i.e., the number of "1" in the Bit Map
field) do not match with the Traffic Parameters. field) do not match with the Traffic Parameters.
5.4. Supporting Virtual Concatenation and Multiplication 6.4. Supporting Virtual Concatenation and Multiplication
As per [VCAT], the VCGs can be created using Co-Signaled style or As per [RFC6344], the VCGs can be created using Co-Signaled style or
Multiple LSPs style. Multiple LSPs style.
In case of Co-Signaled style, the explicit ordered list of all labels In case of Co-Signaled style, the explicit ordered list of all labels
reflects the order of VCG members, which is similar to [RFC4328]. In reflects the order of VCG members, which is similar to [RFC4328]. In
case of multiplexed virtually concatenated signals (NVC > 1), the case of multiplexed virtually concatenated signals (NVC > 1), the
first label indicates the components of the first virtually first label indicates the components of the first virtually
concatenated signal; the second label indicates the components of the concatenated signal; the second label indicates the components of the
second virtually concatenated signal; and so on. In case of second virtually concatenated signal; and so on. In case of
multiplication of multiplexed virtually concatenated signals (MT > 1), multiplication of multiplexed virtually concatenated signals (MT > 1),
the first label indicates the components of the first multiplexed the first label indicates the components of the first multiplexed
virtually concatenated signal; the second label indicates components virtually concatenated signal; the second label indicates components
of the second multiplexed virtually concatenated signal; and so on. of the second multiplexed virtually concatenated signal; and so on.
In case of Multiple LSPs style, multiple control plane LSPs are In case of Multiple LSPs style, multiple control plane LSPs are
created with a single VCG and the VCAT Call can be used to associate created with a single VCG and the VCAT Call can be used to associate
the control plane LSPs. The procedures are similar to section 6 of the control plane LSPs. The procedures are similar to section 6 of
[VCAT]. [RFC6344].
5.5. Control Plane Backward Compatibility Considerations 6.5. Control Plane Backward Compatibility Considerations
Since the [RFC4328] has been deployed in the network for the nodes Since the [RFC4328] has been deployed in the network for the nodes
that support [G709-V1], we call nodes supporting [RFC4328] "legacy that support [G709-V1], we call nodes supporting [RFC4328] "legacy
nodes". Backward compatibility SHOULD be taken into consideration nodes". Backward compatibility SHOULD be taken into consideration
when the new nodes (i.e., nodes that support RSVP-TE extensions when the new nodes (i.e., nodes that support RSVP-TE extensions
defined in this document) and the legacy nodes are interworking. defined in this document) and the legacy nodes are interworking.
For backward compatibility consideration, the new node SHOULD have For backward compatibility consideration, the new node SHOULD have
the ability to generate and parse legacy labels. the ability to generate and parse legacy labels.
skipping to change at page 15, line 38 skipping to change at page 17, line 13
node. node.
o If the neighbor node can support the 1.25Gbps TS, or can support o If the neighbor node can support the 1.25Gbps TS, or can support
other LO ODU types defined in [G709-V3]), the neighbor node SHOULD other LO ODU types defined in [G709-V3]), the neighbor node SHOULD
be treated as new node. be treated as new node.
o If the neighbor node returns a LinkSummaryNack message including o If the neighbor node returns a LinkSummaryNack message including
an ERROR_CODE indicating nonsupport of HO ODU link capability an ERROR_CODE indicating nonsupport of HO ODU link capability
negotiation, the neighbor node SHOULD be treated as a legacy node. negotiation, the neighbor node SHOULD be treated as a legacy node.
6. Supporting Multiplexing Hierarchy 7. Supporting Multiplexing Hierarchy
As described in [OTN-FRWK], one ODUj connection can be nested into As described in [OTN-FWK], one ODUj connection can be nested into
another ODUk (j<k) connection, which forms the multiplexing hierarchy another ODUk (j<k) connection, which forms the multiplexing hierarchy
in the ODU layer. This is useful if there are some intermediate nodes in the ODU layer. This is useful if there are some intermediate nodes
in the network which only support ODUk but not ODUj switching. in the network which only support ODUk but not ODUj switching.
For example, in Figure 3, assume that N3 is a legacy node which only For example, in Figure 3, assume that N3 is a legacy node which only
supports [G709-V1] and does not support ODU0 switching. If an ODU0 supports [G709-V1] and does not support ODU0 switching. If an ODU0
connection between N1 and N5 is required, then we can create an ODU2 connection between N1 and N5 is required, then we can create an ODU2
connection between N2 and N4 (or ODU1 / ODU3 connection, depending on connection between N2 and N4 (or ODU1 / ODU3 connection, depending on
policies and the capabilities of the two ends of the connection), and policies and the capabilities of the two ends of the connection), and
nest the ODU0 into the ODU2 connection. In this way, N3 only needs to nest the ODU0 into the ODU2 connection. In this way, N3 only needs to
skipping to change at page 17, line 5 skipping to change at page 18, line 23
For both methods, when creating an FA-LSP(e.g., ODU2 FA-LSP), the For both methods, when creating an FA-LSP(e.g., ODU2 FA-LSP), the
penultimate hop needs to choose a correct outgoing interface for the penultimate hop needs to choose a correct outgoing interface for the
ODU2 connection, so that the destination node can support ODU2 connection, so that the destination node can support
multiplexing and de-multiplexing LO ODU signal(e.g., ODU0). In order multiplexing and de-multiplexing LO ODU signal(e.g., ODU0). In order
to choose a correct outgoing interface for the penultimate hop of the to choose a correct outgoing interface for the penultimate hop of the
FA-LSP, multiplexing capability (i.e., what client signal type that FA-LSP, multiplexing capability (i.e., what client signal type that
can be adapted directly to this FA-LSP) should be carried in the can be adapted directly to this FA-LSP) should be carried in the
signaling to setup this FA-LSP. In addition, when Auto_Negotiation in signaling to setup this FA-LSP. In addition, when Auto_Negotiation in
the data plane is not enabled, TS granularity may also be needed. the data plane is not enabled, TS granularity may also be needed.
6.1. ODU FA-LSP Creation 7.1. ODU FA-LSP Creation
The required hierarchies and TS type for both ends of an FA-LSP is The required hierarchies and TS type for both ends of an FA-LSP is
for further study. for further study.
7. Security Considerations 8. Security Considerations
This document introduces no new security considerations to the This document introduces no new security considerations to the
existing GMPLS signaling protocols. Referring to [RFC3473], further existing GMPLS signaling protocols. Referring to [RFC3473], further
details of the specific security measures are provided. Additionally, details of the specific security measures are provided. Additionally,
[GMPLS-SEC] provides an overview of security vulnerabilities and [GMPLS-SEC] provides an overview of security vulnerabilities and
protection mechanisms for the GMPLS control plane. protection mechanisms for the GMPLS control plane.
8. IANA Considerations 9. IANA Considerations
- G.709 SENDER_TSPEC and FLOWSPEC objects: - G.709 SENDER_TSPEC and FLOWSPEC objects:
The traffic parameters, which are carried in the G.709 The traffic parameters, which are carried in the G.709
SENDER_TSPEC and FLOWSPEC objects, do not require any new object SENDER_TSPEC and FLOWSPEC objects, do not require any new object
class and type based on [RFC4328]: class and type based on [RFC4328]:
o G.709 SENDER_TSPEC Object: Class = 12, C-Type = 5 [RFC4328] o G.709 SENDER_TSPEC Object: Class = 12, C-Type = 5 [RFC4328]
o G.709 FLOWSPEC Object: Class = 9, C-Type = 5 [RFC4328] o G.709 FLOWSPEC Object: Class = 9, C-Type = 5 [RFC4328]
- Generalized Label Object: - Generalized Label Object:
The new defined ODU label (Section 5) is a kind of generalized The new defined ODU label (Section 6) is a kind of generalized
label. Therefore, the Class-Num and C-Type of the ODU label is label. Therefore, the Class-Num and C-Type of the ODU label is
the same as that of generalized label described in [RFC3473], the same as that of generalized label described in [RFC3473],
i.e., Class-Num = 16, C-Type = 2. i.e., Class-Num = 16, C-Type = 2.
9. References 10. References
9.1. Normative References 10.1. Normative References
[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.
[RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical Switching (GMPLS) Signaling Extensions for G.709 Optical
Transport Networks Control", RFC 4328, Jan 2006. Transport Networks Control", RFC 4328, Jan 2006.
[RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP [RFC3209] D. Awduche et al, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209, December 2001. Tunnels", RFC3209, December 2001.
skipping to change at page 18, line 23 skipping to change at page 19, line 37
Switching (GMPLS) Signaling Functional Description", RFC Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003. 3471, January 2003.
[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label Switching [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label Switching
(GMPLS) Signaling Resource ReserVation Protocol-Traffic (GMPLS) Signaling Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004. (GMPLS) Architecture", RFC 3945, October 2004.
[VCAT] 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)", draft- Generalized Multi-Protocol Label Switching (GMPLS)",
ietf-ccamp-gmpls-vcat-lcas-13.txt, May 4, 2011. RFC6344, August 2011.
[RFC4206] K. Kompella, Y. Rekhter, Ed., " Label Switched Paths (LSP) [RFC4206] K. Kompella, Y. Rekhter, Ed., " Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC6107] K. Shiomoto, A. Farrel, "Procedures for Dynamically [RFC6107] K. Shiomoto, A. Farrel, "Procedures for Dynamically
Signaled Hierarchical Label Switched Paths", RFC6107, Signaled Hierarchical Label Switched Paths", RFC6107,
February 2011. February 2011.
[RFC6001] Dimitri Papadimitriou et al, "Generalized Multi-Protocol [RFC6001] Dimitri Papadimitriou et al, "Generalized Multi-Protocol
Label Switching (GMPLS) Protocol Extensions for Multi-Layer Label Switching (GMPLS) Protocol Extensions for Multi-Layer
and Multi-Region Networks (MLN/MRN)", RFC6001, February 21, and Multi-Region Networks (MLN/MRN)", RFC6001, February 21,
2010. 2010.
[OTN-frwk] 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", draft-ietf-ccamp-gmpls- G.709 Optical Transport Networks", draft-ietf-ccamp-gmpls-
g709-framework-04.txt, March 11, 2011. g709-framework-05.txt, September 9, 2011.
[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)", draft-ietf-ccamp-otn-g709-info- Transport Networks (OTN)", draft-ietf-ccamp-otn-g709-info-
model-00.txt, April 18, 2011. model-01.txt, September 21, 2011.
[OTN-OSPF] D. Ceccarelli et al, "Traffic Engineering Extensions to
OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709
OTN Networks", draft-ietf-ccamp-gmpls-ospf-g709v3-00.txt,
October 13, 2011
[OTN-LMP] Fatai Zhang, Ed., "Link Management Protocol (LMP) [OTN-LMP] Fatai Zhang, Ed., "Link Management Protocol (LMP)
extensions for G.709 Optical Transport Networks", draft- extensions for G.709 Optical Transport Networks", draft-
zhang-ccamp-gmpls-g.709-lmp-discovery-04.txt, April 6, 2011. zhang-ccamp-gmpls-g.709-lmp-discovery-04.txt, April 6, 2011.
[G709-V3] ITU-T, "Interfaces for the Optical Transport Network (OTN) [G709-V3] ITU-T, "Interfaces for the Optical Transport Network (OTN)
", G.709/Y.1331, December 2009. ", G.709/Y.1331, December 2009.
9.2. Informative References [G709-V3-A2] ITU-T, "Interfaces for the Optical Transport Network
(OTN) Amendment 2", G.709/y.1331 Amendment 2, April 2011.
10.2. Informative References
[G709-V1] ITU-T, "Interface for the Optical Transport Network (OTN)," [G709-V1] ITU-T, "Interface for the Optical Transport Network (OTN),"
G.709 Recommendation (and Amendment 1), February 2001 G.709 Recommendation (and Amendment 1), February 2001
(November 2001). (November 2001).
[G709-V2] ITU-T, "Interface for the Optical Transport Network (OTN)," [G709-V2] ITU-T, "Interface for the Optical Transport Network (OTN),"
G.709 Recommendation, March 2003. G.709 Recommendation, March 2003.
[G798-V2] ITU-T, "Characteristics of optical transport network [G798-V2] ITU-T, "Characteristics of optical transport network
hierarchy equipment functional blocks", G.798, December hierarchy equipment functional blocks", G.798, December
skipping to change at page 19, line 35 skipping to change at page 21, line 12
[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.
[IEEE] "IEEE Standard for Binary Floating-Point Arithmetic", [IEEE] "IEEE Standard for Binary Floating-Point Arithmetic",
ANSI/IEEE Standard 754-1985, Institute of Electrical and ANSI/IEEE Standard 754-1985, Institute of Electrical and
Electronics Engineers, August 1985. Electronics Engineers, August 1985.
[GMPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS [GMPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, October 2009. Networks", Work in Progress, October 2009.
10. Contributors 11. Contributors
Jonathan Sadler, Tellabs Jonathan Sadler, Tellabs
Email: jonathan.sadler@tellabs.com Email: jonathan.sadler@tellabs.com
Kam LAM, Alcatel-Lucent Kam LAM, Alcatel-Lucent
Email: kam.lam@alcatel-lucent.com Email: kam.lam@alcatel-lucent.com
Xiaobing Zi, Huawei Technologies Xiaobing Zi, Huawei Technologies
Email: zixiaobing@huawei.com Email: zixiaobing@huawei.com
Francesco Fondelli, Ericsson Francesco Fondelli, Ericsson
Email: francesco.fondelli@ericsson.com Email: francesco.fondelli@ericsson.com
Lyndon Ong, Ciena Lyndon Ong, Ciena
Email: lyong@ciena.com Email: lyong@ciena.com
Biao Lu, infinera Biao Lu, infinera
Email: blu@infinera.com Email: blu@infinera.com
11. Authors' Addresses 12. Authors' Addresses
Fatai Zhang (editor) Fatai Zhang (editor)
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Phone: +86-755-28972912 Phone: +86-755-28972912
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Guoying Zhang Guoying Zhang
China Academy of Telecommunication Research of MII China Academy of Telecommunication Research of MII
11 Yue Tan Nan Jie Beijing, P.R.China 11 Yue Tan Nan Jie Beijing, P.R.China
Phone: +86-10-68094272 Phone: +86-10-68094272
Email: zhangguoying@mail.ritt.com.cn Email: zhangguoying@mail.ritt.com.cn
Sergio Belotti Sergio Belotti
Alcatel-Lucent Alcatel-Lucent
Optics CTO Optics CTO
Via Trento 30 20059 Vimercate (Milano) Italy Via Trento 30 20059 Vimercate (Milano) Italy
skipping to change at page 22, line 19 skipping to change at page 24, line 5
Email: rrao@infinera.com Email: rrao@infinera.com
John E Drake John E Drake
Juniper Juniper
Email: jdrake@juniper.net Email: jdrake@juniper.net
Igor Bryskin Igor Bryskin
Adva Optical Adva Optical
EMail: IBryskin@advaoptical.com EMail: IBryskin@advaoptical.com
12. Acknowledgment 13. Acknowledgment
The authors would like to thank Lou Berger and Deborah Brungard for The authors would like to thank Lou Berger and Deborah Brungard for
their useful comments to the document. their useful comments to the document.
Intellectual Property Intellectual Property
The IETF Trust takes no position regarding the validity or scope of The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license described in any IETF Document or the extent to which any license
 End of changes. 60 change blocks. 
94 lines changed or deleted 171 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/