summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7062.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7062.txt')
-rw-r--r--doc/rfc/rfc7062.txt1459
1 files changed, 1459 insertions, 0 deletions
diff --git a/doc/rfc/rfc7062.txt b/doc/rfc/rfc7062.txt
new file mode 100644
index 0000000..47d0d13
--- /dev/null
+++ b/doc/rfc/rfc7062.txt
@@ -0,0 +1,1459 @@
+
+
+
+
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Informational [Page 1]
+
+RFC 7062 OTN Framework November 2013
+
+
+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.
+
+Table of Contents
+
+ 1. Introduction ....................................................3
+ 2. Terminology .....................................................3
+ 3. G.709 Optical Transport Network .................................4
+ 3.1. OTN Layer Network ..........................................5
+ 3.1.1. Client Signal Mapping ...............................6
+ 3.1.2. Multiplexing ODUj onto Links ........................7
+ 3.1.2.1. Structure of MSI Information ...............9
+ 4. Connection Management in OTN ...................................10
+ 4.1. Connection Management of the ODU ..........................11
+ 5. GMPLS/PCE Implications .........................................13
+ 5.1. Implications for Label Switched Path (LSP) Hierarchy ......13
+ 5.2. Implications for GMPLS Signaling ..........................14
+ 5.3. Implications for GMPLS Routing ............................16
+ 5.4. Implications for Link Management Protocol .................18
+ 5.5. Implications for Control-Plane Backward Compatibility .....19
+ 5.6. Implications for Path Computation Elements ................20
+ 5.7. Implications for Management of GMPLS Networks .............20
+ 6. Data-Plane Backward Compatibility Considerations ...............21
+ 7. Security Considerations ........................................21
+ 8. Acknowledgments ................................................22
+ 9. Contributors ...................................................22
+ 10. References ....................................................23
+ 10.1. Normative References .....................................23
+ 10.2. Informative References ...................................24
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Informational [Page 2]
+
+RFC 7062 OTN Framework November 2013
+
+
+1. 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.
+
+2. Terminology
+
+ OTN: Optical Transport Network
+
+ OPU: Optical Channel Payload Unit
+
+ ODU: Optical Channel Data Unit
+
+
+
+Zhang, et al. Informational [Page 3]
+
+RFC 7062 OTN Framework November 2013
+
+
+ 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.
+
+3. 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].
+
+
+
+
+
+
+
+
+
+Zhang, et al. Informational [Page 4]
+
+RFC 7062 OTN Framework November 2013
+
+
+3.1. 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Informational [Page 5]
+
+RFC 7062 OTN Framework November 2013
+
+
+3.1.1. 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).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Informational [Page 6]
+
+RFC 7062 OTN Framework November 2013
+
+
+ +-----------------------+-----------------------------------+
+ | 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].
+
+3.1.2. 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.
+
+
+
+
+
+
+
+Zhang, et al. Informational [Page 7]
+
+RFC 7062 OTN Framework November 2013
+
+
+ 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
+
+
+
+
+
+
+Zhang, et al. Informational [Page 8]
+
+RFC 7062 OTN Framework November 2013
+
+
+ - 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].
+
+3.1.2.1. 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.
+
+
+
+
+
+
+Zhang, et al. Informational [Page 9]
+
+RFC 7062 OTN Framework November 2013
+
+
+ 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.
+
+4. 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.
+
+
+
+
+
+
+
+Zhang, et al. Informational [Page 10]
+
+RFC 7062 OTN Framework November 2013
+
+
+4.1. 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
+
+
+
+
+Zhang, et al. Informational [Page 11]
+
+RFC 7062 OTN Framework November 2013
+
+
+ [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
+
+
+
+
+
+
+
+
+Zhang, et al. Informational [Page 12]
+
+RFC 7062 OTN Framework November 2013
+
+
+ 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.
+
+5. 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.
+
+5.1. 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.
+
+
+
+Zhang, et al. Informational [Page 13]
+
+RFC 7062 OTN Framework November 2013
+
+
+ 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).
+
+5.2. 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.
+
+
+
+Zhang, et al. Informational [Page 14]
+
+RFC 7062 OTN Framework November 2013
+
+
+ - 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.
+
+
+
+
+
+
+
+Zhang, et al. Informational [Page 15]
+
+RFC 7062 OTN Framework November 2013
+
+
+ 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.
+
+5.3. 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
+
+
+
+
+Zhang, et al. Informational [Page 16]
+
+RFC 7062 OTN Framework November 2013
+
+
+ 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.
+
+
+
+
+Zhang, et al. Informational [Page 17]
+
+RFC 7062 OTN Framework November 2013
+
+
+ - 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.
+
+5.4. 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.
+
+
+
+
+
+
+
+
+Zhang, et al. Informational [Page 18]
+
+RFC 7062 OTN Framework November 2013
+
+
+ - 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.
+
+5.5. 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].
+
+
+
+Zhang, et al. Informational [Page 19]
+
+RFC 7062 OTN Framework November 2013
+
+
+ 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.
+
+5.6. 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.
+
+5.7. 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]).
+
+
+
+
+
+
+
+Zhang, et al. Informational [Page 20]
+
+RFC 7062 OTN Framework November 2013
+
+
+6. 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.
+
+7. 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
+
+
+
+
+Zhang, et al. Informational [Page 21]
+
+RFC 7062 OTN Framework November 2013
+
+
+ ([RFC3473], [RFC4203], [RFC5307], [RFC4204], and [RFC5440]).
+ [RFC5920] provides an overview of security vulnerabilities and
+ protection mechanisms for the GMPLS control plane.
+
+8. Acknowledgments
+
+ We would like to thank Maarten Vissers and Lou Berger for their
+ reviews and useful comments.
+
+9. 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: hanjianrui@huawei.com
+
+
+ Malcolm Betts
+ EMail: malcolm.betts@rogers.com
+
+
+ Pietro Grandi
+ Alcatel-Lucent
+ Optics CTO
+ Via Trento 30
+ 20059 Vimercate (Milano)
+ Italy
+ Phone: +39 039 6864930
+ EMail: pietro_vittorio.grandi@alcatel-lucent.it
+
+
+ Eve Varma
+ Alcatel-Lucent
+ 1A-261, 600-700 Mountain Av
+ PO Box 636
+ Murray Hill, NJ 07974-0636
+ USA
+ EMail: eve.varma@alcatel-lucent.com
+
+
+
+
+
+
+
+
+
+Zhang, et al. Informational [Page 22]
+
+RFC 7062 OTN Framework November 2013
+
+
+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.
+
+
+
+
+Zhang, et al. Informational [Page 23]
+
+RFC 7062 OTN Framework November 2013
+
+
+ [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.
+
+
+
+
+
+Zhang, et al. Informational [Page 24]
+
+RFC 7062 OTN Framework November 2013
+
+
+ [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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zhang, et al. Informational [Page 25]
+
+RFC 7062 OTN Framework 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: zhangfatai@huawei.com
+
+
+ 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: huawei.danli@huawei.com
+
+
+ Han Li
+ China Mobile Communications Corporation
+ 53 A Xibianmennei Ave. Xuanwu District
+ Beijing 100053
+ P.R. China
+ Phone: +86-10-66006688
+ EMail: lihan@chinamobile.com
+
+
+ Sergio Belotti
+ Alcatel-Lucent
+ Optics CTO
+ Via Trento 30
+ 20059 Vimercate (Milano)
+ Italy
+ Phone: +39 039 6863033
+ EMail: sergio.belotti@alcatel-lucent.it
+
+
+ Daniele Ceccarelli
+ Ericsson
+ Via A. Negrone 1/A
+ Genova - Sestri Ponente
+ Italy
+ EMail: daniele.ceccarelli@ericsson.com
+
+
+
+
+Zhang, et al. Informational [Page 26]
+