Difference between revisions of "RFC7062"
imported>Admin (Created page with " Internet Engineering Task Force (IETF) F. Zhang, Ed.Request for Comments: 7062 D. LiCategory: Informational ...") |
|||
Line 1: | Line 1: | ||
+ | Internet Engineering Task Force (IETF) F. Zhang, Ed. | ||
+ | Request for Comments: 7062 D. Li | ||
+ | Category: Informational Huawei | ||
+ | ISSN: 2070-1721 H. Li | ||
+ | CMCC | ||
+ | S. Belotti | ||
+ | Alcatel-Lucent | ||
+ | D. Ceccarelli | ||
+ | Ericsson | ||
+ | November 2013 | ||
+ | Framework for GMPLS and PCE Control of | ||
+ | G.709 Optical Transport Networks | ||
− | + | '''Abstract''' | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | Abstract | ||
This document provides a framework to allow the development of | This document provides a framework to allow the development of | ||
Line 16: | Line 21: | ||
Recommendation G.709 as published in 2012. | Recommendation G.709 as published in 2012. | ||
− | Status of This Memo | + | '''Status of This Memo''' |
This document is not an Internet Standards Track specification; it is | This document is not an Internet Standards Track specification; it is | ||
Line 32: | Line 37: | ||
http://www.rfc-editor.org/info/rfc7062. | http://www.rfc-editor.org/info/rfc7062. | ||
− | + | '''Copyright Notice''' | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | Copyright Notice | ||
Copyright (c) 2013 IETF Trust and the persons identified as the | Copyright (c) 2013 IETF Trust and the persons identified as the | ||
Line 75: | Line 66: | ||
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 signaling extensions defined in [RFC4328] provide the | + | The GMPLS signaling extensions defined in [[RFC4328]] provide the |
mechanisms for basic GMPLS control of OTN based on the 2001 revision | mechanisms for basic GMPLS control of OTN based on the 2001 revision | ||
of the G.709 specification. The 2012 revision of the G.709 | of the G.709 specification. The 2012 revision of the G.709 | ||
Line 91: | Line 82: | ||
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 GMPLS control of OTN and | additionally provides a framework for GMPLS control of OTN and | ||
includes a discussion of the implications for the use of the PCE | includes a discussion of the implications for the use of the PCE | ||
− | [RFC4655]. | + | [[RFC4655]]. |
For the purposes of the control plane, the OTN can be considered to | For the purposes of the control plane, the OTN can be considered to | ||
Line 100: | Line 91: | ||
This document focuses on the control of the ODU layer, with control | This document focuses on the control of the ODU layer, with control | ||
of the wavelength layer considered out of the scope. Please refer to | of the wavelength layer considered out of the scope. Please refer to | ||
− | [RFC6163] for further information about the wavelength layer. | + | [[RFC6163]] for further information about the wavelength layer. |
== Terminology == | == Terminology == | ||
Line 109: | Line 100: | ||
ODU: Optical Channel Data Unit | ODU: Optical Channel Data Unit | ||
− | |||
− | |||
− | |||
− | |||
OTU: Optical Channel Transport Unit | OTU: Optical Channel Transport Unit | ||
Line 149: | Line 136: | ||
optical transport networks providing optical signal transmission, | optical transport networks providing optical signal transmission, | ||
multiplexing, routing, supervision, performance assessment, and | multiplexing, routing, supervision, performance assessment, and | ||
− | network survivability. The legacy OTN referenced by [RFC4328] | + | network survivability. The legacy OTN referenced by [[RFC4328]] |
defines the interfaces of the optical transport network to be used | defines the interfaces of the optical transport network to be used | ||
within and between subnetworks of the optical network. With the | within and between subnetworks of the optical network. With the | ||
Line 156: | Line 143: | ||
ODU0, ODU2e, ODU4, and ODUflex containers as described in | ODU0, ODU2e, ODU4, and ODUflex containers as described in | ||
[G709-2012]. | [G709-2012]. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
=== OTN Layer Network === | === OTN Layer Network === | ||
Line 189: | Line 166: | ||
Multiplexing (WDM), and this aggregated signal provides the link | Multiplexing (WDM), and this aggregated signal provides the link | ||
between the nodes. | between the nodes. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
==== Client Signal Mapping ==== | ==== Client Signal Mapping ==== | ||
Line 252: | Line 199: | ||
(ODU1), 10,037,273.924 Kbps (ODU2), 40,319,218.983 Kbps (ODU3), | (ODU1), 10,037,273.924 Kbps (ODU2), 40,319,218.983 Kbps (ODU3), | ||
104,794,445.815 Kbps (ODU4), and 10,399,525.316 Kbps (ODU2e). | 104,794,445.815 Kbps (ODU4), and 10,399,525.316 Kbps (ODU2e). | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+-----------------------+-----------------------------------+ | +-----------------------+-----------------------------------+ | ||
Line 318: | Line 245: | ||
multiplexing. | multiplexing. | ||
− | + | The initial versions of G.709 referenced by [[RFC4328]] only provided a | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | The initial versions of G.709 referenced by [RFC4328] only provided a | ||
single TS granularity, nominally 2.5 Gbps. [G709-2012] added an | single TS granularity, nominally 2.5 Gbps. [G709-2012] added an | ||
additional TS granularity, nominally 1.25 Gbps. The number and type | additional TS granularity, nominally 1.25 Gbps. The number and type | ||
Line 371: | Line 290: | ||
- ODU3 into ODU4 multiplexing with 1.25 Gbps TS granularity | - ODU3 into ODU4 multiplexing with 1.25 Gbps TS granularity | ||
o ODU3 occupies 31 of the 80 TSs for ODU4 | o ODU3 occupies 31 of the 80 TSs for ODU4 | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
- ODUflex into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS | - ODUflex into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS | ||
Line 391: | Line 303: | ||
specific OTUk TS is determined locally, and it can also be explicitly | specific OTUk TS is determined locally, and it can also be explicitly | ||
controlled by a specific entity (e.g., head end or Network Management | controlled by a specific entity (e.g., head end or Network Management | ||
− | System (NMS)) through Explicit Label Control [RFC3473]. | + | System (NMS)) through Explicit Label Control [[RFC3473]]. |
− | + | ===== Structure of MSI Information ===== | |
When multiplexing an ODUj into an HO ODUk (k>j), G.709 specifies the | When multiplexing an ODUj into an HO ODUk (k>j), G.709 specifies the | ||
Line 424: | Line 336: | ||
Accepted MSI (AcMSI) information. The AcMSI information is the | Accepted MSI (AcMSI) information. The AcMSI information is the | ||
MSI valued received in-band, after a three-frame integration. | MSI valued received in-band, after a three-frame integration. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
As described in [G798], the sink of the HO ODU trail checks the | As described in [G798], the sink of the HO ODU trail checks the | ||
Line 447: | Line 352: | ||
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 to be a set of layers in the | While [G872-2001] considered the ODU to be a set of layers in the | ||
Line 475: | Line 380: | ||
connections, optical connections fully in the optical domain, and | connections, optical connections fully in the optical domain, and | ||
optical connections involving hybrid sub-lambda/lambda nodes | optical connections involving hybrid sub-lambda/lambda nodes | ||
− | involving 3R, etc. See [RFC6163] for additional information. | + | involving 3R, etc. See [[RFC6163]] for additional information. |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
=== Connection Management of the ODU === | === Connection Management of the ODU === | ||
Line 533: | Line 430: | ||
OCh layer, so it is simply a Multi-Layer Network (MLN) (see | OCh layer, so it is simply a Multi-Layer Network (MLN) (see | ||
− | + | [[RFC6001]]). OCh connections may be created on demand, which is | |
− | |||
− | |||
− | |||
− | |||
− | [RFC6001]). OCh connections may be created on demand, which is | ||
described in Section 5.1. | described in Section 5.1. | ||
Line 578: | Line 470: | ||
+-------+ +---------+ Link #2+---------+ +-------+ | +-------+ +---------+ Link #2+---------+ +-------+ | ||
Node A Node B Node C Node D | Node A Node B Node C Node D | ||
− | |||
Figure 4: OCh Visible Topology for LO ODUj Connection Management | Figure 4: OCh Visible Topology for LO ODUj Connection Management | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
In Figure 4, the cloud in the previous figure is substituted by the | In Figure 4, the cloud in the previous figure is substituted by the | ||
Line 618: | Line 500: | ||
The OTN path computation can be divided into two layers. One layer | The OTN path computation can be divided into two layers. One layer | ||
− | is OCh/OTUk; the other is ODUj. [RFC4206] and [RFC6107] define the | + | is OCh/OTUk; the other is ODUj. [[RFC4206]] and [[RFC6107]] define the |
mechanisms to accomplish creating the hierarchy of LSPs. The LSP | mechanisms to accomplish creating the hierarchy of LSPs. The LSP | ||
management of multiple layers in OTN can follow the procedures | management of multiple layers in OTN can follow the procedures | ||
− | defined in [RFC4206], [RFC6001], and [RFC6107]. | + | defined in [[RFC4206]], [[RFC6001]], and [[RFC6107]]. |
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 the Wavelength Switched Optical Network (WSON) | the scope of the Wavelength Switched Optical Network (WSON) | ||
− | [RFC6163]. Therefore, this document only considers the ODU layer for | + | [[RFC6163]]. Therefore, this document only considers the ODU layer for |
an ODU connection request. | an ODU connection request. | ||
Line 632: | Line 514: | ||
compatibility with introducing new [G709-2012] services (e.g., ODU0 | compatibility with introducing new [G709-2012] services (e.g., ODU0 | ||
and ODUflex) into a legacy network configuration (i.e., the legacy | and ODUflex) into a legacy network configuration (i.e., the legacy | ||
− | OTN referenced by [RFC4328]). In this scenario, it may be necessary | + | OTN referenced by [[RFC4328]]). In this scenario, it may be necessary |
to consider introducing hierarchical multiplexing capability in | to consider introducing hierarchical multiplexing capability in | ||
specific network transition scenarios. One method for enabling | specific network transition scenarios. One method for enabling | ||
Line 639: | Line 521: | ||
through the legacy containers (ODU1, ODU2, ODU3), thus postponing the | through the legacy containers (ODU1, ODU2, ODU3), thus postponing the | ||
need to upgrade every network element to [G709-2012] capabilities. | need to upgrade every network element to [G709-2012] capabilities. | ||
− | |||
− | |||
− | |||
− | |||
In such cases, one ODUj connection can be nested into another ODUk | In such cases, one ODUj connection can be nested into another ODUk | ||
Line 650: | Line 528: | ||
For the former case, the outer ODUk connection can be created in | For the former case, the outer ODUk connection can be created in | ||
advance based on network planning. For the latter case, the multi- | advance based on network planning. For the latter case, the multi- | ||
− | layer network signaling described in [RFC4206], [RFC6107], and | + | layer network signaling described in [[RFC4206]], [[RFC6107]], and |
− | [RFC6001] (including related modifications, if needed) is relevant to | + | [[RFC6001]] (including related modifications, if needed) is relevant to |
create the ODU connections with multiplexing hierarchy. In both | create the ODU connections with multiplexing hierarchy. In both | ||
cases, the outer ODUk connection is advertised as a Forwarding | cases, the outer ODUk connection is advertised as a Forwarding | ||
Line 659: | Line 537: | ||
The signaling function and RSVP-TE extensions are described in | The signaling function and RSVP-TE extensions are described in | ||
− | [RFC3471] and [RFC3473]. For OTN-specific control, [RFC4328] defines | + | [[RFC3471]] and [[RFC3473]]. For OTN-specific control, [[RFC4328]] defines |
signaling extensions to support control for the legacy G.709 Optical | signaling extensions to support control for the legacy G.709 Optical | ||
Transport Networks. | Transport Networks. | ||
Line 665: | Line 543: | ||
As described in Section 3, [G709-2012] 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]. In addition, the following | + | parameters are also defined in [[RFC4328]]. In addition, the following |
− | signaling aspects not included in [RFC4328] should be considered: | + | signaling aspects not included in [[RFC4328]] should be considered: |
- Support for specifying new signal types and related traffic | - Support for specifying new signal types and related traffic | ||
Line 692: | Line 570: | ||
For other ODU signal types, the bit rates and tolerances are fixed | For other ODU signal types, the bit rates and tolerances are fixed | ||
and can be deduced from the signal types. | and can be deduced from the signal types. | ||
− | |||
− | |||
− | |||
− | |||
- Support for LSP setup using different TS granularity | - Support for LSP setup using different TS granularity | ||
Line 727: | Line 601: | ||
Concatenation of an ODUk signal with k=1, 2, 3. The signaling | Concatenation of an ODUk signal with k=1, 2, 3. The signaling | ||
should also support the control of dynamic capacity changing of a | should also support the control of dynamic capacity changing of a | ||
− | VCAT container using LCAS ([G7042]). [RFC6344] has a clear | + | VCAT container using LCAS ([G7042]). [[RFC6344]] has a clear |
description of VCAT and LCAS control in SONET/SDH and OTN. | description of VCAT and LCAS control in SONET/SDH and OTN. | ||
Line 741: | Line 615: | ||
adjustment procedure in order to avoid manual configuration at | adjustment procedure in order to avoid manual configuration at | ||
each node along the path. | each node along the path. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
From the perspective of the control plane, control of ODUflex | From the perspective of the control plane, control of ODUflex | ||
resizing is similar to control of bandwidth increasing and | resizing is similar to control of bandwidth increasing and | ||
− | decreasing as described in [RFC3209]. Therefore, the Shared | + | decreasing as described in [[RFC3209]]. Therefore, the Shared |
Explicit (SE) style can be used for control of HAO. | Explicit (SE) style can be used for control of HAO. | ||
Line 766: | Line 632: | ||
information to represent ODU Traffic Engineering (TE) topology. | information to represent ODU Traffic Engineering (TE) topology. | ||
− | The Interface Switching Capability Descriptors defined in [RFC4202] | + | The Interface Switching Capability Descriptors defined in [[RFC4202]] |
− | present a new constraint for LSP path computation. [RFC4203] defines | + | present a new constraint for LSP path computation. [[RFC4203]] defines |
the Switching Capability, related Maximum LSP Bandwidth, and | the Switching Capability, related Maximum LSP Bandwidth, and | ||
Switching Capability specific information. When the Switching | Switching Capability specific information. When the Switching | ||
Line 797: | Line 663: | ||
into different HO ODUs. For example, for ODU2e, 9 TSs are needed | into different HO ODUs. For example, for ODU2e, 9 TSs are needed | ||
when multiplexed into an ODU3, while only 8 TSs are needed when | when multiplexed into an ODU3, while only 8 TSs are needed when | ||
− | |||
− | |||
− | |||
− | |||
− | |||
multiplexed into an ODU4. For ODUflex, the total number of TSs to | multiplexed into an ODU4. For ODUflex, the total number of TSs to | ||
Line 839: | Line 700: | ||
operator's policy. Therefore, the routing protocol should be | operator's policy. Therefore, the routing protocol should be | ||
capable of supporting up to 8 priority levels as defined in | capable of supporting up to 8 priority levels as defined in | ||
− | [RFC4202]. | + | [[RFC4202]]. |
- Support link bundling | - Support link bundling | ||
− | As described in [RFC4201], link bundling can improve routing | + | As described in [[RFC4201]], link bundling can improve routing |
scalability by reducing the number of TE links that have to be | scalability by reducing the number of TE links that have to be | ||
handled by the routing protocol. The routing protocol should be | handled by the routing protocol. The routing protocol should be | ||
Line 850: | Line 711: | ||
a TE link does. Note that link bundling is optional and is | a TE link does. Note that link bundling is optional and is | ||
implementation dependent. | implementation dependent. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
- Support for Control of Hitless Adjustment of ODUflex (GFP) | - Support for Control of Hitless Adjustment of ODUflex (GFP) | ||
Line 880: | Line 736: | ||
ends should be correlated. | ends should be correlated. | ||
− | LMP [RFC4204] provides a control-plane protocol for exchanging and | + | LMP [[RFC4204]] provides a control-plane protocol for exchanging and |
correlating link capabilities. | correlating link capabilities. | ||
Line 899: | Line 755: | ||
the granularity of the TS. This ensures the correct use of the TE | the granularity of the TS. This ensures the correct use of the TE | ||
link. | link. | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
- Correlating the supported LO ODU signal types and multiplexing | - Correlating the supported LO ODU signal types and multiplexing | ||
Line 932: | Line 779: | ||
With the introduction of [G709-2012], there may be OTN composed of a | With the introduction of [G709-2012], there may be OTN composed of a | ||
mixture of nodes, some of which support the legacy OTN and run the | mixture of nodes, some of which support the legacy OTN and run the | ||
− | control-plane protocols defined in [RFC4328], while others support | + | control-plane protocols defined in [[RFC4328]], while others support |
[G709-2012] and the new OTN control plane characterized in this | [G709-2012] and the 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 of nodes supporting the legacy OTN referenced by [RFC4328] | + | consists of nodes supporting the legacy OTN referenced by [[RFC4328]] |
with a new OTN control plane, but such nodes can be considered new | with a new OTN control plane, but such nodes can be considered new | ||
nodes with limited 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 in [RFC4328] in support of the | + | control-plane procedures defined in [[RFC4328]] in support of the |
legacy OTN and the control-plane procedures defined to support | legacy OTN and the control-plane procedures defined to support | ||
[G709-2012] as outlined by this document. | [G709-2012] as outlined by this document. | ||
Line 948: | Line 795: | ||
three ODU signal types. In such cases, there are several possible | three ODU signal types. In such cases, there are several possible | ||
options, including: | options, including: | ||
− | |||
- A node supporting [G709-2012] could support only the control-plane | - A node supporting [G709-2012] could support only the control-plane | ||
Line 956: | Line 802: | ||
- A node supporting [G709-2012] could support both the control plane | - A node supporting [G709-2012] could support both the control plane | ||
− | related to [G709-2012] and the control plane defined in [RFC4328]. | + | related to [G709-2012] and the control plane defined in [[RFC4328]]. |
− | |||
− | |||
− | |||
− | |||
o Such a node could identify which set of procedures to follow | o Such a node could identify which set of procedures to follow | ||
Line 976: | Line 818: | ||
=== Implications for Path Computation Elements === | === Implications for Path Computation Elements === | ||
− | [RFC7025] describes the requirements for GMPLS applications of PCE in | + | [[RFC7025]] describes the requirements for GMPLS applications of PCE in |
order to establish GMPLS LSP. PCE needs to consider the GMPLS TE | order to establish GMPLS LSP. PCE needs to consider the GMPLS TE | ||
attributes appropriately once a Path Computation Client (PCC) or | attributes appropriately once a Path Computation Client (PCC) or | ||
another PCE requests a path computation. The TE attributes that can | another PCE requests a path computation. The TE attributes that can | ||
be contained in the path calculation request message from the PCC or | be contained in the path calculation request message from the PCC or | ||
− | the PCE defined in [RFC5440] include switching capability, encoding | + | the PCE defined in [[RFC5440]] include switching capability, encoding |
type, signal type, etc. | type, signal type, etc. | ||
Line 994: | Line 836: | ||
From the management perspective, the management function should be | From the management perspective, the management function should be | ||
− | capable of managing not only the legacy OTN referenced by [RFC4328], | + | capable of managing not only the legacy OTN referenced by [[RFC4328]], |
but also new management functions introduced by the new features as | but also new management functions introduced by the new features as | ||
specified in [G709-2012] (for more information, see Sections 3 and | specified in [G709-2012] (for more information, see Sections 3 and | ||
Line 1,001: | Line 843: | ||
(NMS) or the GMPLS control plane as defined in [TDM-OAM]. For | (NMS) or the GMPLS control plane as defined in [TDM-OAM]. For | ||
further details on management aspects for GMPLS networks, refer to | further details on management aspects for GMPLS networks, refer to | ||
− | [RFC3945]. | + | [[RFC3945]]. |
In case PCE is used to perform path computation in OTN, the PCE | In case PCE is used to perform path computation in OTN, the PCE | ||
manageability should be considered (for more information, see | manageability should be considered (for more information, see | ||
− | Section 8 of [RFC5440]). | + | Section 8 of [[RFC5440]]). |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
== Data-Plane Backward Compatibility Considerations == | == Data-Plane Backward Compatibility Considerations == | ||
Line 1,056: | Line 890: | ||
computation opens an OTN to security threats through attacks on those | computation opens an OTN to security threats through attacks on those | ||
protocols. However, this is not greater than the risks presented by | protocols. However, 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]]. |
Meanwhile, the Data Communication Network (DCN) for OTN GMPLS | Meanwhile, the Data Communication Network (DCN) for OTN GMPLS | ||
control-plane protocols is likely to be in the in-fiber overhead, | control-plane protocols is likely to be in the in-fiber overhead, | ||
Line 1,063: | Line 897: | ||
security measures, refer to the documents that define the protocols | security measures, refer to the documents that define the protocols | ||
− | + | ([[RFC3473]], [[RFC4203]], [[RFC5307]], [[RFC4204]], and [[RFC5440]]). | |
− | + | [[RFC5920]] provides an overview of security vulnerabilities and | |
− | |||
− | |||
− | |||
− | ([RFC3473], [RFC4203], [RFC5307], [RFC4204], and [RFC5440]). | ||
− | [RFC5920] provides an overview of security vulnerabilities and | ||
protection mechanisms for the GMPLS control plane. | protection mechanisms for the GMPLS control plane. | ||
Line 1,087: | Line 916: | ||
Phone: +86-755-28972913 | Phone: +86-755-28972913 | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
Malcolm Betts | Malcolm Betts | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
Pietro Grandi | Pietro Grandi | ||
Line 1,101: | Line 928: | ||
Phone: +39 039 6864930 | Phone: +39 039 6864930 | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
Eve Varma | Eve Varma | ||
Line 1,111: | Line 937: | ||
EMail: [email protected] | EMail: [email protected] | ||
+ | 10. References | ||
+ | 10.1. Normative References | ||
+ | [G709-2012] ITU-T, "Interface for the Optical Transport Network | ||
+ | (OTN)", G.709/Y.1331 Recommendation, February 2012. | ||
+ | [[RFC3209]] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., | ||
+ | and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP | ||
+ | Tunnels", [[RFC3209|RFC 3209]], December 2001. | ||
+ | [[RFC3471]] Berger, L., Ed., "Generalized Multi-Protocol Label | ||
+ | Switching (GMPLS) Signaling Functional Description", RFC | ||
+ | 3471, January 2003. | ||
+ | [[RFC3473]] Berger, L., Ed., "Generalized Multi-Protocol Label | ||
+ | Switching (GMPLS) Signaling Resource ReserVation | ||
+ | Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC | ||
+ | 3473, January 2003. | ||
+ | [[RFC4201]] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling | ||
+ | in MPLS Traffic Engineering (TE)", [[RFC4201|RFC 4201]], October | ||
+ | 2005. | ||
+ | [[RFC4202]] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing | ||
+ | Extensions in Support of Generalized Multi-Protocol Label | ||
+ | Switching (GMPLS)", [[RFC4202|RFC 4202]], October 2005. | ||
+ | [[RFC4203]] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions | ||
+ | in Support of Generalized Multi-Protocol Label Switching | ||
+ | (GMPLS)", [[RFC4203|RFC 4203]], October 2005. | ||
+ | [[RFC4204]] Lang, J., Ed., "Link Management Protocol (LMP)", RFC | ||
+ | 4204, October 2005. | ||
− | + | [[RFC4206]] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP) | |
− | + | Hierarchy with Generalized Multi-Protocol Label Switching | |
− | + | (GMPLS) Traffic Engineering (TE)", [[RFC4206|RFC 4206]], October | |
− | + | 2005. | |
− | [ | ||
− | [ | ||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
+ | [[RFC4328]] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label | ||
+ | Switching (GMPLS) Signaling Extensions for G.709 Optical | ||
+ | Transport Networks Control", [[RFC4328|RFC 4328]], January 2006. | ||
+ | [[RFC5307]] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions | ||
+ | in Support of Generalized Multi-Protocol Label Switching | ||
+ | (GMPLS)", [[RFC5307|RFC 5307]], October 2008. | ||
+ | [[RFC5440]] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path | ||
+ | Computation Element (PCE) Communication Protocol (PCEP)", | ||
+ | [[RFC5440|RFC 5440]], March 2009. | ||
+ | [[RFC6001]] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, | ||
+ | D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol | ||
+ | Extensions for Multi-Layer and Multi-Region Networks | ||
+ | (MLN/MRN)", [[RFC6001|RFC 6001]], October 2010. | ||
+ | [[RFC6107]] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for | ||
+ | Dynamically Signaled Hierarchical Label Switched Paths", | ||
+ | [[RFC6107|RFC 6107]], February 2011. | ||
+ | [[RFC6344]] Bernstein, G., Ed., Caviglia, D., Rabbat, R., and H. van | ||
+ | Helvoort, "Operating Virtual Concatenation (VCAT) and the | ||
+ | Link Capacity Adjustment Scheme (LCAS) with Generalized | ||
+ | Multi-Protocol Label Switching (GMPLS)", [[RFC6344|RFC 6344]], August | ||
+ | 2011. | ||
+ | 10.2. Informative References | ||
+ | [G798] ITU-T, "Characteristics of optical transport network | ||
+ | hierarchy equipment functional blocks", G.798 | ||
+ | Recommendation, December 2012. | ||
+ | [G872-2001] ITU-T, "Architecture of optical transport networks", | ||
+ | G.872 Recommendation, November 2001. | ||
+ | [G872-2012] ITU-T, "Architecture of optical transport networks", | ||
+ | G.872 Recommendation, October 2012. | ||
+ | [G7041] ITU-T, "Generic framing procedure", G.7041/Y.1303, April | ||
+ | 2011. | ||
+ | [G7042] ITU-T, "Link capacity adjustment scheme (LCAS) for | ||
+ | virtual concatenated signals", G.7042/Y.1305, March 2006. | ||
+ | [G7044] ITU-T, "Hitless adjustment of ODUflex (HAO)", | ||
+ | G.7044/Y.1347, October 2011. | ||
+ | [[RFC3945]] Mannie, E., Ed., "Generalized Multi-Protocol Label | ||
+ | Switching (GMPLS) Architecture", [[RFC3945|RFC 3945]], October 2004. | ||
+ | [[RFC4655]] Farrel, A., Vasseur, J.-P., and J. Ash, "A Path | ||
+ | Computation Element (PCE)-Based Architecture", [[RFC4655|RFC 4655]], | ||
+ | August 2006. | ||
+ | [[RFC6163]] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku, | ||
+ | "Framework for GMPLS and Path Computation Element (PCE) | ||
+ | Control of Wavelength Switched Optical Networks (WSONs)", | ||
+ | [[RFC6163|RFC 6163]], April 2011. | ||
+ | [[RFC5920]] Fang, L., Ed., "Security Framework for MPLS and GMPLS | ||
+ | Networks", [[RFC5920|RFC 5920]], July 2010. | ||
+ | [[RFC7025]] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C. | ||
+ | Margaria, "Requirements for GMPLS Applications of PCE", | ||
+ | [[RFC7025|RFC 7025]], September 2013. | ||
+ | [TDM-OAM] Kern, A., and A. Takacs, "GMPLS RSVP-TE Extensions for | ||
+ | SONET/SDH and OTN OAM Configuration", Work in Progress, | ||
+ | November 2013. | ||
Authors' Addresses | Authors' Addresses | ||
Line 1,212: | Line 1,058: | ||
Phone: +86-755-28972912 | Phone: +86-755-28972912 | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
Dan Li | Dan Li | ||
Line 1,222: | Line 1,067: | ||
Phone: +86-755-28973237 | Phone: +86-755-28973237 | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
Han Li | Han Li | ||
Line 1,231: | Line 1,075: | ||
Phone: +86-10-66006688 | Phone: +86-10-66006688 | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
Sergio Belotti | Sergio Belotti | ||
Line 1,241: | Line 1,084: | ||
Phone: +39 039 6863033 | Phone: +39 039 6863033 | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
Daniele Ceccarelli | Daniele Ceccarelli | ||
Line 1,249: | Line 1,091: | ||
Italy | Italy | ||
EMail: [email protected] | EMail: [email protected] | ||
− | |||
− | |||
− | |||
[[Category:Informational]] | [[Category:Informational]] |
Latest revision as of 00:14, 2 October 2020
Internet Engineering Task Force (IETF) F. Zhang, Ed. Request for Comments: 7062 D. Li Category: Informational Huawei ISSN: 2070-1721 H. Li
CMCC S. Belotti Alcatel-Lucent D. Ceccarelli Ericsson November 2013
Framework for GMPLS and PCE Control of G.709 Optical Transport Networks
Abstract
This document provides a framework to allow the development of protocol extensions to support Generalized Multi-Protocol Label Switching (GMPLS) and Path Computation Element (PCE) control of Optical Transport Networks (OTNs) as specified in ITU-T Recommendation G.709 as published in 2012.
Status of This Memo
This document is not an Internet Standards Track specification; it is published for informational purposes.
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7062.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Contents
- 1 Introduction
- 2 Terminology
- 3 G.709 Optical Transport Network
- 4 Connection Management in OTN
- 5 GMPLS/PCE Implications
- 5.1 Implications for Label Switched Path (LSP) Hierarchy
- 5.2 Implications for GMPLS Signaling
- 5.3 Implications for GMPLS Routing
- 5.4 Implications for Link Management Protocol
- 5.5 Implications for Control-Plane Backward Compatibility
- 5.6 Implications for Path Computation Elements
- 5.7 Implications for Management of GMPLS Networks
- 6 Data-Plane Backward Compatibility Considerations
- 7 Security Considerations
- 8 Acknowledgments
- 9 Contributors
Introduction
Optical Transport Networks (OTNs) have become a mainstream layer 1 technology for the transport network. Operators want to introduce control-plane capabilities based on GMPLS to OTN to realize the benefits associated with a high-function control plane (e.g., improved network resiliency, resource usage efficiency, etc.).
GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass Time Division Multiplexing (TDM) networks (e.g., Synchronous Optical NETwork (SONET) / Synchronous Digital Hierarchy (SDH), Plesiochronous Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching optical networks, and spatial switching (e.g., incoming port or fiber to outgoing port or fiber). The GMPLS architecture is provided in RFC3945, signaling function and Resource Reservation Protocol - Traffic Engineering (RSVP-TE) extensions are described in RFC3471 and RFC3473, routing and Open Shortest Path First (OSPF) extensions are described in RFC4202 and RFC4203, and the Link Management Protocol (LMP) is described in RFC4204.
The GMPLS signaling extensions defined in RFC4328 provide the mechanisms for basic GMPLS control of OTN based on the 2001 revision of the G.709 specification. The 2012 revision of the G.709 specification, [G709-2012], includes new features, for example, various multiplexing structures, two types of Tributary Slots (TSs) (i.e., 1.25 Gbps and 2.5G bps), and extension of the Optical channel Data Unit-j (ODUj) definition to include the ODUflex function.
This document reviews relevant aspects of OTN technology evolution that affect the GMPLS control-plane protocols and examines why and how to update the mechanisms described in RFC4328. This document additionally provides a framework for GMPLS control of OTN and includes a discussion of the implications for the use of the PCE RFC4655.
For the purposes of the control plane, the OTN can be considered to be comprised of ODU and wavelength (Optical Channel (OCh)) layers. This document focuses on the control of the ODU layer, with control of the wavelength layer considered out of the scope. Please refer to RFC6163 for further information about the wavelength layer.
Terminology
OTN: Optical Transport Network
OPU: Optical Channel Payload Unit
ODU: Optical Channel Data Unit
OTU: Optical Channel Transport Unit
OMS: Optical Multiplex Section
MSI: Multiplex Structure Identifier
TPN: Tributary Port Number
LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4, or flex) represents the container transporting a client of the OTN that is either directly mapped into an OTUk (k = j) or multiplexed into a server HO ODUk (k > j) container.
HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, or 4) represents the entity transporting a multiplex of LO ODUj tributary signals in its OPUk area.
ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a bit rate tolerance of +/-100 ppm (parts per million).
In general, throughout this document, "ODUj" is used to refer to ODU entities acting as an LO ODU, and "ODUk" is used to refer to ODU entities being used as an HO ODU.
G.709 Optical Transport Network
This section provides an informative overview of the aspects of the OTN impacting control-plane protocols. This overview is based on the ITU-T Recommendations that contain the normative definition of the OTN. Technical details regarding OTN architecture and interfaces are provided in the relevant ITU-T Recommendations.
Specifically, [G872-2012] describes the functional architecture of optical transport networks providing optical signal transmission, multiplexing, routing, supervision, performance assessment, and network survivability. The legacy OTN referenced by RFC4328 defines the interfaces of the optical transport network to be used within and between subnetworks of the optical network. With the evolution and deployment of OTN technology, many new features have been specified in ITU-T recommendations, including, for example, new ODU0, ODU2e, ODU4, and ODUflex containers as described in [G709-2012].
OTN Layer Network
The simplified signal hierarchy of OTN is shown in Figure 1, which illustrates the layers that are of interest to the control plane. Other layers below OCh (e.g., Optical Transmission Section (OTS)) are not included in this figure. The full signal hierarchy is provided in [G709-2012].
Client signal | ODUj | OTU/OCh OMS
Figure 1: Basic OTN Signal Hierarchy
Client signals are mapped into ODUj containers. These ODUj containers are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are combined in the OMS using Wavelength Division Multiplexing (WDM), and this aggregated signal provides the link between the nodes.
Client Signal Mapping
The client signals are mapped into an LO ODUj. The current values of j defined in [G709-2012] are: 0, 1, 2, 2e, 3, 4, and flex. The approximate bit rates of these signals are defined in [G709-2012] and are reproduced in Tables 1 and 2.
+-----------------------+-----------------------------------+ | ODU Type | ODU nominal bit rate | +-----------------------+-----------------------------------+ | ODU0 | 1,244,160 Kbps | | ODU1 | 239/238 x 2,488,320 Kbps | | ODU2 | 239/237 x 9,953,280 Kbps | | ODU3 | 239/236 x 39,813,120 Kbps | | ODU4 | 239/227 x 99,532,800 Kbps | | ODU2e | 239/237 x 10,312,500 Kbps | | | | | ODUflex for | | |Constant Bit Rate (CBR)| 239/238 x client signal bit rate | | Client signals | | | | | | ODUflex for Generic | | | Framing Procedure | Configured bit rate | | - Framed (GFP-F) | | | Mapped client signal | | +-----------------------+-----------------------------------+
Table 1: ODU Types and Bit Rates
NOTE: The nominal ODUk rates are approximately: 2,498,775.126 Kbps (ODU1), 10,037,273.924 Kbps (ODU2), 40,319,218.983 Kbps (ODU3), 104,794,445.815 Kbps (ODU4), and 10,399,525.316 Kbps (ODU2e).
+-----------------------+-----------------------------------+ | ODU Type | ODU bit rate tolerance | +-----------------------+-----------------------------------+ | ODU0 | +/-20 ppm | | ODU1 | +/-20 ppm | | ODU2 | +/-20 ppm | | ODU3 | +/-20 ppm | | ODU4 | +/-20 ppm | | ODU2e | +/-100 ppm | | | | | ODUflex for CBR | | | Client signals | +/-100 ppm | | | | | ODUflex for GFP-F | | | Mapped client signal | +/-100 ppm | +-----------------------+-----------------------------------+
Table 2: ODU Types and Tolerance
One of two options is for mapping client signals into ODUflex depending on the client signal type:
- Circuit clients are proportionally wrapped. Thus, the bit rate is
defined by the client signal, and the tolerance is fixed to +/-100 ppm.
- Packet clients are mapped using the Generic Framing Procedure
(GFP). [G709-2012] 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, and the tolerance should be +/-100 ppm.
Note that additional information on G.709 client mapping can be found in [G7041].
Multiplexing ODUj onto Links
The links between the switching nodes are provided by one or more wavelengths. Each wavelength carries one OCh, which carries one OTU, 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 mapped into the TSs (Tributary Slots) of the OPUk. Note that in the case where j=k, the ODUj is mapped into the OTU/OCh without multiplexing.
The initial versions of G.709 referenced by RFC4328 only provided a single TS granularity, nominally 2.5 Gbps. [G709-2012] added an additional TS granularity, nominally 1.25 Gbps. The number and type of TS provided by each of the currently identified OTUk are provided below:
Tributary Slot Granularity 2.5 Gbps 1.25 Gbps Nominal Bit Rate OTU1 1 2 2.5 Gbps OTU2 4 8 10 Gbps OTU3 16 32 40 Gbps OTU4 -- 80 100 Gbps
To maintain backward compatibility while providing the ability to interconnect nodes that support a 1.25 Gbps TS at one end of a link and a 2.5 Gbps TS at the other, [G709-2012] requires 'new' equipment to fall back to the use of a 2.5 Gbps TS when connected to legacy equipment. This 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. Thus, the number of TSs occupied by an ODUj may vary depending on the values of j and k. For example, an ODU2e uses 9 TSs in an OTU3 but only 8 in an OTU4. Examples of the number of TSs used for various cases are provided below (referring to Tables 7-9 of [G709-2012]):
- ODU0 into ODU1, ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS
granularity o ODU0 occupies 1 of the 2, 8, 32, or 80 TSs for ODU1, ODU2, ODU3, or ODU4
- ODU1 into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS
granularity o ODU1 occupies 2 of the 8, 32, or 80 TSs for ODU2, ODU3, or ODU4
- ODU1 into ODU2 or ODU3 multiplexing with 2.5 Gbps TS granularity
o ODU1 occupies 1 of the 4 or 16 TSs for ODU2 or ODU3
- ODU2 into ODU3 or ODU4 multiplexing with 1.25 Gbps TS granularity
o ODU2 occupies 8 of the 32 or 80 TSs for ODU3 or ODU4
- ODU2 into ODU3 multiplexing with 2.5 Gbps TS granularity
o ODU2 occupies 4 of the 16 TSs for ODU3
- ODU3 into ODU4 multiplexing with 1.25 Gbps TS granularity
o ODU3 occupies 31 of the 80 TSs for ODU4
- ODUflex into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS
granularity o ODUflex occupies n of the 8, 32, or 80 TSs for ODU2, ODU3, or ODU4 (n <= Total TS number of ODUk)
- ODU2e into ODU3 or ODU4 multiplexing with 1.25 Gbps TS granularity
o ODU2e occupies 9 of the 32 TSs for ODU3 or 8 of the 80 TSs for ODU4
In general, the mapping of an ODUj (including ODUflex) into a specific OTUk TS is determined locally, and it can also be explicitly controlled by a specific entity (e.g., head end or Network Management System (NMS)) through Explicit Label Control RFC3473.
Structure of MSI Information
When multiplexing an ODUj into an HO ODUk (k>j), G.709 specifies the information that has to be transported in-band in order to allow for correct demultiplexing. This information, known as MSI, is transported in the OPUk overhead and is local to each link. In case of bidirectional paths, the association between the TPN and TS must be the same in both directions.
The MSI information is organized as a set of entries, with one entry for each HO ODUj TS. The information carried by each entry is:
- Payload Type: the type of the transported payload.
- TPN: the port number of the ODUj transported by the HO ODUk. The
TPN is the same for all the TSs assigned to the transport of the same ODUj instance.
For example, an ODU2 carried by an HO ODU3 is described by 4 entries in the OPU3 overhead when the TS granularity is 2.5 Gbps, and by 8 entries when the TS granularity is 1.25 Gbps.
On each node and on every link, two MSI values have to be provisioned (referring to [G798]):
- The Transmitted MSI (TxMSI) information inserted in OPU (e.g.,
OPU3) overhead by the source of the HO ODUk trail.
- The Expected MSI (ExMSI) information that is used to check the
Accepted MSI (AcMSI) information. The AcMSI information is the MSI valued received in-band, after a three-frame integration.
As described in [G798], the sink of the HO ODU trail checks the complete content of the AcMSI information against the ExMSI. If the AcMSI is different from the ExMSI, then the traffic is dropped, and a payload mismatch alarm is generated.
Provisioning of TPN can be performed by either a network management system or control plane. In the last case, the control plane is also responsible for negotiating the provisioned values on a link-by-link basis.
Connection Management in OTN
OTN-based connection management is concerned with controlling the connectivity of ODU paths and OCh. This document focuses on the connection management of ODU paths. The management of OCh paths is described in RFC6163.
While [G872-2001] considered the ODU to be a set of layers in the same way as SDH has been modeled, recent ITU-T OTN architecture progress [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. 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 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 supported by HO ODU (which has a one-to-one relationship with the OTU).
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 the OCh layer (independent of whether the OTU supports an HO ODU, where multiplexing is utilized, or an LO ODU in the case of direct mapping).
Thus, the OTU and OCh layers should be visible in a single topological representation of the network, and from a logical perspective, the OTU and OCh may be considered as the same logical, switchable entity.
Note that the OTU link-layer topology may be provided via various infrastructure alternatives, including point-to-point optical connections, optical connections fully in the optical domain, and optical connections involving hybrid sub-lambda/lambda nodes involving 3R, etc. See RFC6163 for additional information.
Connection Management of the ODU
An 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 mapped into an OCh.
From the perspective of the control plane, there are two kinds of network topology to be considered.
(1) ODU layer
In this case, the ODU links are presented between adjacent OTN nodes, as illustrated in Figure 2. In this layer, there are ODU links with a variety of TSs available, and nodes that are Optical Digital Cross Connects (ODXCs). LO ODU connections can be set up based on the network topology.
Link #5 +--+---+--+ Link #4 +--------------------------| |--------------------------+ | | ODXC | | | +---------+ | | Node E | | |
+-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++ | |Link #1 | |Link #2 | |Link #3 | | | |--------| |--------| |--------| | | ODXC | | ODXC | | ODXC | | ODXC | +---------+ +---------+ +---------+ +---------+
Node A Node B Node C Node D
Figure 2: Example Topology for LO ODU Connection Management
If an ODUj connection is requested between Node C and Node E, routing/path computation must select a path that has the required number of TSs available and that offers the lowest cost. Signaling is then invoked to set up the path and to provide the information (e.g., selected TSs) required by each transit node to allow the configuration of the ODUj-to-OTUk mapping (j = k) or multiplexing (j < k) and demapping (j = k) or demultiplexing (j < k).
(2) ODU layer with OCh switching capability
In this case, the OTN nodes interconnect with wavelength switched nodes (e.g., Reconfiguration Optical Add/Drop Multiplexer (ROADM) or Optical Cross-Connect (OXC)) that are capable of OCh switching; this is illustrated in Figures 3 and 4. There are the ODU layer and the OCh layer, so it is simply a Multi-Layer Network (MLN) (see
RFC6001). OCh connections may be created on demand, which is described in Section 5.1.
In this case, an operator may choose to allow the underlying OCh layer to be visible to the ODU routing/path computation process, in which case the topology would be as shown in Figure 4. In Figure 3, however, a cloud representing OCh-capable switching nodes is represented. In Figure 3, the operator choice is to hide the real OCh-layer network topology.
Node E Link #5 +--------+ Link #4 +------------------------| |------------------------+ | ------ | | // \\ | | || || | | | OCh domain | |
+-+-----+ +------ || || ------+ +-----+-+ | | | \\ // | | | | |Link #1 | -------- |Link #3 | | | +--------+ | | +--------+ + | ODXC | | ODXC +--------+ ODXC | | ODXC | +-------+ +---------+Link #2 +---------+ +-------+
Node A Node B Node C Node D
Figure 3: OCh Hidden Topology for LO ODU Connection Management
Link #5 +---------+ Link #4 +------------------------| |-----------------------+ | +----| ODXC |----+ | | +-++ +---------+ ++-+ | | Node f | | Node E | | Node g | | +-++ ++-+ | | | +--+ | |
+-+-----+ +----+----+--| |--+-----+---+ +-----+-+ | |Link #1 | | +--+ | |Link #3 | | | +--------+ | Node h | +--------+ | | ODXC | | ODXC +--------+ ODXC | | ODXC | +-------+ +---------+ Link #2+---------+ +-------+
Node A Node B Node C Node D
Figure 4: OCh Visible Topology for LO ODUj Connection Management
In Figure 4, the cloud in the previous figure is substituted by the real topology. The nodes f, g, and h are nodes with OCh switching capability.
In the examples (i.e., Figures 3 and 4), we have considered the case in which LO ODUj connections are supported by an OCh connection and the case in which the supporting underlying connection can also be made by a combination of HO ODU/OCh connections.
In this case, the ODU routing/path selection process will request an HO ODU/OCh connection between node C and node E from the OCh domain. The connection will appear at the ODU level as a Forwarding Adjacency, which will be used to create the ODU connection.
GMPLS/PCE Implications
The purpose of this section is to provide a set of requirements to be evaluated for extensions of the current GMPLS protocol suite and the PCE applications and protocols to encompass OTN enhancements and connection management.
Implications for Label Switched Path (LSP) Hierarchy
The path computation for an ODU connection request is based on the topology of the ODU layer.
The OTN path computation can be divided into two layers. One layer is OCh/OTUk; the other is ODUj. RFC4206 and RFC6107 define the mechanisms to accomplish creating the hierarchy of LSPs. The LSP management of multiple layers in OTN can follow the procedures defined in RFC4206, RFC6001, and RFC6107.
As discussed in Section 4, the route path computation for OCh is in the scope of the Wavelength Switched Optical Network (WSON) RFC6163. Therefore, this document only considers the ODU layer for an ODU connection request.
The LSP hierarchy can also be applied within the ODU layers. One of the typical scenarios for ODU layer hierarchy is to maintain compatibility with introducing new [G709-2012] services (e.g., ODU0 and ODUflex) into a legacy network configuration (i.e., the legacy OTN referenced by RFC4328). In this scenario, it may be necessary to consider introducing hierarchical multiplexing capability in specific network transition scenarios. One method for enabling multiplexing hierarchy is by introducing dedicated boards in a few specific places in the network and tunneling these new services through the legacy containers (ODU1, ODU2, ODU3), thus postponing the need to upgrade every network element to [G709-2012] capabilities.
In such cases, one ODUj connection can be nested into another ODUk (j<k) connection, which forms the LSP hierarchy in the ODU layer. The creation of the outer ODUk connection can be triggered via network planning or by the signaling of the inner ODUj connection. For the former case, the outer ODUk connection can be created in advance based on network planning. For the latter case, the multi- layer network signaling described in RFC4206, RFC6107, and RFC6001 (including related modifications, if needed) is relevant to create the ODU connections with multiplexing hierarchy. In both cases, the outer ODUk connection is advertised as a Forwarding Adjacency (FA).
Implications for GMPLS Signaling
The signaling function and RSVP-TE extensions are described in RFC3471 and RFC3473. For OTN-specific control, RFC4328 defines signaling extensions to support control for the legacy G.709 Optical Transport Networks.
As described in Section 3, [G709-2012] introduced some new features that include the ODU0, ODU2e, ODU4, and ODUflex containers. The mechanisms defined in RFC4328 do not support such new OTN features, and protocol extensions will be necessary to allow them to be controlled by a GMPLS control plane.
RFC4328 defines the LSP Encoding Type, the Switching Type, and the Generalized Protocol Identifier (Generalized-PID) constituting the common part of the Generalized Label Request. The G.709 traffic parameters are also defined in RFC4328. In addition, the following signaling aspects not included in RFC4328 should be considered:
- Support for specifying new signal types and related traffic
information
The traffic parameters should be extended in a signaling message to support the new ODUj, including:
- ODU0 - ODU2e - ODU4 - ODUflex
For the ODUflex signal type, the bit rate must be carried additionally in the traffic parameter to set up an ODUflex connection.
For other ODU signal types, the bit rates and tolerances are fixed and can be deduced from the signal types.
- Support for LSP setup using different TS granularity
The signaling protocol should be able to identify the TS granularity (i.e., the 2.5 Gbps TS granularity and the new 1.25 Gbps TS granularity) to be used for establishing a Hierarchical LSP that will be used to carry service LSP(s) requiring a specific TS granularity.
- Support for LSP setup of new ODUk/ODUflex containers with related
mapping and multiplexing capabilities
A new label format must be defined to carry the exact TS's allocation information related to the extended mapping and multiplexing hierarchy (for example, ODU0 into ODU2 multiplexing (with 1.25 Gbps TS granularity)), in order to set up the ODU connection.
- Support for TPN allocation and negotiation
TPN needs to be configured as part of the MSI information (see more information in Section 3.1.2.1). A signaling mechanism must be identified to carry TPN information if the control plane is used to configure MSI information.
- Support for ODU Virtual Concatenation (VCAT) and Link Capacity
Adjustment Scheme (LCAS)
GMPLS signaling should support the creation of Virtual Concatenation of an ODUk signal with k=1, 2, 3. The signaling should also support the control of dynamic capacity changing of a VCAT container using LCAS ([G7042]). RFC6344 has a clear description of VCAT and LCAS control in SONET/SDH and OTN.
- Support for Control of Hitless Adjustment of ODUflex (GFP)
[G7044] has been created in ITU-T to specify hitless adjustment of ODUflex (GFP) (HAO) that is used to increase or decrease the bandwidth of an ODUflex (GFP) that is transported in an OTN.
The procedure of ODUflex (GFP) adjustment requires the participation of every node along the path. Therefore, it is recommended to use control-plane signaling to initiate the adjustment procedure in order to avoid manual configuration at each node along the path.
From the perspective of the control plane, control of ODUflex resizing is similar to control of bandwidth increasing and decreasing as described in RFC3209. Therefore, the Shared Explicit (SE) style can be used for control of HAO.
All the extensions above should consider the extensibility to match future evolvement of OTN.
Implications for GMPLS Routing
The path computation process needs to select a suitable route for an ODUj connection request. In order to perform the path computation, it needs to evaluate the available bandwidth on each candidate link. The routing protocol should be extended to convey sufficient information to represent ODU Traffic Engineering (TE) topology.
The Interface Switching Capability Descriptors defined in RFC4202 present a new constraint for LSP path computation. RFC4203 defines the Switching Capability, related Maximum LSP Bandwidth, and Switching Capability specific information. When the Switching Capability field is TDM, the Switching Capability specific information field includes Minimum LSP Bandwidth, an indication whether the interface supports Standard or Arbitrary SONET/SDH, and padding. Hence, a new Switching Capability value needs to be defined for [G709-2012] ODU switching in order to allow the definition of a new Switching Capability specific information field. The following requirements should be considered:
- Support for carrying the link multiplexing capability
As discussed in Section 3.1.2, many different types of ODUj can be multiplexed into the same OTUk. For example, both ODU0 and ODU1 may be multiplexed into ODU2. An OTU link may support one or more types of ODUj signals. The routing protocol should be capable of carrying this multiplexing capability.
- Support any ODU and ODUflex
The bit rate (i.e., bandwidth) of each TS is dependent on the TS granularity and the signal type of the link. For example, the bandwidth of a 1.25 Gbps TS in an OTU2 is about 1.249409620 Gbps, while the bandwidth of a 1.25 Gbps TS in an OTU3 is about 1.254703729 Gbps.
One LO ODU may need a different number of TSs when multiplexed into different HO ODUs. For example, for ODU2e, 9 TSs are needed when multiplexed into an ODU3, while only 8 TSs are needed when
multiplexed into an ODU4. For ODUflex, the total number of TSs to be reserved in an HO ODU equals the maximum of [bandwidth of ODUflex / bandwidth of TS of the HO ODU].
Therefore, the routing protocol should be capable of carrying the necessary link bandwidth information for performing accurate route computation for any of the fixed rate ODUs as well as ODUflex.
- Support for differentiating between terminating and switching
capability
Due to internal constraints and/or limitations, the type of signal being advertised by an interface could be restricted to switched (i.e., forwarded to switching matrix without multiplexing/demultiplexing actions), restricted to terminated (demuxed), or both. The capability advertised by an interface needs further distinction in order to separate termination and switching capabilities.
Therefore, to allow the required flexibility, the routing protocol should clearly distinguish the terminating and switching capability.
- Support for Tributary Slot Granularity advertisement
[G709-2012] defines two types of TSs, but each link can only support a single type at a given time. In order to perform a correct path computation (i.e., the LSP endpoints have matching Tributary Slot Granularity values) the Tributary Slot Granularity needs to be advertised.
- Support different priorities for resource reservation
How many priority levels should be supported depends on the operator's policy. Therefore, the routing protocol should be capable of supporting up to 8 priority levels as defined in RFC4202.
- Support link bundling
As described in RFC4201, link bundling can improve routing scalability by reducing the number of TE links that have to be handled by the routing protocol. The routing protocol should be capable of supporting the bundling of multiple OTU links, at the same line rate and muxing hierarchy, between a pair of nodes that a TE link does. Note that link bundling is optional and is implementation dependent.
- Support for Control of Hitless Adjustment of ODUflex (GFP)
The control plane should support hitless adjustment of ODUflex, so the routing protocol should be capable of differentiating whether or not an ODU link can support hitless adjustment of ODUflex (GFP) and how many resources can be used for resizing. This can be achieved by introducing a new signal type "ODUflex(GFP-F), resizable" that implies the support for hitless adjustment of ODUflex (GFP) by that link.
As mentioned in Section 5.1, one method of enabling multiplexing hierarchy is via usage of dedicated boards to allow tunneling of new services through legacy ODU1, ODU2, and ODU3 containers. Such dedicated boards may have some constraints with respect to switching matrix access; detection and representation of such constraints is for further study.
Implications for Link Management Protocol
As discussed in Section 5.3, path computation needs to know the interface switching capability of links. The switching capability of two ends of the link may be different, so the link capability of two ends should be correlated.
LMP RFC4204 provides a control-plane protocol for exchanging and correlating link capabilities.
Note that LO ODU type information can be, in principle, discovered by routing. Since in certain cases, routing is not present (e.g., in the case of a User-Network Interface (UNI)), we need to extend link management protocol capabilities to cover this aspect. If routing is present, discovery via LMP could also be optional.
- Correlating the granularity of the TS
As discussed in Section 3.1.2, the two ends of a link may support different TS granularity. In order to allow interconnection, the node with 1.25 Gbps granularity should fall back to 2.5 Gbps granularity.
Therefore, it is necessary for the two ends of a link to correlate the granularity of the TS. This ensures the correct use of the TE link.
- Correlating the supported LO ODU signal types and multiplexing
hierarchy capability
Many new ODU signal types have been introduced in [G709-2012], such as ODU0, ODU4, ODU2e, and ODUflex. It is possible that equipment does not support all the LO ODU signal types introduced by new standards or documents. Furthermore, since multiplexing hierarchy may not be supported by the legacy OTNs, it is possible that only one end of an ODU link can support multiplexing hierarchy capability or that the two ends of the link support different multiplexing hierarchy capabilities (e.g., one end of the link supports ODU0 into ODU1 into ODU3 multiplexing while the other end supports ODU0 into ODU2 into ODU3 multiplexing).
For control and management consideration, it is necessary for the two ends of an HO ODU link to correlate the types of LO ODU that can be supported and the multiplexing hierarchy capabilities that can be provided by the other end.
Implications for Control-Plane Backward Compatibility
With the introduction of [G709-2012], there may be OTN composed of a mixture of nodes, some of which support the legacy OTN and run the control-plane protocols defined in RFC4328, while others support [G709-2012] and the new OTN control plane characterized in this document. Note that a third case, for the sake of completeness, consists of nodes supporting the legacy OTN referenced by RFC4328 with a new OTN control plane, but such nodes can be considered new nodes with limited capabilities.
This section discusses the compatibility of nodes implementing the control-plane procedures defined in RFC4328 in support of the legacy OTN and the control-plane procedures defined to support [G709-2012] as outlined by this document.
Compatibility needs to be considered only when controlling an ODU1, ODU2, or ODU3 connection because the legacy OTN only supports these three ODU signal types. In such cases, there are several possible options, including:
- A node supporting [G709-2012] could support only the control-plane
procedures related to [G709-2012], in which case both types of nodes would be unable to jointly control an LSP for an ODU type that both nodes support in the data plane.
- A node supporting [G709-2012] could support both the control plane
related to [G709-2012] and the control plane defined in RFC4328.
o Such a node could identify which set of procedures to follow when initiating an LSP based on the Switching Capability value advertised in routing.
o Such a node could follow the set of procedures based on the Switching Type received in signaling messages from an upstream node.
o Such a node, when processing a transit LSP, could select which signaling procedures to follow based on the Switching Capability value advertised in routing by the next-hop node.
Implications for Path Computation Elements
RFC7025 describes the requirements for GMPLS applications of PCE in order to establish GMPLS LSP. PCE needs to consider the GMPLS TE attributes appropriately once a Path Computation Client (PCC) or another PCE requests a path computation. The TE attributes that can be contained in the path calculation request message from the PCC or the PCE defined in RFC5440 include switching capability, encoding type, signal type, etc.
As described in Section 5.2, new signal types and new signals with variable bandwidth information need to be carried in the extended signaling message of path setup. For the same consideration, the PCE Communication Protocol (PCECP) also has a desire to be extended to carry the new signal type and related variable bandwidth information when a PCC requests a path computation.
Implications for Management of GMPLS Networks
From the management perspective, the management function should be capable of managing not only the legacy OTN referenced by RFC4328, but also new management functions introduced by the new features as specified in [G709-2012] (for more information, see Sections 3 and 4). OTN Operations, Administration, and Maintenance (OAM) configuration could be done through either Network Management Systems (NMS) or the GMPLS control plane as defined in [TDM-OAM]. For further details on management aspects for GMPLS networks, refer to RFC3945.
In case PCE is used to perform path computation in OTN, the PCE manageability should be considered (for more information, see Section 8 of RFC5440).
Data-Plane Backward Compatibility Considerations
If MI AUTOpayloadtype is activated (see [G798]), a node supporting 1.25 Gbps TS can interwork with the other nodes that support 2.5 Gbps TS by combining specific TSs together in the data plane. The control plane must support this TS combination.
Path +----------+ ------------> +----------+ | TS1==|===========\--------+--TS1 | | TS2==|=========\--\-------+--TS2 | | TS3==|=======\--\--\------+--TS3 | | TS4==|=====\--\--\--\-----+--TS4 | | | \ \ \ \----+--TS5 | | | \ \ \------+--TS6 | | | \ \--------+--TS7 | | | \----------+--TS8 | +----------+ <------------ +----------+ node A Resv node B
Figure 5: Interworking between 1.25 Gbps TS and 2.5 Gbps TS
Take Figure 5 as an example. Assume that there is an ODU2 link between node A and B, where node A only supports the 2.5 Gbps TS while node B supports the 1.25 Gbps TS. In this case, the TS#i and TS#i+4 (where i<=4) of node B are combined together. When creating an ODU1 service in this ODU2 link, node B reserves the TS#i and TS#i+4 with the granularity of 1.25 Gbps. But in the label sent from B to A, it is indicated that the TS#i with the granularity of 2.5 Gbps is reserved.
In the opposite direction, when receiving a label from node A indicating that the TS#i with the granularity of 2.5 Gbps is reserved, node B will reserve the TS#i and TS#i+4 with the granularity of 1.25 Gbps in its data plane.
Security Considerations
The use of control-plane protocols for signaling, routing, and path computation opens an OTN to security threats through attacks on those protocols. However, this is not greater than the risks presented by the existing OTN control plane as defined by RFC4203 and RFC4328. Meanwhile, the Data Communication Network (DCN) for OTN GMPLS control-plane protocols is likely to be in the in-fiber overhead, which, together with access lists at the network edges, provides a significant security feature. For further details of specific security measures, refer to the documents that define the protocols
(RFC3473, RFC4203, RFC5307, RFC4204, and RFC5440). RFC5920 provides an overview of security vulnerabilities and protection mechanisms for the GMPLS control plane.
Acknowledgments
We would like to thank Maarten Vissers and Lou Berger for their reviews and useful comments.
Contributors
Jianrui Han Huawei Technologies Co., Ltd. F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R. China Phone: +86-755-28972913 EMail: [email protected]
Malcolm Betts EMail: [email protected]
Pietro Grandi Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate (Milano) Italy Phone: +39 039 6864930 EMail: [email protected]
Eve Varma Alcatel-Lucent 1A-261, 600-700 Mountain Av PO Box 636 Murray Hill, NJ 07974-0636 USA EMail: [email protected]
10. References
10.1. Normative References
[G709-2012] ITU-T, "Interface for the Optical Transport Network
(OTN)", G.709/Y.1331 Recommendation, February 2012.
RFC3209 Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, December 2001.
RFC3471 Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003.
RFC3473 Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003.
RFC4201 Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
in MPLS Traffic Engineering (TE)", RFC 4201, October 2005.
RFC4202 Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005.
RFC4203 Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005.
RFC4204 Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005.
RFC4206 Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
RFC4328 Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006.
RFC5307 Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, October 2008.
RFC5440 Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
Computation Element (PCE) Communication Protocol (PCEP)", RFC 5440, March 2009.
RFC6001 Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 6001, October 2010.
RFC6107 Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for
Dynamically Signaled Hierarchical Label Switched Paths", RFC 6107, February 2011.
RFC6344 Bernstein, G., Ed., Caviglia, D., Rabbat, R., and H. van
Helvoort, "Operating Virtual Concatenation (VCAT) and the Link Capacity Adjustment Scheme (LCAS) with Generalized Multi-Protocol Label Switching (GMPLS)", RFC 6344, August 2011.
10.2. Informative References
[G798] ITU-T, "Characteristics of optical transport network
hierarchy equipment functional blocks", G.798 Recommendation, December 2012.
[G872-2001] ITU-T, "Architecture of optical transport networks",
G.872 Recommendation, November 2001.
[G872-2012] ITU-T, "Architecture of optical transport networks",
G.872 Recommendation, October 2012.
[G7041] ITU-T, "Generic framing procedure", G.7041/Y.1303, April
2011.
[G7042] ITU-T, "Link capacity adjustment scheme (LCAS) for
virtual concatenated signals", G.7042/Y.1305, March 2006.
[G7044] ITU-T, "Hitless adjustment of ODUflex (HAO)",
G.7044/Y.1347, October 2011.
RFC3945 Mannie, E., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Architecture", RFC 3945, October 2004.
RFC4655 Farrel, A., Vasseur, J.-P., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", RFC 4655, August 2006.
RFC6163 Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku,
"Framework for GMPLS and Path Computation Element (PCE) Control of Wavelength Switched Optical Networks (WSONs)", RFC 6163, April 2011.
RFC5920 Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010.
RFC7025 Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.
Margaria, "Requirements for GMPLS Applications of PCE", RFC 7025, September 2013.
[TDM-OAM] Kern, A., and A. Takacs, "GMPLS RSVP-TE Extensions for
SONET/SDH and OTN OAM Configuration", Work in Progress, November 2013.
Authors' Addresses
Fatai Zhang (editor) Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R. China Phone: +86-755-28972912 EMail: [email protected]
Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R. China Phone: +86-755-28973237 EMail: [email protected]
Han Li China Mobile Communications Corporation 53 A Xibianmennei Ave. Xuanwu District Beijing 100053 P.R. China Phone: +86-10-66006688 EMail: [email protected]
Sergio Belotti Alcatel-Lucent Optics CTO Via Trento 30 20059 Vimercate (Milano) Italy Phone: +39 039 6863033 EMail: [email protected]
Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy EMail: [email protected]