draft-ietf-ccamp-gmpls-g709-framework-10.txt   draft-ietf-ccamp-gmpls-g709-framework-11.txt 
Network Working Group Fatai Zhang, Ed. Network Working Group Fatai Zhang, Ed.
Internet Draft Dan Li Internet Draft Dan Li
Category: Informational Huawei Category: Informational Huawei
Han Li Han Li
CMCC CMCC
S.Belotti S.Belotti
Alcatel-Lucent Alcatel-Lucent
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
Expires: May 13, 2013 November 13, 2012 Expires: May 19, 2013 November 19, 2012
Framework for GMPLS and PCE Control of Framework for GMPLS and PCE Control of
G.709 Optical Transport Networks G.709 Optical Transport Networks
draft-ietf-ccamp-gmpls-g709-framework-10.txt draft-ietf-ccamp-gmpls-g709-framework-11.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 39 skipping to change at page 1, line 39
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 May 13, 2013. This Internet-Draft will expire on May 19, 2013.
Abstract Abstract
This document provides a framework to allow the development of This document provides a framework to allow the development of
protocol extensions to support Generalized Multi-Protocol Label protocol extensions to support Generalized Multi-Protocol Label
Switching (GMPLS) and Path Computation Element (PCE) control of Switching (GMPLS) and Path Computation Element (PCE) control of
Optical Transport Networks (OTN) as specified in ITU-T Recommendation Optical Transport Networks (OTN) as specified in ITU-T Recommendation
G.709 as published in 2009. G.709 as published in 2012.
Table of Contents Table of Contents
1. Introduction .................................................. 2 1. Introduction .................................................. 2
2. Terminology ................................................... 3 2. Terminology ................................................... 3
3. G.709 Optical Transport Network ............................... 4 3. G.709 Optical Transport Network ............................... 4
3.1. OTN Layer Network ........................................ 4 3.1. OTN Layer Network ........................................ 4
3.1.1. Client signal mapping ............................... 5 3.1.1. Client signal mapping ............................... 5
3.1.2. Multiplexing ODUj onto Links ........................ 6 3.1.2. Multiplexing ODUj onto Links ........................ 6
3.1.2.1. Structure of MSI information ................... 8 3.1.2.1. Structure of MSI information ................... 8
skipping to change at page 3, line 14 skipping to change at page 3, line 14
optical networks, and spatial switching (e.g., incoming port or fiber optical networks, and spatial switching (e.g., incoming port or fiber
to outgoing port or fiber). The GMPLS architecture is provided in to outgoing port or fiber). The GMPLS architecture is provided in
[RFC3945], signaling function and Resource ReserVation Protocol- [RFC3945], signaling function and Resource ReserVation Protocol-
Traffic Engineering (RSVP-TE) extensions are described in [RFC3471] Traffic Engineering (RSVP-TE) extensions are described in [RFC3471]
and [RFC3473], routing and Open Shortest Path First (OSPF) extensions and [RFC3473], routing and Open Shortest Path First (OSPF) extensions
are described in [RFC4202] and [RFC4203], and the Link Management are described in [RFC4202] and [RFC4203], and the Link Management
Protocol (LMP) is described in [RFC4204]. Protocol (LMP) is described in [RFC4204].
The GMPLS protocol suite including provision [RFC4328] provides the The GMPLS protocol suite including provision [RFC4328] provides the
mechanisms for basic GMPLS control of OTN networks based on the 2001 mechanisms for basic GMPLS control of OTN networks based on the 2001
revision of the G.709 specification [G709-V1]. Later revisions of the revision of the G.709 specification. Later revisions of the G.709
G.709 specification, including [G709-V3], have included some new specification, i.e., [G709-2012], has included some new features; for
features; for example, various multiplexing structures, two types of example, various multiplexing structures, two types of Tributary
Tributary Slots (TSs) (i.e., 1.25Gbps and 2.5Gbps), and extension of Slots (TSs) (i.e., 1.25Gbps and 2.5Gbps), and extension of the
the Optical channel Data Unit-j (ODUj) definition to include the Optical channel Data Unit-j (ODUj) definition to include the ODUflex
ODUflex function. function.
This document reviews relevant aspects of OTN technology evolution This document reviews relevant aspects of OTN technology evolution
that affect the GMPLS control plane protocols and examines why and that affect the GMPLS control plane protocols and examines why and
how to update the mechanisms described in [RFC4328]. This document how to update the mechanisms described in [RFC4328]. This document
additionally provides a framework for the GMPLS control of OTN additionally provides a framework for the GMPLS control of OTN
networks and includes a discussion of the implication for the use of networks and includes a discussion of the implication for the use of
the PCE [RFC4655]. the PCE [RFC4655].
For the purposes of the control plane the OTN can be considered as For the purposes of the control plane the OTN can be considered as
being comprised of ODU and wavelength (Optical Channel (OCh)) layers. being comprised of ODU and wavelength (Optical Channel (OCh)) layers.
skipping to change at page 4, line 24 skipping to change at page 4, line 24
bit rate tolerance up to +/-100 ppm. bit rate tolerance up to +/-100 ppm.
3. G.709 Optical Transport Network 3. G.709 Optical Transport Network
This section provides an informative overview of those aspects of the This section provides an informative overview of those aspects of the
OTN impacting control plane protocols. This overview is based on the OTN impacting control plane protocols. This overview is based on the
ITU-T Recommendations that contain the normative definition of the ITU-T Recommendations that contain the normative definition of the
OTN. Technical details regarding OTN architecture and interfaces are OTN. Technical details regarding OTN architecture and interfaces are
provided in the relevant ITU-T Recommendations. provided in the relevant ITU-T Recommendations.
Specifically, [G872-2001] and [G872-Am2] describe the functional Specifically, [G872-2012] describes the functional architecture of
architecture of optical transport networks providing optical signal optical transport networks providing optical signal transmission,
transmission, multiplexing, routing, supervision, performance multiplexing, routing, supervision, performance assessment, and
assessment, and network survivability. [G709-V1] defines the network survivability. The legacy OTN referenced by [RFC4328] defines
interfaces of the optical transport network to be used within and the interfaces of the optical transport network to be used within and
between subnetworks of the optical network. With the evolution and between subnetworks of the optical network. With the evolution and
deployment of OTN technology many new features have been specified in deployment of OTN technology many new features have been specified in
ITU-T recommendations, including for example, new ODU0, ODU2e, ODU4 ITU-T recommendations, including for example, new ODU0, ODU2e, ODU4
and ODUflex containers as described in [G709-V3]. and ODUflex containers as described in [G709-2012].
3.1. OTN Layer Network 3.1. OTN Layer Network
The simplified signal hierarchy of OTN is shown in Figure 1, which The simplified signal hierarchy of OTN is shown in Figure 1, which
illustrates the layers that are of interest to the control plane. illustrates the layers that are of interest to the control plane.
Other layers below OCh (e.g. Optical Transmission Section (OTS)) are Other layers below OCh (e.g. Optical Transmission Section (OTS)) are
not included in this Figure. The full signal hierarchy is provided in not included in this Figure. The full signal hierarchy is provided in
[G709-V3]. [G709-2012].
Client signal Client signal
| |
ODUj ODUj
| |
OTU/OCh OTU/OCh
OMS OMS
Figure 1 - Basic OTN signal hierarchy Figure 1 - Basic OTN signal hierarchy
Client signals are mapped into ODUj containers. These ODUj containers Client signals are mapped into ODUj containers. These ODUj containers
are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are
combined in the OMS using Wavelength Division Multiplexing (WDM), and combined in the OMS using Wavelength Division Multiplexing (WDM), and
this aggregated signal provides the link between the nodes. this aggregated signal provides the link between the nodes.
3.1.1. Client signal mapping 3.1.1. Client signal mapping
The client signals are mapped into a LO ODUj. The current values of j The client signals are mapped into a LO ODUj. The current values of j
defined in [G709-V3] are: 0, 1, 2, 2e, 3, 4, Flex. The approximate defined in [G709-2012] are: 0, 1, 2, 2e, 3, 4, Flex. The approximate
bit rates of these signals are defined in [G709-V3A2] and are bit rates of these signals are defined in [G709-2012] and are
reproduced in Tables 1 and 2. reproduced in Tables 1 and 2.
Table 1 - ODU types and bit rates
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| ODU Type | ODU nominal bit rate | | ODU Type | ODU nominal bit rate |
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| ODU0 | 1,244,160 kbits/s | | ODU0 | 1,244,160 kbits/s |
| ODU1 | 239/238 x 2,488,320 kbit/s | | ODU1 | 239/238 x 2,488,320 kbit/s |
| ODU2 | 239/237 x 9,953,280 kbit/s | | ODU2 | 239/237 x 9,953,280 kbit/s |
| ODU3 | 239/236 x 39,813,120 kbit/s | | ODU3 | 239/236 x 39,813,120 kbit/s |
| ODU4 | 239/227 x 99,532,800 kbit/s | | ODU4 | 239/227 x 99,532,800 kbit/s |
| ODU2e | 239/237 x 10,312,500 kbit/s | | ODU2e | 239/237 x 10,312,500 kbit/s |
| | | | | |
| ODUflex for | | | ODUflex for | |
|Constant Bit Rate (CBR)| 239/238 x client signal bit rate | |Constant Bit Rate (CBR)| 239/238 x client signal bit rate |
| Client signals | | | Client signals | |
| | | | | |
| ODUflex for Generic | | | ODUflex for Generic | |
| Framing Procedure | Configured bit rate | | Framing Procedure | Configured bit rate |
| - Framed (GFP-F) | | | - Framed (GFP-F) | |
| Mapped client signal | | | Mapped client signal | |
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
Table 1 - ODU types and bit rates
NOTE - The nominal ODUk rates are approximately: 2,498,775.126 kbit/s NOTE - The nominal ODUk rates are approximately: 2,498,775.126 kbit/s
(ODU1), 10,037,273.924 kbit/s (ODU2), 40,319,218.983 kbit/s (ODU3), (ODU1), 10,037,273.924 kbit/s (ODU2), 40,319,218.983 kbit/s (ODU3),
104,794,445.815 kbit/s (ODU4) and 10,399,525.316 kbit/s (ODU2e). 104,794,445.815 kbit/s (ODU4) and 10,399,525.316 kbit/s (ODU2e).
Table 2 - ODU types and tolerance
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| ODU Type | ODU bit-rate tolerance | | ODU Type | ODU bit-rate tolerance |
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| ODU0 | +- 20 ppm | | ODU0 | +- 20 ppm |
| ODU1 | +- 20 ppm | | ODU1 | +- 20 ppm |
| ODU2 | +- 20 ppm | | ODU2 | +- 20 ppm |
| ODU3 | +- 20 ppm | | ODU3 | +- 20 ppm |
| ODU4 | +- 20 ppm | | ODU4 | +- 20 ppm |
| ODU2e | +- 100 ppm | | ODU2e | +- 100 ppm |
| | | | | |
| ODUflex for CBR | | | ODUflex for CBR | |
| Client signals | +- 100 ppm | | Client signals | +- 100 ppm |
| | | | | |
| ODUflex for GFP-F | | | ODUflex for GFP-F | |
| Mapped client signal | +- 100 ppm | | Mapped client signal | +- 100 ppm |
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
Table 2 - ODU types and tolerance
One of two options is for mapping client signals into ODUflex One of two options is for mapping client signals into ODUflex
depending on the client signal type: depending on the client signal type:
- Circuit clients are proportionally wrapped. Thus the bit rate and - Circuit clients are proportionally wrapped. Thus the bit rate and
tolerance are defined by the client signal. tolerance are defined by the client signal.
- Packet clients are mapped using the Generic Framing Procedure - Packet clients are mapped using the Generic Framing Procedure
(GFP). [G709-V3A2] recommends that the ODUflex(GFP) will fill an (GFP). [G709-2012] recommends that the ODUflex(GFP) will fill an
integral number of tributary slots of the smallest HO ODUk path integral number of tributary slots of the smallest HO ODUk path
over which the ODUflex(GFP) may be carried, and the tolerance over which the ODUflex(GFP) may be carried, and the tolerance
should be +/-100ppm. should be +/-100ppm.
3.1.2. Multiplexing ODUj onto Links 3.1.2. Multiplexing ODUj onto Links
The links between the switching nodes are provided by one or more The links between the switching nodes are provided by one or more
wavelengths. Each wavelength carries one OCh, which carries one OTU, wavelengths. Each wavelength carries one OCh, which carries one OTU,
which carries one ODU. Since all of these signals have a 1:1:1 which carries one ODU. Since all of these signals have a 1:1:1
relationship, we only refer to the OTU for clarity. The ODUjs are relationship, we only refer to the OTU for clarity. The ODUjs are
mapped into the TS of the OPUk. Note that in the case where j=k the mapped into the TS of the OPUk. Note that in the case where j=k the
ODUj is mapped into the OTU/OCh without multiplexing. ODUj is mapped into the OTU/OCh without multiplexing.
The initial versions of G.709 [G709-V1] only provided a single TS The initial versions of G.709 referenced by [RFC4328] only provided a
granularity, nominally 2.5Gb/s. [G709-V3] added an additional TS single TS granularity and nominally 2.5Gb/s. [G709-2012] added an
granularity, nominally 1.25Gb/s. The number and type of TSs provided additional TS granularity, nominally 1.25Gb/s. The number and type of
by each of the currently identified OTUk is provided below: TSs provided by each of the currently identified OTUk is provided
below:
Tributary Slot Granularity Tributary Slot Granularity
2.5Gb/s 1.25Gb/s Nominal Bit rate 2.5Gb/s 1.25Gb/s Nominal Bit rate
OTU1 1 2 2.5Gb/s OTU1 1 2 2.5Gb/s
OTU2 4 8 10Gb/s OTU2 4 8 10Gb/s
OTU3 16 32 40Gb/s OTU3 16 32 40Gb/s
OTU4 -- 80 100Gb/s OTU4 -- 80 100Gb/s
To maintain backwards compatibility while providing the ability to To maintain backwards compatibility while providing the ability to
interconnect nodes that support 1.25Gb/s TS at one end of a link and interconnect nodes that support 1.25Gb/s TS at one end of a link and
2.5Gb/s TS at the other, the 'new' equipment will fall back to the 2.5Gb/s TS at the other, the 'new' equipment will fall back to the
use of a 2.5Gb/s TS if connected to legacy equipment. This use of a 2.5Gb/s TS if connected to legacy equipment. This
information is carried in band by the payload type. information is carried in band by the payload type.
The actual bit rate of the TS in an OTUk depends on the value of k. The actual bit rate of the TS in an OTUk depends on the value of k.
Thus the number of TS occupied by an ODUj may vary depending on the Thus the number of TS occupied by an ODUj may vary depending on the
values of j and k. For example an ODU2e uses 9 TS in an OTU3 but only values of j and k. For example an ODU2e uses 9 TS in an OTU3 but only
8 in an OTU4. Examples of the number of TS used for various cases are 8 in an OTU4. Examples of the number of TS used for various cases are
provided below (Referring to Table 7-9 of [G709-V3A2]): provided below (Referring to Table 7-9 of [G709-2012]):
- ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS - ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS
granularity granularity
o ODU0 occupies 1 of the 2, 8, 32 or 80 TS for ODU1, ODU2, ODU3 o ODU0 occupies 1 of the 2, 8, 32 or 80 TS for ODU1, ODU2, ODU3
or ODU4 or ODU4
- ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS - ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS
granularity granularity
o ODU1 occupies 2 of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4 o ODU1 occupies 2 of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4
skipping to change at page 9, line 24 skipping to change at page 9, line 28
4. Connection management in OTN 4. Connection management in OTN
OTN-based connection management is concerned with controlling the OTN-based connection management is concerned with controlling the
connectivity of ODU paths and OCh. This document focuses on the connectivity of ODU paths and OCh. This document focuses on the
connection management of ODU paths. The management of OCh paths is connection management of ODU paths. The management of OCh paths is
described in [RFC6163]. described in [RFC6163].
While [G872-2001] considered the ODU as a set of layers in the same While [G872-2001] considered the ODU as a set of layers in the same
way as SDH has been modeled, recent ITU-T OTN architecture progress way as SDH has been modeled, recent ITU-T OTN architecture progress
[G872-Am2] includes an agreement to model the ODU as a single layer [G872-2012] includes an agreement to model the ODU as a single layer
network with the bit rate as a parameter of links and connections. network with the bit rate as a parameter of links and connections.
This allows the links and nodes to be viewed in a single topology as This allows the links and nodes to be viewed in a single topology as
a common set of resources that are available to provide ODUj a common set of resources that are available to provide ODUj
connections independent of the value of j. Note that when the bit connections independent of the value of j. Note that when the bit
rate of ODUj is less than the server bit rate, ODUj connections are rate of ODUj is less than the server bit rate, ODUj connections are
supported by HO ODU (which has a one-to-one relationship with the supported by HO ODU (which has a one-to-one relationship with the
OTU). OTU).
From an ITU-T perspective, the ODU connection topology is represented From an ITU-T perspective, the ODU connection topology is represented
by that of the OTU link layer, which has the same topology as that of by that of the OTU link layer, which has the same topology as that of
the OCh layer (independent of whether the OTU supports HO ODU, where the OCh layer (independent of whether the OTU supports HO ODU, where
multiplexing is utilized, or LO ODU in the case of direct mapping). multiplexing is utilized, or LO ODU in the case of direct mapping).
Thus, the OTU and OCh layers should be visible in a single Thus, the OTU and OCh layers should be visible in a single
topological representation of the network, and from a logical topological representation of the network, and from a logical
perspective, the OTU and OCh may be considered as the same logical, perspective, the OTU and OCh may be considered as the same logical,
switchable entity. switchable entity.
Note that the OTU link layer topology may be provided via various Note that the OTU link layer topology may be provided via various
infrastructure alternatives, including point-to-point optical infrastructure alternatives, including point-to-point optical
connections, flexible optical connections fully in the optical domain, connections, flexible optical connections fully in the optical
flexible optical connections involving hybrid sub-lambda/lambda nodes domain, flexible optical connections involving hybrid sub-lambda /
involving 3R, etc. lambda nodes involving 3R, etc.
4.1. Connection management of the ODU 4.1. Connection management of the ODU
LO ODUj can be either mapped into the OTUk signal (j = k), or LO ODUj can be either mapped into the OTUk signal (j = k), or
multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is
mapped into an OCh. mapped into an OCh.
From the perspective of control plane, there are two kinds of network From the perspective of control plane, there are two kinds of network
topology to be considered. topology to be considered.
skipping to change at page 12, line 43 skipping to change at page 12, line 43
management of multiple layers in OTN can follow the procedures management of multiple layers in OTN can follow the procedures
defined in [RFC4206], [RFC6107] and related MLN drafts. defined in [RFC4206], [RFC6107] and related MLN drafts.
As discussed in section 4, the route path computation for OCh is in As discussed in section 4, the route path computation for OCh is in
the scope of Wavelength Switched Optical Network (WSON) [RFC6163]. the scope of Wavelength Switched Optical Network (WSON) [RFC6163].
Therefore, this document only considers ODU layer for ODU connection Therefore, this document only considers ODU layer for ODU connection
request. request.
LSP hierarchy can also be applied within the ODU layers. One of the LSP hierarchy can also be applied within the ODU layers. One of the
typical scenarios for ODU layer hierarchy is to maintain typical scenarios for ODU layer hierarchy is to maintain
compatibility with introducing new [G709-V3] services (e.g., ODU0, compatibility with introducing new [G709-2012] services (e.g., ODU0,
ODUflex) into a legacy network configuration (containing [G709-V1] or ODUflex) into a legacy network configuration (i.e., the legacy OTN
[G709-V2] OTN equipment). In this scenario, it may be needed to referenced by [RFC4328]). In this scenario, it may be needed to
consider introducing hierarchical multiplexing capability in specific consider introducing hierarchical multiplexing capability in specific
network transition scenarios. One method for enabling multiplexing network transition scenarios. One method for enabling multiplexing
hierarchy is by introducing dedicated boards in a few specific places hierarchy is by introducing dedicated boards in a few specific places
in the network and tunneling these new services through [G709-V1] or in the network and tunneling these new services through the legacy
containers (ODU1, ODU2, ODU3), thus postponing the need to upgrade
[G709-V2] containers (ODU1, ODU2, ODU3), thus postponing the need to every network element to [G709-2012] capabilities.
upgrade every network element to [G709-V3] capabilities.
In such case, one ODUj connection can be nested into another ODUk In such case, one ODUj connection can be nested into another ODUk
(j<k) connection, which forms the LSP hierarchy in ODU layer. The (j<k) connection, which forms the LSP hierarchy in ODU layer. The
creation of the outer ODUk connection can be triggered via network creation of the outer ODUk connection can be triggered via network
planning, or by the signaling of the inner ODUj connection. For the planning, or by the signaling of the inner ODUj connection. For the
former case, the outer ODUk connection can be created in advance former case, the outer ODUk connection can be created in advance
based on network planning. For the latter case, the multi-layer based on network planning. For the latter case, the multi-layer
network signaling described in [RFC4206], [RFC6107] and [RFC6001] network signaling described in [RFC4206], [RFC6107] and [RFC6001]
(including related modifications, if needed) are relevant to create (including related modifications, if needed) are relevant to create
the ODU connections with multiplexing hierarchy. In both cases, the the ODU connections with multiplexing hierarchy. In both cases, the
outer ODUk connection is advertised as a Forwarding Adjacency (FA). outer ODUk connection is advertised as a Forwarding Adjacency (FA).
5.2. Implications for GMPLS Signaling 5.2. Implications for GMPLS Signaling
The signaling function and RSVP-TE extensions are described in The signaling function and RSVP-TE extensions are described in
[RFC3471] and [RFC 3473]. For OTN-specific control, [RFC4328] defines [RFC3471] and [RFC3473]. For OTN-specific control, [RFC4328] defines
signaling extensions to support G.709 Optical Transport Networks signaling extensions to support control for the legacy G.709 Optical
Control as defined in [G709-V1]. Transport Networks.
As described in Section 3, [G709-V3] introduced some new features As described in Section 3, [G709-2012] introduced some new features
that include the ODU0, ODU2e, ODU4 and ODUflex containers. The that include the ODU0, ODU2e, ODU4 and ODUflex containers. The
mechanisms defined in [RFC4328] do not support such new OTN features, mechanisms defined in [RFC4328] do not support such new OTN features,
and protocol extensions will be necessary to allow them to be and protocol extensions will be necessary to allow them to be
controlled by a GMPLS control plane. controlled by a GMPLS control plane.
[RFC4328] defines the LSP Encoding Type, the Switching Type and the [RFC4328] defines the LSP Encoding Type, the Switching Type and the
Generalized Protocol Identifier (Generalized-PID) constituting the Generalized Protocol Identifier (Generalized-PID) constituting the
common part of the Generalized Label Request. The G.709 Traffic common part of the Generalized Label Request. The G.709 Traffic
Parameters are also defined in [RFC4328]. The following signaling Parameters are also defined in [RFC4328]. The following signaling
aspects should be considered additionally since [RFC4328] was aspects should be considered additionally since [RFC4328] was
skipping to change at page 14, line 43 skipping to change at page 14, line 43
more information in Section 3.1.2.1). A new extension object has more information in Section 3.1.2.1). A new extension object has
to be defined to carry TPN information if control plane is used to to be defined to carry TPN information if control plane is used to
configure MSI information. configure MSI information.
- Support for ODU Virtual Concatenation (VCAT) and Link Capacity - Support for ODU Virtual Concatenation (VCAT) and Link Capacity
Adjustment Scheme (LCAS) Adjustment Scheme (LCAS)
GMPLS signaling should support the creation of Virtual GMPLS signaling should support the creation of Virtual
Concatenation of ODUk signal with k=1, 2, 3. The signaling should Concatenation of ODUk signal with k=1, 2, 3. The signaling should
also support the control of dynamic capacity changing of a VCAT also support the control of dynamic capacity changing of a VCAT
container using LCAS ([G.7042]). [RFC6344] has a clear description container using LCAS ([G7042]). [RFC6344] has a clear description
of VCAT and LCAS control in SONET/SDH and OTN networks. of VCAT and LCAS control in SONET/SDH and OTN networks.
- Support for Control of Hitless Adjustment of ODUflex (GFP) - Support for Control of Hitless Adjustment of ODUflex (GFP)
[G.7044] has been created in ITU-T to specify Hitless Adjustment [G7044] has been created in ITU-T to specify Hitless Adjustment of
of ODUflex (GFP) (HAO) that is used to increase or decrease the ODUflex (GFP) (HAO) that is used to increase or decrease the
bandwidth of an ODUflex (GFP) that is transported in an OTN bandwidth of an ODUflex (GFP) that is transported in an OTN
network. network.
The procedure of ODUflex (GFP) adjustment requires the The procedure of ODUflex (GFP) adjustment requires the
participation of every node along the path. Therefore, it is participation of every node along the path. Therefore, it is
recommended to use the control plane signaling to initiate the recommended to use the control plane signaling to initiate the
adjustment procedure in order to avoid the manual configuration at adjustment procedure in order to avoid the manual configuration at
each node along the path. each node along the path.
From the perspective of control plane, the control of ODUflex From the perspective of control plane, the control of ODUflex
skipping to change at page 15, line 30 skipping to change at page 15, line 30
5.3. Implications for GMPLS Routing 5.3. Implications for GMPLS Routing
The path computation process needs to select a suitable route for an The path computation process needs to select a suitable route for an
ODUj connection request. In order to perform the path computation, it ODUj connection request. In order to perform the path computation, it
needs to evaluate the available bandwidth on each candidate link. needs to evaluate the available bandwidth on each candidate link.
The routing protocol should be extended to convey sufficient The routing protocol should be extended to convey sufficient
information to represent ODU Traffic Engineering (TE) topology. information to represent ODU Traffic Engineering (TE) topology.
Interface Switching Capability Descriptors defined in [RFC4202] Interface Switching Capability Descriptors defined in [RFC4202]
present a new constraint for LSP path computation. [RFC4203] present a new constraint for LSP path computation. [RFC4203] defines
defines the switching capability and related Maximum LSP Bandwidth the switching capability and related Maximum LSP Bandwidth and the
and the Switching Capability specific information. When the Switching Switching Capability specific information. When the Switching
Capability field is TDM the Switching Capability Specific Information Capability field is TDM the Switching Capability Specific Information
field includes Minimum LSP Bandwidth, an indication whether the field includes Minimum LSP Bandwidth, an indication whether the
interface supports Standard or Arbitrary SONET/SDH, and padding. interface supports Standard or Arbitrary SONET/SDH, and padding.
Hence a new Switching Capability value needs to be defined for [G709- Hence a new Switching Capability value needs to be defined for [G709-
V3] ODU switching in order to allow the definition of a new Switching 2012] ODU switching in order to allow the definition of a new
Capability Specific Information field definition. The following Switching Capability Specific Information field definition. The
requirements should be considered: following requirements should be considered:
- Support for carrying the link multiplexing capability - Support for carrying the link multiplexing capability
As discussed in section 3.1.2, many different types of ODUj can As discussed in section 3.1.2, many different types of ODUj can
be multiplexed into the same OTUk. For example, both ODU0 and be multiplexed into the same OTUk. For example, both ODU0 and
ODU1 may be multiplexed into ODU2. An OTU link may support one or ODU1 may be multiplexed into ODU2. An OTU link may support one or
more types of ODUj signals. The routing protocol should be more types of ODUj signals. The routing protocol should be
capable of carrying this multiplexing capability. capable of carrying this multiplexing capability.
- Support any ODU and ODUflex - Support any ODU and ODUflex
skipping to change at page 16, line 39 skipping to change at page 16, line 39
(demuxed) or both of them. The capability advertised by an (demuxed) or both of them. The capability advertised by an
interface needs further distinction in order to separate interface needs further distinction in order to separate
termination and switching capabilities. termination and switching capabilities.
Therefore, to allow the required flexibility, the routing Therefore, to allow the required flexibility, the routing
protocol should clearly distinguish the terminating and switching protocol should clearly distinguish the terminating and switching
capability. capability.
- Support for Tributary Slot Granularity advertisement - Support for Tributary Slot Granularity advertisement
[G709-V3] defines two types of TS but each link can only support [G709-2012] defines two types of TS but each link can only
a single type at a given time. In order to perform a correct path support a single type at a given time. In order to perform a
computation (i.e. the LSP end points have matching Tributary Slot correct path computation (i.e. the LSP end points have matching
Granularity values) the Tributary Slot Granularity needs to be Tributary Slot Granularity values) the Tributary Slot Granularity
advertised. needs to be advertised.
- Support different priorities for resource reservation - Support different priorities for resource reservation
How many priorities levels should be supported depends on the How many priorities levels should be supported depends on the
operator's policy. Therefore, the routing protocol should be operator's policy. Therefore, the routing protocol should be
capable of supporting either no priorities or up to 8 priority capable of supporting either no priorities or up to 8 priority
levels as defined in [RFC4202]. levels as defined in [RFC4202].
- Support link bundling - Support link bundling
skipping to change at page 18, line 19 skipping to change at page 18, line 19
node with 1.25Gb/s granularity should fall back to 2.5Gb/s node with 1.25Gb/s granularity should fall back to 2.5Gb/s
granularity. granularity.
Therefore, it is necessary for the two ends of a link to Therefore, it is necessary for the two ends of a link to
correlate the granularity of the TS. This ensures the correct use correlate the granularity of the TS. This ensures the correct use
and of the TE link. and of the TE link.
- Correlating the supported LO ODU signal types and multiplexing - Correlating the supported LO ODU signal types and multiplexing
hierarchy capability hierarchy capability
Many new ODU signal types have been introduced in [G709-V3], such Many new ODU signal types have been introduced in [G709-2012],
as ODU0, ODU4, ODU2e and ODUflex. It is possible that equipment such as ODU0, ODU4, ODU2e and ODUflex. It is possible that
does not support all the LO ODU signal types introduced by those equipment does not support all the LO ODU signal types introduced
new standards or drafts. Furthermore, since multiplexing by those new standards or drafts. Furthermore, since multiplexing
hierarchy is not allowed before [G709-V3], it is possible that hierarchy was not allowed by the legacy OTN referenced by
only one end of an ODU link can support multiplexing hierarchy [RFC4328], it is possible that only one end of an ODU link can
capability, or the two ends of the link support different support multiplexing hierarchy capability, or the two ends of the
multiplexing hierarchy capabilities (e.g., one end of the link link support different multiplexing hierarchy capabilities (e.g.,
supports ODU0 into ODU1 into ODU3 multiplexing while the other one end of the link supports ODU0 into ODU1 into ODU3
end supports ODU0 into ODU2 into ODU3 multiplexing). multiplexing while the other end supports ODU0 into ODU2 into
ODU3 multiplexing).
For the control and management consideration, it is necessary for For the control and management consideration, it is necessary for
the two ends of an HO ODU link to correlate which types of LO ODU the two ends of an HO ODU link to correlate which types of LO ODU
can be supported and what multiplexing hierarchy capabilities can can be supported and what multiplexing hierarchy capabilities can
be provided by the other end. be provided by the other end.
5.5. Implications for Control Plane Backward Compatibility 5.5. Implications for Control Plane Backward Compatibility
With the introduction of [G709-V3], there may be OTN networks With the introduction of [G709-2012], there may be OTN networks
composed of a mixture of nodes, some of which support [G709-V1] and composed of a mixture of nodes, some of which support the legacy OTN
run control plane protocols defined in [RFC4328], while others and run control plane protocols defined in [RFC4328], while others
support [G709-V3] and new OTN control plane characterized in this support [G709-2012] and new OTN control plane characterized in this
document. Note that a third case, for the sake of completeness, document. Note that a third case, for the sake of completeness,
consists on nodes supporting [G709-V1] with a new OTN control plane, consists on nodes supporting the legacy OTN referenced by [RFC4328]
but such nodes can be considered as new nodes with limited with a new OTN control plane, but such nodes can be considered as new
capabilities. nodes with limited capabilities.
This section discusses the compatibility of nodes implementing the This section discusses the compatibility of nodes implementing the
control plane procedures defined [RFC4328], in support of [G709-V1], control plane procedures defined [RFC4328], in support of the legacy
and the control plane procedures defined to support [G709-V3], as OTN, and the control plane procedures defined to support [G709-2012],
outlined by this document. as outlined by this document.
Compatibility needs to be considered only when controlling ODU1 or Compatibility needs to be considered only when controlling ODU1 or
ODU2 or ODU3 connection, because [G709-V1] only support these three ODU2 or ODU3 connection, because the legacy OTN only support these
ODU signal types. In such cases, there are several possible options three ODU signal types. In such cases, there are several possible
including: options including:
- A node supporting [G709-V3] could support only the [G709-V3] - A node supporting [G709-2012] could support only the [G709-2012]
related control plane procedures, in which case both types of related control plane procedures, in which case both types of
nodes would be unable to jointly control an LSP for an ODU type nodes would be unable to jointly control an LSP for an ODU type
that both nodes support in the data plane. Note that this case is that both nodes support in the data plane. Note that this case is
supported by the procedures defined in [RFC3473] as a different supported by the procedures defined in [RFC3473] as a different
Switching Capability/Type value is used for the different control Switching Capability/Type value is used for the different control
plane versions. plane versions.
- A node supporting [G709-V3] could support both the [G709-V3] - A node supporting [G709-2012] could support both the [G709-2012]
related control plane and the control plane defined in [RFC4328]. related control plane and the control plane defined in [RFC4328].
o Such a node could identify which set of procedure to follow o Such a node could identify which set of procedure to follow
when initiating an LSP based on the Switching Capability value when initiating an LSP based on the Switching Capability value
advertised in routing. advertised in routing.
o Such a node could follow the set of procedures based on the o Such a node could follow the set of procedures based on the
Switching Type received in signaling messages from an upstream Switching Type received in signaling messages from an upstream
node. node.
skipping to change at page 20, line 48 skipping to change at page 20, line 48
1.25Gbps in its data plane. 1.25Gbps in its data plane.
7. Security Considerations 7. Security Considerations
The use of control plane protocols for signaling, routing, and path The use of control plane protocols for signaling, routing, and path
computation opens an OTN to security threats through attacks on those computation opens an OTN to security threats through attacks on those
protocols. Although, this is not greater than the risks presented by protocols. Although, this is not greater than the risks presented by
the existing OTN control plane as defined by [RFC4203] and [RFC4328]. the existing OTN control plane as defined by [RFC4203] and [RFC4328].
For further details of the specific security measures refer to the For further details of the specific security measures refer to the
documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], documents that define the protocols ([RFC3473], [RFC4203], [RFC5307],
[RFC4204], and [RFC5440]). [RFC5920] provides an overview of security [RFC4204], and [RFC5440]). [RFC5920] provides an overview of security
vulnerabilities and protection mechanisms for the GMPLS control plane. vulnerabilities and protection mechanisms for the GMPLS control
plane.
8. IANA Considerations 8. IANA Considerations
This document makes not requests for IANA action. This document makes not requests for IANA action.
9. Acknowledgments 9. Acknowledgments
We would like to thank Maarten Vissers and Lou Berger for their We would like to thank Maarten Vissers and Lou Berger for their
review and useful comments. review and useful comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
LabelSwitching (GMPLS) Signaling Extensions for G.709 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Optical Transport Networks Control", RFC 4328, Jan 2006. Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
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 [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003. 3473, January 2003.
skipping to change at page 22, line 5 skipping to change at page 22, line 5
Traffic Engineering (TE)", RFC 4201, October 2005. Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4202] K. Kompella, Y. Rekhter, Ed., "Routing Extensions in [RFC4202] K. Kompella, Y. Rekhter, Ed., "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005. (GMPLS)", RFC 4202, October 2005.
[RFC4203] K. Kompella, Y. Rekhter, Ed., "OSPF Extensions in Support [RFC4203] K. Kompella, Y. Rekhter, Ed., "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)", of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005. RFC 4203, October 2005.
[RFC4205] K. Kompella, Y. Rekhter, Ed., "Intermediate System to [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
Intermediate System (IS-IS) Extensions in Support of 4204, October 2005.
Generalized Multi-Protocol Label Switching (GMPLS)", RFC
4205, October 2005.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
October 2005.
[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 [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol
Signaled Hierarchical Label Switched Paths", RFC6107, LabelSwitching (GMPLS) Signaling Extensions for G.709
February 2011. Optical Transport Networks Control", RFC 4328, Jan 2006.
[RFC5307] K. Kompella, Y. Rekhter, Ed., "IS-IS Extensions in
Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, October 2008.
[RFC5440] JP. Vasseur, JL. Le Roux, Ed.," Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, March
2009.
[RFC6001] Dimitri Papadimitriou et al, "Generalized Multi-Protocol [RFC6001] Dimitri Papadimitriou et al, "Generalized Multi-Protocol
Label Switching (GMPLS) Protocol Extensions for Multi- Label Switching (GMPLS) Protocol Extensions for Multi-
Layer and Multi-Region Networks (MLN/MRN)", RFC6001, Layer and Multi-Region Networks (MLN/MRN)", RFC6001,
February 21, 2010. February 21, 2010.
[RFC5440] JP. Vasseur, JL. Le Roux, Ed.," Path Computation Element [RFC6107] K. Shiomoto, A. Farrel, "Procedures for Dynamically
(PCE) Communication Protocol (PCEP)", RFC 5440, March Signaled Hierarchical Label Switched Paths", RFC6107,
2009. February 2011.
[RFC6344] G. Bernstein et al, "Operating Virtual Concatenation [RFC6344] G. Bernstein et al, "Operating Virtual Concatenation
(VCAT) and the Link Capacity Adjustment Scheme (LCAS) (VCAT) and the Link Capacity Adjustment Scheme (LCAS)
with Generalized Multi-Protocol Label Switching (GMPLS)", with Generalized Multi-Protocol Label Switching (GMPLS)",
RFC6344, August, 2011. RFC6344, August, 2011.
[G709-V3] ITU-T, "Interfaces for the Optical Transport Network [G709-2012] ITU-T, "Interface for the Optical Transport Network
(OTN)", G.709 Recommendation, December 2009. (OTN)", G.709/Y.1331 Recommendation, February 2012.
[G709-V3A2] ITU-T, "Interfaces for the Optical Transport Network
(OTN)", G.709 Recommendation Amendment2, April 2011.
10.2. Informative References 10.2. Informative References
[G709-V1] ITU-T, "Interface for the Optical Transport Network
(OTN)," G.709 Recommendation (and Amendment 1), November
2001.
[G709-V2] ITU-T, "Interface for the Optical Transport Network
(OTN)," G.709 Recommendation, March 2003.
[G798-V4] ITU-T, "Characteristics of optical transport network [G798-V4] ITU-T, "Characteristics of optical transport network
hierarchy equipment functional blocks", G.798 hierarchy equipment functional blocks", G.798
Recommendation, October 2010. Recommendation, October 2010.
[G7042] ITU-T, "Link capacity adjustment scheme (LCAS) for [G7042] ITU-T, "Link capacity adjustment scheme (LCAS) for
virtual concatenated signals", G.7042/Y.1305, March 2006. virtual concatenated signals", G.7042/Y.1305, March 2006.
[G872-2001] ITU-T, "Architecture of optical transport networks", [G872-2001] ITU-T, "Architecture of optical transport networks",
G.872 Recommendation, November 2001. G.872 Recommendation, November 2001.
[G872-Am2] ITU-T, "Architecture of optical transport networks", [G872-2012] ITU-T, "Architecture of optical transport networks",
G.872 Recommendation and Amendment 2, July 2010. G.872 Recommendation, October 2012.
[G.7044] ITU-T, "Hitless adjustment of ODUflex", G.7044 (and [G7044] ITU-T, "Hitless adjustment of ODUflex", G.7044/Y.1347,
Amendment 1), February 2012. October 2011.
[HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
and wavelength assignment approaches for wavelength- (GMPLS) Architecture", RFC 3945, October 2004.
routed optical WDM networks", Optical Networks Magazine,
January 2000. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture",
RFC 4655, August 2006.
[RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS
and PCE Control of Wavelength Switched Optical Networks and PCE Control of Wavelength Switched Optical Networks
(WSON)", RFC6163, April 2011. (WSON)", RFC6163, April 2011.
[PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai [PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai
Zhang, "Requirements for GMPLS applications of PCE", Zhang, "Requirements for GMPLS applications of PCE",
draft-ietf-pce-gmpls-aps-req, Work in Progress. draft-ietf-pce-gmpls-aps-req, Work in Progress.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
skipping to change at page 26, line 42 skipping to change at page 26, line 33
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
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
 End of changes. 48 change blocks. 
124 lines changed or deleted 120 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/