draft-ietf-ccamp-gmpls-g709-framework-15.txt   rfc7062.txt 
Network Working Group Fatai Zhang, Ed.
Internet Draft Dan Li Internet Engineering Task Force (IETF) F. Zhang, Ed.
Request for Comments: 7062 D. Li
Category: Informational Huawei Category: Informational Huawei
Han Li ISSN: 2070-1721 H. Li
CMCC CMCC
S.Belotti S. Belotti
Alcatel-Lucent Alcatel-Lucent
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
Expires: March 22, 2014 September 22, 2013 November 2013
Framework for GMPLS and PCE Control of Framework for GMPLS and PCE Control of
G.709 Optical Transport Networks G.709 Optical Transport Networks
draft-ietf-ccamp-gmpls-g709-framework-15.txt Abstract
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This document provides a framework to allow the development of
the provisions of BCP 78 and BCP 79. 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.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months This document is not an Internet Standards Track specification; it is
and may be updated, replaced, or obsoleted by other documents at any published for informational purposes.
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/ietf/1id-abstracts.txt. (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.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html. and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7062.
This Internet-Draft will expire on March 22, 2014. Copyright Notice
Abstract Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document provides a framework to allow the development of This document is subject to BCP 78 and the IETF Trust's Legal
protocol extensions to support Generalized Multi-Protocol Label Provisions Relating to IETF Documents
Switching (GMPLS) and Path Computation Element (PCE) control of (http://trustee.ietf.org/license-info) in effect on the date of
Optical Transport Networks (OTN) as specified in ITU-T Recommendation publication of this document. Please review these documents
G.709 as published in 2012. 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 Table of Contents
1. Introduction ................................................. 2 1. Introduction ....................................................3
2. Terminology .................................................. 3 2. Terminology .....................................................3
3. G.709 Optical Transport Network .............................. 4 3. G.709 Optical Transport Network .................................4
3.1. OTN Layer Network ....................................... 4 3.1. OTN Layer Network ..........................................5
3.1.1. Client signal mapping .............................. 5 3.1.1. Client Signal Mapping ...............................6
3.1.2. Multiplexing ODUj onto Links ....................... 7 3.1.2. Multiplexing ODUj onto Links ........................7
3.1.2.1. Structure of MSI information .................. 8 3.1.2.1. Structure of MSI Information ...............9
4. Connection management in OTN ................................. 9 4. Connection Management in OTN ...................................10
4.1. Connection management of the ODU ........................ 10 4.1. Connection Management of the ODU ..........................11
5. GMPLS/PCE Implications ...................................... 12 5. GMPLS/PCE Implications .........................................13
5.1. Implications for Label Switch Path (LSP) Hierarchy ...... 12 5.1. Implications for Label Switched Path (LSP) Hierarchy ......13
5.2. Implications for GMPLS Signaling ........................ 13 5.2. Implications for GMPLS Signaling ..........................14
5.3. Implications for GMPLS Routing .......................... 15 5.3. Implications for GMPLS Routing ............................16
5.4. Implications for Link Management Protocol ............... 17 5.4. Implications for Link Management Protocol .................18
5.5. Implications for Control Plane Backward Compatibility ... 18 5.5. Implications for Control-Plane Backward Compatibility .....19
5.6. Implications for Path Computation Elements .............. 19 5.6. Implications for Path Computation Elements ................20
5.7. Implications for Management of GMPLS Networks ........... 20 5.7. Implications for Management of GMPLS Networks .............20
6. Data Plane Backward Compatibility Considerations ............. 20 6. Data-Plane Backward Compatibility Considerations ...............21
7. Security Considerations ..................................... 21 7. Security Considerations ........................................21
8. IANA Considerations .......................................... 21 8. Acknowledgments ................................................22
9. Acknowledgments .............................................. 21 9. Contributors ...................................................22
10. References .................................................. 21 10. References ....................................................23
10.1. Normative References ................................... 21 10.1. Normative References .....................................23
10.2. Informative References ................................ 23 10.2. Informative References ...................................24
11. Authors' Addresses .......................................... 24
12. Contributors ................................................ 25
1. Introduction 1. Introduction
Optical Transport Networks (OTN) has become a mainstream layer 1 Optical Transport Networks (OTNs) have become a mainstream layer 1
technology for the transport network. Operators want to introduce technology for the transport network. Operators want to introduce
control plane capabilities based on GMPLS to OTN, to realize the control-plane capabilities based on GMPLS to OTN to realize the
benefits associated with a high-function control plane (e.g., benefits associated with a high-function control plane (e.g.,
improved network resiliency, resource usage efficiency, etc.). improved network resiliency, resource usage efficiency, etc.).
GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass time GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass Time
division multiplexing (TDM) networks (e.g., Synchronous Optical Division Multiplexing (TDM) networks (e.g., Synchronous Optical
NETwork (SONET)/ Synchronous Digital Hierarchy (SDH), Plesiochronous NETwork (SONET) / Synchronous Digital Hierarchy (SDH), Plesiochronous
Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching
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
specification, [G709-2012], includes new features, for example, specification, [G709-2012], includes new features, for example,
various multiplexing structures, two types of Tributary Slots (TSs) various multiplexing structures, two types of Tributary Slots (TSs)
(i.e., 1.25Gbps and 2.5Gbps), and extension of the Optical channel (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. Data Unit-j (ODUj) definition to include the ODUflex function.
This document reviews relevant aspects of OTN technology evolution This document reviews relevant aspects of OTN technology evolution
that affect the GMPLS control plane protocols and examines why and that affect the GMPLS control-plane protocols and examines why and
how to update the mechanisms described in [RFC4328]. This document how to update the mechanisms described in [RFC4328]. This document
additionally provides a framework for the GMPLS control of OTN and additionally provides a framework for GMPLS control of OTN and
includes a discussion of the implication 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 as For the purposes of the control plane, the OTN can be considered to
being comprised of ODU and wavelength (Optical Channel (OCh)) layers. be comprised of ODU and wavelength (Optical Channel (OCh)) layers.
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.
2. Terminology 2. Terminology
OTN: Optical Transport Network OTN: Optical Transport Network
OPU: Optical channel Payload Unit OPU: Optical Channel Payload Unit
ODU: Optical channel Data Unit
OTU: Optical channel Transport Unit ODU: Optical Channel Data Unit
OTU: Optical Channel Transport Unit
OMS: Optical multiplex section OMS: Optical Multiplex Section
MSI: Multiplex Structure Identifier MSI: Multiplex Structure Identifier
TPN: Tributary Port Number TPN: Tributary Port Number
LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4,
flex.) represents the container transporting a client of the OTN that 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 is either directly mapped into an OTUk (k = j) or multiplexed into a
server HO ODUk (k > j) container. server HO ODUk (k > j) container.
HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, 4.) 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 represents the entity transporting a multiplex of LO ODUj tributary
signals in its OPUk area. signals in its OPUk area.
ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a
bit rate tolerance of +/-100 ppm (parts per million). bit rate tolerance of +/-100 ppm (parts per million).
In general, throughout this document, 'ODUj' is used to refer to ODU In general, throughout this document, "ODUj" is used to refer to ODU
entities acting as LO ODU, and 'ODUk' is used to refer to ODU entities acting as an LO ODU, and "ODUk" is used to refer to ODU
entities being used as HO ODU. entities being used as an HO ODU.
3. G.709 Optical Transport Network 3. G.709 Optical Transport Network
This section provides an informative overview of those aspects of the This section provides an informative overview of the aspects of the
OTN impacting control plane protocols. This overview is based on the OTN impacting control-plane protocols. This overview is based on the
ITU-T Recommendations that contain the normative definition of the ITU-T Recommendations that contain the normative definition of the
OTN. Technical details regarding OTN architecture and interfaces are OTN. Technical details regarding OTN architecture and interfaces are
provided in the relevant ITU-T Recommendations. provided in the relevant ITU-T Recommendations.
Specifically, [G872-2012] describes the functional architecture of Specifically, [G872-2012] describes the functional architecture of
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] defines network survivability. The legacy OTN referenced by [RFC4328]
the interfaces of the optical transport network to be used within and defines the interfaces of the optical transport network to be used
between subnetworks of the optical network. With the evolution and within and between subnetworks of the optical network. With the
deployment of OTN technology many new features have been specified in evolution and deployment of OTN technology, many new features have
ITU-T recommendations, including for example, new ODU0, ODU2e, ODU4 been specified in ITU-T recommendations, including, for example, new
and ODUflex containers as described in [G709-2012]. ODU0, ODU2e, ODU4, and ODUflex containers as described in
[G709-2012].
3.1. OTN Layer Network 3.1. OTN Layer Network
The simplified signal hierarchy of OTN is shown in Figure 1, which The simplified signal hierarchy of OTN is shown in Figure 1, which
illustrates the layers that are of interest to the control plane. illustrates the layers that are of interest to the control plane.
Other layers below OCh (e.g. Optical Transmission Section (OTS)) are Other layers below OCh (e.g., Optical Transmission Section (OTS)) are
not included in this Figure. The full signal hierarchy is provided in not included in this figure. The full signal hierarchy is provided
[G709-2012]. in [G709-2012].
Client signal Client signal
| |
ODUj ODUj
| |
OTU/OCh OTU/OCh
OMS OMS
Figure 1 - Basic OTN signal hierarchy Figure 1: Basic OTN Signal Hierarchy
Client signals are mapped into ODUj containers. These ODUj containers Client signals are mapped into ODUj containers. These ODUj
are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are containers are multiplexed onto the OTU/OCh. The individual OTU/OCh
combined in the OMS using Wavelength Division Multiplexing (WDM), and signals are combined in the OMS using Wavelength Division
this aggregated signal provides the link between the nodes. Multiplexing (WDM), and this aggregated signal provides the link
between the nodes.
3.1.1. Client signal mapping 3.1.1. Client Signal Mapping
The client signals are mapped into a LO ODUj. The current values of j The client signals are mapped into an LO ODUj. The current values of
defined in [G709-2012] are: 0, 1, 2, 2e, 3, 4, Flex. The approximate j defined in [G709-2012] are: 0, 1, 2, 2e, 3, 4, and flex. The
bit rates of these signals are defined in [G709-2012] and are approximate bit rates of these signals are defined in [G709-2012] and
reproduced in Tables 1 and 2. are reproduced in Tables 1 and 2.
Table 1 - ODU types and bit rates
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| ODU Type | ODU nominal bit rate | | ODU Type | ODU nominal bit rate |
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| ODU0 | 1,244,160 Kbps | | ODU0 | 1,244,160 Kbps |
| ODU1 | 239/238 x 2,488,320 Kbps | | ODU1 | 239/238 x 2,488,320 Kbps |
| ODU2 | 239/237 x 9,953,280 Kbps | | ODU2 | 239/237 x 9,953,280 Kbps |
| ODU3 | 239/236 x 39,813,120 Kbps | | ODU3 | 239/236 x 39,813,120 Kbps |
| ODU4 | 239/227 x 99,532,800 Kbps | | ODU4 | 239/227 x 99,532,800 Kbps |
| ODU2e | 239/237 x 10,312,500 Kbps | | ODU2e | 239/237 x 10,312,500 Kbps |
| | | | | |
| ODUflex for | | | ODUflex for | |
|Constant Bit Rate (CBR)| 239/238 x client signal bit rate | |Constant Bit Rate (CBR)| 239/238 x client signal bit rate |
| Client signals | | | Client signals | |
| | | | | |
| ODUflex for Generic | | | ODUflex for Generic | |
| Framing Procedure | Configured bit rate | | Framing Procedure | Configured bit rate |
| - Framed (GFP-F) | | | - Framed (GFP-F) | |
| Mapped client signal | | | Mapped client signal | |
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
NOTE - The nominal ODUk rates are approximately: 2,498,775.126 Kbps
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), (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).
Table 2 - ODU types and tolerance
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| ODU Type | ODU bit-rate tolerance | | ODU Type | ODU bit rate tolerance |
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| ODU0 | +/-20 ppm | | ODU0 | +/-20 ppm |
| ODU1 | +/-20 ppm | | ODU1 | +/-20 ppm |
| ODU2 | +/-20 ppm | | ODU2 | +/-20 ppm |
| ODU3 | +/-20 ppm | | ODU3 | +/-20 ppm |
| ODU4 | +/-20 ppm | | ODU4 | +/-20 ppm |
| ODU2e | +/-100 ppm | | ODU2e | +/-100 ppm |
| | | | | |
| ODUflex for CBR | | | ODUflex for CBR | |
| Client signals | +/-100 ppm | | Client signals | +/-100 ppm |
| | | | | |
| ODUflex for GFP-F | | | ODUflex for GFP-F | |
| Mapped client signal | +/-100 ppm | | Mapped client signal | +/-100 ppm |
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
Table 2: ODU Types and Tolerance
One of two options is for mapping client signals into ODUflex One of two options is for mapping client signals into ODUflex
depending on the client signal type: depending on the client signal type:
- Circuit clients are proportionally wrapped. Thus the bit rate is - Circuit clients are proportionally wrapped. Thus, the bit rate is
defined by the client signal and the tolerance is fixed to +/-100 defined by the client signal, and the tolerance is fixed to +/-100
ppm. ppm.
- Packet clients are mapped using the Generic Framing Procedure - Packet clients are mapped using the Generic Framing Procedure
(GFP). [G709-2012] recommends that the ODUflex(GFP) will fill an (GFP). [G709-2012] recommends that the ODUflex(GFP) will fill an
integral number of tributary slots of the smallest HO ODUk path integral number of tributary slots of the smallest HO ODUk path
over which the ODUflex(GFP) may be carried, and the tolerance over which the ODUflex(GFP) may be carried, and the tolerance
should be +/-100 ppm. should be +/-100 ppm.
Note that additional information on G.709 client mapping can be found Note that additional information on G.709 client mapping can be found
in [G7041]. in [G7041].
3.1.2. Multiplexing ODUj onto Links 3.1.2. Multiplexing ODUj onto Links
The links between the switching nodes are provided by one or more The links between the switching nodes are provided by one or more
wavelengths. Each wavelength carries one OCh, which carries one OTU, wavelengths. Each wavelength carries one OCh, which carries one OTU,
which carries one ODU. Since all of these signals have a 1:1:1 which carries one ODU. Since all of these signals have a 1:1:1
relationship, we only refer to the OTU for clarity. The ODUjs are relationship, we only refer to the OTU for clarity. The ODUjs are
mapped into the TSs (Tributary Slots) of the OPUk. Note that in the 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 case where j=k, the ODUj is mapped into the OTU/OCh without
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.5Gbps. [G709-2012] added an single TS granularity, nominally 2.5 Gbps. [G709-2012] added an
additional TS granularity, nominally 1.25Gbps. The number and type of additional TS granularity, nominally 1.25 Gbps. The number and type
TSs provided by each of the currently identified OTUk is provided of TS provided by each of the currently identified OTUk are provided
below: below:
Tributary Slot Granularity Tributary Slot Granularity
2.5Gbps 1.25Gbps Nominal Bit rate 2.5 Gbps 1.25 Gbps Nominal Bit Rate
OTU1 1 2 2.5Gbps OTU1 1 2 2.5 Gbps
OTU2 4 8 10Gbps OTU2 4 8 10 Gbps
OTU3 16 32 40Gbps OTU3 16 32 40 Gbps
OTU4 -- 80 100Gbps OTU4 -- 80 100 Gbps
To maintain backwards compatibility while providing the ability to To maintain backward compatibility while providing the ability to
interconnect nodes that support 1.25Gbps TS at one end of a link and interconnect nodes that support a 1.25 Gbps TS at one end of a link
2.5Gbps TS at the other, [G709-2012] requires 'new' equipment fall and a 2.5 Gbps TS at the other, [G709-2012] requires 'new' equipment
back to the use of a 2.5Gbps TS when connected to legacy equipment. to fall back to the use of a 2.5 Gbps TS when connected to legacy
This information is carried in band by the payload type. 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. 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 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 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 only 8 in an OTU4. Examples of the number of TSs used for various
cases are provided below (Referring to Table 7-9 of [G709-2012]): cases are provided below (referring to Tables 7-9 of [G709-2012]):
- ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS - ODU0 into ODU1, ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS
granularity granularity
o ODU0 occupies 1 of the 2, 8, 32 or 80 TSs for ODU1, ODU2, ODU3 o ODU0 occupies 1 of the 2, 8, 32, or 80 TSs for ODU1, ODU2,
or ODU4 ODU3, or ODU4
- ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS - ODU1 into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS
granularity granularity
o ODU1 occupies 2 of the 8, 32 or 80 TSs for ODU2, ODU3 or ODU4 o ODU1 occupies 2 of the 8, 32, or 80 TSs for ODU2, ODU3, or ODU4
- ODU1 into ODU2, ODU3 multiplexing with 2.5Gbps TS granularity - 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 o ODU1 occupies 1 of the 4 or 16 TSs for ODU2 or ODU3
- ODU2 into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity - 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 o ODU2 occupies 8 of the 32 or 80 TSs for ODU3 or ODU4
- ODU2 into ODU3 multiplexing with 2.5Gbps TS granularity - ODU2 into ODU3 multiplexing with 2.5 Gbps TS granularity
o ODU2 occupies 4 of the 16 TSs for ODU3 o ODU2 occupies 4 of the 16 TSs for ODU3
- ODU3 into ODU4 multiplexing with 1.25Gbps 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.25Gbps TS - ODUflex into ODU2, ODU3, or ODU4 multiplexing with 1.25 Gbps TS
granularity granularity
o ODUflex occupies n of the 8, 32 or 80 TSs for ODU2, ODU3 or o ODUflex occupies n of the 8, 32, or 80 TSs for ODU2, ODU3, or
ODU4 (n <= Total TS number of ODUk) ODU4 (n <= Total TS number of ODUk)
- ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity - 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 o ODU2e occupies 9 of the 32 TSs for ODU3 or 8 of the 80 TSs for
ODU4 ODU4
In general the mapping of an ODUj (including ODUflex) into a specific In general, the mapping of an ODUj (including ODUflex) into a
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, 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].
3.1.2.1. Structure of MSI information 3.1.2.1. Structure of MSI Information
When multiplexing an ODUj into a HO ODUk (k>j), G.709 specifies the 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 information that has to be transported in-band in order to allow for
correct demultiplexing. This information, known as MSI, is correct demultiplexing. This information, known as MSI, is
transported in the OPUk overhead and is local to each link. In case transported in the OPUk overhead and is local to each link. In case
of bidirectional paths the association between TPN and TS must be the of bidirectional paths, the association between the TPN and TS must
same in both directions. be the same in both directions.
The MSI information is organized as a set of entries, with one entry 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: for each HO ODUj TS. The information carried by each entry is:
- Payload Type: the type of the transported payload. - Payload Type: the type of the transported payload.
- TPN: the port number of the ODUj transported by the HO ODUk. The - 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 TPN is the same for all the TSs assigned to the transport of the
same ODUj instance. same ODUj instance.
For example, an ODU2 carried by a HO ODU3 is described by 4 entries For example, an ODU2 carried by an HO ODU3 is described by 4 entries
in the OPU3 overhead when the TS granularity is 2.5Gbps, and by 8 in the OPU3 overhead when the TS granularity is 2.5 Gbps, and by 8
entries when the TS granularity is 1.25Gbps. entries when the TS granularity is 1.25 Gbps.
On each node and on every link, two MSI values have to be provisioned On each node and on every link, two MSI values have to be provisioned
(Referring to [G798-V4]): (referring to [G798]):
- The Transmitted MSI (TxMSI) information inserted in OPU (e.g., - The Transmitted MSI (TxMSI) information inserted in OPU (e.g.,
OPU3) overhead by the source of the HO ODUk trail. OPU3) overhead by the source of the HO ODUk trail.
- The expected MSI (ExMSI) information that is used to check the - The Expected MSI (ExMSI) information that is used to check the
accepted MSI (AcMSI) information. The AcMSI information is the MSI Accepted MSI (AcMSI) information. The AcMSI information is the
valued received in-band, after a three-frame integration. MSI valued received in-band, after a three-frame integration.
As described in [G798-V4], the sink of the HO ODU trail checks the As described in [G798], the sink of the HO ODU trail checks the
complete content of the AcMSI information against the ExMSI. If 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 AcMSI is different from the ExMSI, then the traffic is dropped, and a
payload mismatch alarm is generated. payload mismatch alarm is generated.
Provisioning of TPN can be performed either by network management Provisioning of TPN can be performed by either a network management
system or control plane. In the last case, control plane is also system or control plane. In the last case, the control plane is also
responsible for negotiating the provisioned values on a link by link responsible for negotiating the provisioned values on a link-by-link
base. basis.
4. Connection management in OTN 4. Connection Management in OTN
OTN-based connection management is concerned with controlling the OTN-based connection management is concerned with controlling the
connectivity of ODU paths and OCh. This document focuses on the connectivity of ODU paths and OCh. This document focuses on the
connection management of ODU paths. The management of OCh paths is connection management of ODU paths. The management of OCh paths is
described in [RFC6163]. described in [RFC6163].
While [G872-2001] considered the ODU as a set of layers in the same While [G872-2001] considered the ODU to be a set of layers in the
way as SDH has been modeled, recent ITU-T OTN architecture progress same way as SDH has been modeled, recent ITU-T OTN architecture
[G872-2012] includes an agreement to model the ODU as a single layer progress [G872-2012] includes an agreement to model the ODU as a
network with the bit rate as a parameter of links and connections. single-layer network with the bit rate as a parameter of links and
This allows the links and nodes to be viewed in a single topology as connections. This allows the links and nodes to be viewed in a
a common set of resources that are available to provide ODUj single topology as a common set of resources that are available to
connections independent of the value of j. Note that when the bit provide ODUj connections independent of the value of j. Note that
rate of ODUj is less than the server bit rate, ODUj connections are when the bit rate of ODUj is less than the server bit rate, ODUj
supported by HO ODU (which has a one-to-one relationship with the connections are supported by HO ODU (which has a one-to-one
OTU). relationship with the OTU).
From an ITU-T perspective, the ODU connection topology is represented From an ITU-T perspective, the ODU connection topology is represented
by that of the OTU link layer, which has the same topology as that of by that of the OTU link layer, which has the same topology as that of
the OCh layer (independent of whether the OTU supports HO ODU, where the OCh layer (independent of whether the OTU supports an HO ODU,
multiplexing is utilized, or LO ODU in the case of direct mapping). 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 Thus, the OTU and OCh layers should be visible in a single
topological representation of the network, and from a logical topological representation of the network, and from a logical
perspective, the OTU and OCh may be considered as the same logical, perspective, the OTU and OCh may be considered as the same logical,
switchable entity. switchable entity.
Note that the OTU link layer topology may be provided via various Note that the OTU link-layer topology may be provided via various
infrastructure alternatives, including point-to-point optical infrastructure alternatives, including point-to-point optical
connections, 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.
4.1. Connection management of the ODU 4.1. Connection Management of the ODU
LO ODUj can be either mapped into the OTUk signal (j = k), or 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 multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is
mapped into an OCh. mapped into an OCh.
From the perspective of control plane, there are two kinds of network From the perspective of the control plane, there are two kinds of
topology to be considered. network topology to be considered.
(1) ODU layer (1) ODU layer
In this case, the ODU links are presented between adjacent OTN nodes, 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 as illustrated in Figure 2. In this layer, there are ODU links with
variety of TSs available, and nodes that are Optical Digital Cross a variety of TSs available, and nodes that are Optical Digital Cross
Connects (ODXCs). LO ODU connections can be setup based on the Connects (ODXCs). LO ODU connections can be set up based on the
network topology. network topology.
Link #5 +--+---+--+ Link #4 Link #5 +--+---+--+ Link #4
+--------------------------| |--------------------------+ +--------------------------| |--------------------------+
| | ODXC | | | | ODXC | |
| +---------+ | | +---------+ |
| Node E | | Node E |
| | | |
+-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++ +-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++
| |Link #1 | |Link #2 | |Link #3 | | | |Link #1 | |Link #2 | |Link #3 | |
| |--------| |--------| |--------| | | |--------| |--------| |--------| |
| ODXC | | ODXC | | ODXC | | ODXC | | ODXC | | ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
Node A Node B Node C Node D Node A Node B Node C Node D
Figure 2 - Example Topology for LO ODU connection management Figure 2: Example Topology for LO ODU Connection Management
If an ODUj connection is requested between Node C and Node E If an ODUj connection is requested between Node C and Node E,
routing/path computation must select a path that has the required routing/path computation must select a path that has the required
number of TS available and that offers the lowest cost. Signaling is number of TSs available and that offers the lowest cost. Signaling
then invoked to set up the path and to provide the information (e.g., is then invoked to set up the path and to provide the information
selected TSs) required by each transit node to allow the (e.g., selected TSs) required by each transit node to allow the
configuration of the ODUj to OTUk mapping (j = k) or multiplexing (j configuration of the ODUj-to-OTUk mapping (j = k) or multiplexing (j
< k), and demapping (j = k) or demultiplexing (j < k). < k) and demapping (j = k) or demultiplexing (j < k).
(2) ODU layer with OCh switching capability (2) ODU layer with OCh switching capability
In this case, the OTN nodes interconnect with wavelength switched In this case, the OTN nodes interconnect with wavelength switched
node (e.g., Reconfiguration Optical Add/Drop Multiplexer (ROADM), nodes (e.g., Reconfiguration Optical Add/Drop Multiplexer (ROADM) or
Optical Cross-Connect (OXC)) that are capable of OCh switching, which Optical Cross-Connect (OXC)) that are capable of OCh switching; this
is illustrated in Figure 3 and Figure 4. There are ODU layer and OCh is illustrated in Figures 3 and 4. There are the ODU layer and the
layer, so it is simply a Multi-Layer Networks (MLN) (see [RFC6001]). OCh layer, so it is simply a Multi-Layer Network (MLN) (see
OCh connections may be created on demand, which is described in
section 5.1. [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 In this case, an operator may choose to allow the underlying OCh
layer to be visible to the ODU routing/path computation process in 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 which case the topology would be as shown in Figure 4. In Figure 3,
below, instead, a cloud representing OCh capable switching nodes is however, a cloud representing OCh-capable switching nodes is
represented. In Figure 3, the operator choice is to hide the real OCh represented. In Figure 3, the operator choice is to hide the real
layer network topology. OCh-layer network topology.
Node E Node E
Link #5 +--------+ Link #4 Link #5 +--------+ Link #4
+------------------------| |------------------------+ +------------------------| |------------------------+
| ------ | | ------ |
| // \\ | | // \\ |
| || || | | || || |
| | OCh domain | | | | OCh domain | |
+-+-----+ +------ || || ------+ +-----+-+ +-+-----+ +------ || || ------+ +-----+-+
| | | \\ // | | | | | | \\ // | | |
| |Link #1 | -------- |Link #3 | | | |Link #1 | -------- |Link #3 | |
| +--------+ | | +--------+ + | +--------+ | | +--------+ +
| ODXC | | ODXC +--------+ ODXC | | ODXC | | ODXC | | ODXC +--------+ ODXC | | ODXC |
+-------+ +---------+Link #2 +---------+ +-------+ +-------+ +---------+Link #2 +---------+ +-------+
Node A Node B Node C Node D Node A Node B Node C Node D
Figure 3 - OCh Hidden Topology for LO ODU connection management Figure 3: OCh Hidden Topology for LO ODU Connection Management
Link #5 +---------+ Link #4 Link #5 +---------+ Link #4
+------------------------| |-----------------------+ +------------------------| |-----------------------+
| +----| ODXC |----+ | | +----| ODXC |----+ |
| +-++ +---------+ ++-+ | | +-++ +---------+ ++-+ |
| Node f | | Node E | | Node g | | Node f | | Node E | | Node g |
| +-++ ++-+ | | +-++ ++-+ |
| | +--+ | | | | +--+ | |
+-+-----+ +----+----+--| |--+-----+---+ +-----+-+ +-+-----+ +----+----+--| |--+-----+---+ +-----+-+
| |Link #1 | | +--+ | |Link #3 | | | |Link #1 | | +--+ | |Link #3 | |
| +--------+ | Node h | +--------+ | | +--------+ | Node h | +--------+ |
| ODXC | | ODXC +--------+ ODXC | | ODXC | | ODXC | | ODXC +--------+ ODXC | | ODXC |
+-------+ +---------+ 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 of previous figure is substituted by the real In Figure 4, the cloud in the previous figure is substituted by the
topology. The nodes f, g, h are nodes with OCh switching capability. real topology. The nodes f, g, and h are nodes with OCh switching
capability.
In the examples (i.e., Figure 3 and Figure 4), we have considered the In the examples (i.e., Figures 3 and 4), we have considered the case
case in which LO ODUj connections are supported by OCh connection, in which LO ODUj connections are supported by an OCh connection and
and the case in which the supporting underlying connection can be the case in which the supporting underlying connection can also be
also made by a combination of HO ODU/OCh connections. made by a combination of HO ODU/OCh connections.
In this case, the ODU routing/path selection process will request an 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. HO ODU/OCh connection between node C and node E from the OCh domain.
The connection will appear at ODU level as a Forwarding Adjacency, The connection will appear at the ODU level as a Forwarding
which will be used to create the ODU connection. Adjacency, which will be used to create the ODU connection.
5. GMPLS/PCE Implications 5. GMPLS/PCE Implications
The purpose of this section is to provide a set of requirements to be 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 evaluated for extensions of the current GMPLS protocol suite and the
PCE applications and protocols to encompass OTN enhancements and PCE applications and protocols to encompass OTN enhancements and
connection management. connection management.
5.1. Implications for Label Switch Path (LSP) Hierarchy 5.1. Implications for Label Switched Path (LSP) Hierarchy
The path computation for ODU connection request is based on the The path computation for an ODU connection request is based on the
topology of ODU layer. topology of the ODU layer.
The OTN path computation can be divided into two layers. One layer is The OTN path computation can be divided into two layers. One layer
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], etc. 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 Wavelength Switched Optical Network (WSON) [RFC6163]. the scope of the Wavelength Switched Optical Network (WSON)
Therefore, this document only considers ODU layer for ODU connection [RFC6163]. Therefore, this document only considers the ODU layer for
request. an ODU connection request.
LSP hierarchy can also be applied within the ODU layers. One of the The LSP hierarchy can also be applied within the ODU layers. One of
typical scenarios for ODU layer hierarchy is to maintain the typical scenarios for ODU layer hierarchy is to maintain
compatibility with introducing new [G709-2012] services (e.g., ODU0, compatibility with introducing new [G709-2012] services (e.g., ODU0
ODUflex) into a legacy network configuration (i.e., the legacy OTN and ODUflex) into a legacy network configuration (i.e., the legacy
referenced by [RFC4328]). In this scenario, it may be needed to OTN referenced by [RFC4328]). In this scenario, it may be necessary
consider introducing hierarchical multiplexing capability in specific to consider introducing hierarchical multiplexing capability in
network transition scenarios. One method for enabling multiplexing specific network transition scenarios. One method for enabling
hierarchy is by introducing dedicated boards in a few specific places multiplexing hierarchy is by introducing dedicated boards in a few
in the network and tunneling these new services through the legacy specific places in the network and tunneling these new services
containers (ODU1, ODU2, ODU3), thus postponing the need to upgrade through the legacy containers (ODU1, ODU2, ODU3), thus postponing the
every network element to [G709-2012] capabilities. need to upgrade every network element to [G709-2012] capabilities.
In such case, one ODUj connection can be nested into another ODUk In such cases, one ODUj connection can be nested into another ODUk
(j<k) connection, which forms the LSP hierarchy in ODU layer. The (j<k) connection, which forms the LSP hierarchy in the ODU layer.
creation of the outer ODUk connection can be triggered via network The creation of the outer ODUk connection can be triggered via
planning, or by the signaling of the inner ODUj connection. For the network planning or by the signaling of the inner ODUj connection.
former case, the outer ODUk connection can be created in advance For the former case, the outer ODUk connection can be created in
based on network planning. For the latter case, the multi-layer advance based on network planning. For the latter case, the multi-
network signaling described in [RFC4206], [RFC6107] and [RFC6001] layer network signaling described in [RFC4206], [RFC6107], and
(including related modifications, if needed) are relevant to create [RFC6001] (including related modifications, if needed) is relevant to
the ODU connections with multiplexing hierarchy. In both cases, the create the ODU connections with multiplexing hierarchy. In both
outer ODUk connection is advertised as a Forwarding Adjacency (FA). cases, the outer ODUk connection is advertised as a Forwarding
Adjacency (FA).
5.2. Implications for GMPLS Signaling 5.2. Implications for GMPLS Signaling
The signaling function and RSVP-TE extensions are described in The signaling function and RSVP-TE extensions are described in
[RFC3471] and [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.
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]. The following signaling parameters are also defined in [RFC4328]. In addition, the following
aspects should be considered additionally since [RFC4328] was signaling aspects not included in [RFC4328] should be considered:
published:
- Support for specifying the new signal types and the related - Support for specifying new signal types and related traffic
traffic information information
The traffic parameters should be extended in signaling message to The traffic parameters should be extended in a signaling message
support the new ODUj including: to support the new ODUj, including:
- ODU0 - ODU0
- ODU2e - ODU2e
- ODU4 - ODU4
- ODUflex - ODUflex
For ODUflex signal type, its bit rate must be carried additionally For the ODUflex signal type, the bit rate must be carried
in the Traffic Parameter to setup an ODUflex connection. additionally in the traffic parameter to set up an ODUflex
connection.
For other ODU signal types, their bit rates and tolerances are For other ODU signal types, the bit rates and tolerances are fixed
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
The signaling protocol should be able to identify the TS The signaling protocol should be able to identify the TS
granularity (i.e., the 2.5Gbps TS granularity and the new 1.25Gbps granularity (i.e., the 2.5 Gbps TS granularity and the new 1.25
TS granularity) to be used for establishing an Hierarchical LSP Gbps TS granularity) to be used for establishing a Hierarchical
which will be used to carry service LSP(s) requiring specific TS LSP that will be used to carry service LSP(s) requiring a specific
granularity. TS granularity.
- Support for LSP setup of new ODUk/ODUflex containers with related - Support for LSP setup of new ODUk/ODUflex containers with related
mapping and multiplexing capabilities mapping and multiplexing capabilities
A new label format must be defined to carry the exact TSs A new label format must be defined to carry the exact TS's
allocation information related to the extended mapping and allocation information related to the extended mapping and
multiplexing hierarchy (For example, ODU0 into ODU2 multiplexing multiplexing hierarchy (for example, ODU0 into ODU2 multiplexing
(with 1.25Gbps TS granularity)), in order to set up the ODU (with 1.25 Gbps TS granularity)), in order to set up the ODU
connection. connection.
- Support for TPN allocation and negotiation - Support for TPN allocation and negotiation
TPN needs to be configured as part of the MSI information (see TPN needs to be configured as part of the MSI information (see
more information in Section 3.1.2.1). A signaling mechanism must more information in Section 3.1.2.1). A signaling mechanism must
be identified to carry TPN information if control plane is used to be identified to carry TPN information if the control plane is
configure MSI information. used to configure MSI information.
- Support for ODU Virtual Concatenation (VCAT) and Link Capacity - Support for ODU Virtual Concatenation (VCAT) and Link Capacity
Adjustment Scheme (LCAS) Adjustment Scheme (LCAS)
GMPLS signaling should support the creation of Virtual GMPLS signaling should support the creation of Virtual
Concatenation of ODUk signal with k=1, 2, 3. The signaling should Concatenation of an ODUk signal with k=1, 2, 3. The signaling
also support the control of dynamic capacity changing of a VCAT should also support the control of dynamic capacity changing of a
container using LCAS ([G7042]). [RFC6344] has a clear description VCAT container using LCAS ([G7042]). [RFC6344] has a clear
of VCAT and LCAS control in SONET/SDH and OTN. description of VCAT and LCAS control in SONET/SDH and OTN.
- Support for Control of Hitless Adjustment of ODUflex (GFP) - Support for Control of Hitless Adjustment of ODUflex (GFP)
[G7044] has been created in ITU-T to specify Hitless Adjustment of [G7044] has been created in ITU-T to specify hitless adjustment of
ODUflex (GFP) (HAO) that is used to increase or decrease the ODUflex (GFP) (HAO) that is used to increase or decrease the
bandwidth of an ODUflex (GFP) that is transported in an OTN. bandwidth of an ODUflex (GFP) that is transported in an OTN.
The procedure of ODUflex (GFP) adjustment requires the The procedure of ODUflex (GFP) adjustment requires the
participation of every node along the path. Therefore, it is participation of every node along the path. Therefore, it is
recommended to use the control plane signaling to initiate the recommended to use control-plane signaling to initiate the
adjustment procedure in order to avoid the 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 control plane, the 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 described in [RFC3209]. Therefore, the Shared Explicit decreasing as described in [RFC3209]. Therefore, the Shared
(SE) style can be used for control of HAO. Explicit (SE) style can be used for control of HAO.
All the extensions above should consider the extensibility to match All the extensions above should consider the extensibility to match
future evolvement of OTN. future evolvement of OTN.
5.3. Implications for GMPLS Routing 5.3. Implications for GMPLS Routing
The path computation process needs to select a suitable route for an The path computation process needs to select a suitable route for an
ODUj connection request. In order to perform the path computation, it ODUj connection request. In order to perform the path computation,
needs to evaluate the available bandwidth on each candidate link. it needs to evaluate the available bandwidth on each candidate link.
The routing protocol should be extended to convey sufficient The routing protocol should be extended to convey sufficient
information to represent ODU Traffic Engineering (TE) topology. information to represent ODU Traffic Engineering (TE) topology.
Interface Switching Capability Descriptors defined in [RFC4202] 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 and related Maximum LSP Bandwidth and the the Switching Capability, related Maximum LSP Bandwidth, and
Switching Capability specific information. When the Switching Switching Capability specific information. When the Switching
Capability field is TDM the Switching Capability Specific Information Capability field is TDM, the Switching Capability specific
field includes Minimum LSP Bandwidth, an indication whether the information field includes Minimum LSP Bandwidth, an indication
interface supports Standard or Arbitrary SONET/SDH, and padding. whether the interface supports Standard or Arbitrary SONET/SDH, and
Hence a new Switching Capability value needs to be defined for [G709- padding. Hence, a new Switching Capability value needs to be defined
2012] ODU switching in order to allow the definition of a new for [G709-2012] ODU switching in order to allow the definition of a
Switching Capability Specific Information field definition. The new Switching Capability specific information field. The following
following requirements should be considered: requirements should be considered:
- Support for carrying the link multiplexing capability - Support for carrying the link multiplexing capability
As discussed in section 3.1.2, many different types of ODUj can
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 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.
The bit rate (i.e., bandwidth) of each TS is dependent on the TS - Support any ODU and ODUflex
granularity and the signal type of the link. For example, the
bandwidth of a 1.25G TS in an OTU2 is about 1.249409620Gbps,
while the bandwidth of a 1.25G TS in an OTU3 is about
1.254703729Gbps.
One LO ODU may need different number of TSs when multiplexed into The bit rate (i.e., bandwidth) of each TS is dependent on the TS
different HO ODUs. For example, for ODU2e, 9 TSs are needed when granularity and the signal type of the link. For example, the
multiplexed into an ODU3, while only 8 TSs are needed when bandwidth of a 1.25 Gbps TS in an OTU2 is about 1.249409620 Gbps,
multiplexed into an ODU4. For ODUflex, the total number of TSs to while the bandwidth of a 1.25 Gbps TS in an OTU3 is about
be reserved in a HO ODU equals the maximum of [bandwidth of 1.254703729 Gbps.
ODUflex / bandwidth of TS of the HO ODU].
Therefore, the routing protocol should be capable of carrying the One LO ODU may need a different number of TSs when multiplexed
necessary link bandwidth information for performing accurate into different HO ODUs. For example, for ODU2e, 9 TSs are needed
route computation for any of the fixed rate ODUs as well as when multiplexed into an ODU3, while only 8 TSs are needed when
ODUflex. 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].
- Support for differentiating between terminating and switching 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 capability
Due to internal constraints and/or limitations, the type of Due to internal constraints and/or limitations, the type of signal
signal being advertised by an interface could be restricted to being advertised by an interface could be restricted to switched
switched (i.e. forwarded to switching matrix without (i.e., forwarded to switching matrix without
multiplexing/demultiplexing actions), restricted to terminated multiplexing/demultiplexing actions), restricted to terminated
(demuxed) or both of them. The capability advertised by an (demuxed), or both. The capability advertised by an interface
interface needs further distinction in order to separate needs further distinction in order to separate termination and
termination and switching capabilities. switching capabilities.
Therefore, to allow the required flexibility, the routing Therefore, to allow the required flexibility, the routing protocol
protocol should clearly distinguish the terminating and switching should clearly distinguish the terminating and switching
capability. capability.
- Support for Tributary Slot Granularity advertisement - Support for Tributary Slot Granularity advertisement
[G709-2012] defines two types of TS but each link can only [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 support a single type at a given time. In order to perform a
correct path computation (i.e. the LSP end points have matching correct path computation (i.e., the LSP endpoints have matching
Tributary Slot Granularity values) the Tributary Slot Granularity Tributary Slot Granularity values) the Tributary Slot Granularity
needs to be advertised. needs to be advertised.
- Support different priorities for resource reservation - Support different priorities for resource reservation
How many priorities levels should be supported depends on the How many priority levels should be supported depends on the
operator's policy. Therefore, the routing protocol should be operator's policy. Therefore, the routing protocol should be
capable of supporting 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 amount of TE links that has to be scalability by reducing the number of TE links that have to be
handled by routing protocol. The routing protocol should be handled by the routing protocol. The routing protocol should be
capable of supporting bundling multiple OTU links, at the same capable of supporting the bundling of multiple OTU links, at the
line rate and muxing hierarchy, between a pair of nodes as a TE same line rate and muxing hierarchy, between a pair of nodes that
link. Note that link bundling is optional and is implementation a TE link does. Note that link bundling is optional and is
dependent. implementation dependent.
- Support for Control of Hitless Adjustment of ODUflex (GFP) - Support for Control of Hitless Adjustment of ODUflex (GFP)
The control plane should support hitless adjustment of ODUflex, The control plane should support hitless adjustment of ODUflex, so
so the routing protocol should be capable of differentiating the routing protocol should be capable of differentiating whether
whether an ODU link can support hitless adjustment of ODUflex or not an ODU link can support hitless adjustment of ODUflex (GFP)
(GFP) or not, and how much resource can be used for resizing. and how many resources can be used for resizing. This can be
This can be achieved by introducing a new signal type achieved by introducing a new signal type "ODUflex(GFP-F),
"ODUflex(GFP-F), resizable" that implies the support for hitless resizable" that implies the support for hitless adjustment of
adjustment of ODUflex (GFP) by that link. ODUflex (GFP) by that link.
As mentioned in Section 5.1, one method of enabling multiplexing As mentioned in Section 5.1, one method of enabling multiplexing
hierarchy is via usage of dedicated boards to allow tunneling of new hierarchy is via usage of dedicated boards to allow tunneling of new
services through legacy ODU1, ODU2, ODU3 containers. Such dedicated services through legacy ODU1, ODU2, and ODU3 containers. Such
boards may have some constraints with respect to switching matrix dedicated boards may have some constraints with respect to switching
access; detection and representation of such constraints is for matrix access; detection and representation of such constraints is
further study. for further study.
5.4. Implications for Link Management Protocol 5.4. Implications for Link Management Protocol
As discussed in section 5.3, Path computation needs to know the As discussed in Section 5.3, path computation needs to know the
interface switching capability of links. The switching capability of interface switching capability of links. The switching capability of
two ends of the link may be different, so the link capability of two two ends of the link may be different, so the link capability of two
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.
Note that LO ODU type information can be, in principle, discovered by Note that LO ODU type information can be, in principle, discovered by
routing. Since in certain cases, routing is not present (e.g. User- routing. Since in certain cases, routing is not present (e.g., in
Network Interface (UNI) case) we need to extend link management the case of a User-Network Interface (UNI)), we need to extend link
protocol capabilities to cover this aspect. In case of routing management protocol capabilities to cover this aspect. If routing is
presence, the discovery via LMP could also be optional. present, discovery via LMP could also be optional.
- Correlating the granularity of the TS - Correlating the granularity of the TS
As discussed in section 3.1.2, the two ends of a link may support As discussed in Section 3.1.2, the two ends of a link may support
different TS granularity. In order to allow interconnection the different TS granularity. In order to allow interconnection, the
node with 1.25Gbps granularity should fall back to 2.5Gbps node with 1.25 Gbps granularity should fall back to 2.5 Gbps
granularity. granularity.
Therefore, it is necessary for the two ends of a link to Therefore, it is necessary for the two ends of a link to correlate
correlate the granularity of the TS. This ensures the correct use the granularity of the TS. This ensures the correct use of the TE
and of the TE link. link.
- Correlating the supported LO ODU signal types and multiplexing - Correlating the supported LO ODU signal types and multiplexing
hierarchy capability hierarchy capability
Many new ODU signal types have been introduced in [G709-2012], Many new ODU signal types have been introduced in [G709-2012],
such as ODU0, ODU4, ODU2e and ODUflex. It is possible that such as ODU0, ODU4, ODU2e, and ODUflex. It is possible that
equipment does not support all the LO ODU signal types introduced equipment does not support all the LO ODU signal types introduced
by those new standards or drafts. Furthermore, since multiplexing by new standards or documents. Furthermore, since multiplexing
hierarchy may not be supported by the legacy OTN, it is possible hierarchy may not be supported by the legacy OTNs, it is possible
that only one end of an ODU link can support multiplexing that only one end of an ODU link can support multiplexing
hierarchy capability, or the two ends of the link support hierarchy capability or that the two ends of the link support
different multiplexing hierarchy capabilities (e.g., one end of different multiplexing hierarchy capabilities (e.g., one end of
the link supports ODU0 into ODU1 into ODU3 multiplexing while the the link supports ODU0 into ODU1 into ODU3 multiplexing while the
other end supports ODU0 into ODU2 into ODU3 multiplexing). other end supports ODU0 into ODU2 into ODU3 multiplexing).
For the control and management consideration, it is necessary for For control and management consideration, it is necessary for the
the two ends of an HO ODU link to correlate which types of LO ODU two ends of an HO ODU link to correlate the types of LO ODU that
can be supported and what multiplexing hierarchy capabilities can can be supported and the multiplexing hierarchy capabilities that
be provided by the other end. can be provided by the other end.
5.5. Implications for Control Plane Backward Compatibility 5.5. Implications for Control-Plane Backward Compatibility
With the introduction of [G709-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 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 new OTN control plane characterized in this document. [G709-2012] and the new OTN control plane characterized in this
Note that a third case, for the sake of completeness, consists on document. Note that a third case, for the sake of completeness,
nodes supporting the legacy OTN referenced by [RFC4328] with a new consists of nodes supporting the legacy OTN referenced by [RFC4328]
OTN control plane, but such nodes can be considered as new nodes with with a new OTN control plane, but such nodes can be considered new
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 [RFC4328], in support of the legacy control-plane procedures defined in [RFC4328] in support of the
OTN, and the control plane procedures defined to support [G709-2012], legacy OTN and the control-plane procedures defined to support
as outlined by this document. [G709-2012] as outlined by this document.
Compatibility needs to be considered only when controlling ODU1 or Compatibility needs to be considered only when controlling an ODU1,
ODU2 or ODU3 connection, because the legacy OTN only support these ODU2, or ODU3 connection because the legacy OTN only supports these
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 [G709-2012] - A node supporting [G709-2012] could support only the control-plane
related control plane procedures, in which case both types of procedures related to [G709-2012], in which case both types of
nodes would be unable to jointly control an LSP for an ODU type nodes would be unable to jointly control an LSP for an ODU type
that both nodes support in the data plane. that both nodes support in the data plane.
- A node supporting [G709-2012] could support both the [G709-2012] - A node supporting [G709-2012] could support both the control plane
related control plane 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 procedure to follow o Such a node could identify which set of procedures to follow
when initiating an LSP based on the Switching Capability value when initiating an LSP based on the Switching Capability value
advertised in routing. advertised in routing.
o Such a node could follow the set of procedures based on the o Such a node could follow the set of procedures based on the
Switching Type received in signaling messages from an upstream Switching Type received in signaling messages from an upstream
node. node.
o Such a node, when processing a transit LSP, could select which o Such a node, when processing a transit LSP, could select which
signaling procedures to follow based on the Switching signaling procedures to follow based on the Switching
Capability value advertised in routing by the next hop node. Capability value advertised in routing by the next-hop node.
5.6. Implications for Path Computation Elements 5.6. 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 which 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] includes switching capability, encoding the PCE defined in [RFC5440] include switching capability, encoding
type, signal type, etc. type, signal type, etc.
As described in section 5.2, new signal types and new signals with As described in Section 5.2, new signal types and new signals with
variable bandwidth information need to be carried in the extended variable bandwidth information need to be carried in the extended
signaling message of path setup. For the same consideration, PCE signaling message of path setup. For the same consideration, the PCE
Communication Protocol (PCECP) also has a desire to be extended to Communication Protocol (PCECP) also has a desire to be extended to
carry the new signal type and related variable bandwidth information carry the new signal type and related variable bandwidth information
when a PCC requests a path computation. when a PCC requests a path computation.
5.7. Implications for Management of GMPLS Networks 5.7. Implications for Management of GMPLS Networks
From the management perspective, it should be capable of managing not From the management perspective, the management function should be
only the legacy OTN referenced by [RFC4328], but also new management capable of managing not only the legacy OTN referenced by [RFC4328],
functions introduced by the new features as specified in [G709-2012] but also new management functions introduced by the new features as
(see more in Sections 3&4). Regarding OTN Operations, Administration specified in [G709-2012] (for more information, see Sections 3 and
and Maintenance (OAM) configuration, it could be done through either 4). OTN Operations, Administration, and Maintenance (OAM)
Network Management Systems (NMS) or GMPLS control plane as defined in configuration could be done through either Network Management Systems
[TDM-OAM]. Further details of management aspects for GMPLS networks (NMS) or the GMPLS control plane as defined in [TDM-OAM]. For
refer to [RFC3945]. further details on management aspects for GMPLS networks, refer to
[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 (see more in Section 8 of manageability should be considered (for more information, see
[RFC5440]). Section 8 of [RFC5440]).
6. Data Plane Backward Compatibility Considerations 6. Data-Plane Backward Compatibility Considerations
If MI AUTOpayloadtype is activated (see [G798-V4]), a node supporting If MI AUTOpayloadtype is activated (see [G798]), a node supporting
1.25Gbps TS can interwork with the other nodes that supporting 1.25 Gbps TS can interwork with the other nodes that support 2.5 Gbps
2.5Gbps TS by combining Specific TSs together in data plane. The TS by combining specific TSs together in the data plane. The control
control plane must support this TS combination. plane must support this TS combination.
Path Path
+----------+ ------------> +----------+ +----------+ ------------> +----------+
| TS1==|===========\--------+--TS1 | | TS1==|===========\--------+--TS1 |
| TS2==|=========\--\-------+--TS2 | | TS2==|=========\--\-------+--TS2 |
| TS3==|=======\--\--\------+--TS3 | | TS3==|=======\--\--\------+--TS3 |
| TS4==|=====\--\--\--\-----+--TS4 | | TS4==|=====\--\--\--\-----+--TS4 |
| | \ \ \ \----+--TS5 | | | \ \ \ \----+--TS5 |
| | \ \ \------+--TS6 | | | \ \ \------+--TS6 |
| | \ \--------+--TS7 | | | \ \--------+--TS7 |
| | \----------+--TS8 | | | \----------+--TS8 |
+----------+ <------------ +----------+ +----------+ <------------ +----------+
node A Resv node B node A Resv node B
Figure 5 - Interworking between 1.25Gbps TS and 2.5Gbps TS 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 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.5Gbps TS while between node A and B, where node A only supports the 2.5 Gbps TS
node B supports the 1.25Gbps TS. In this case, the TS#i and TS#i+4 while node B supports the 1.25 Gbps TS. In this case, the TS#i and
(where i<=4) of node B are combined together. When creating an ODU1 TS#i+4 (where i<=4) of node B are combined together. When creating
service in this ODU2 link, node B reserves the TS#i and TS#i+4 with an ODU1 service in this ODU2 link, node B reserves the TS#i and
the granularity of 1.25Gbps. But in the label sent from B to A, it is TS#i+4 with the granularity of 1.25 Gbps. But in the label sent from
indicated that the TS#i with the granularity of 2.5Gbps is reserved. 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 In the opposite direction, when receiving a label from node A
indicating that the TS#i with the granularity of 2.5Gbps is reserved, indicating that the TS#i with the granularity of 2.5 Gbps is
node B will reserved the TS#i and TS#i+4 with the granularity of reserved, node B will reserve the TS#i and TS#i+4 with the
1.25Gbps in its data plane. granularity of 1.25 Gbps in its data plane.
7. Security Considerations 7. Security Considerations
The use of control plane protocols for signaling, routing and path The use of control-plane protocols for signaling, routing, and path
computation opens an OTN to security threats through attacks on those computation opens an OTN to security threats through attacks on those
protocols. Although, this is not greater than the risks presented by protocols. 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 control Meanwhile, the Data Communication Network (DCN) for OTN GMPLS
plane protocols is likely to be in the in-fiber overhead, which control-plane protocols is likely to be in the in-fiber overhead,
together with access lists at the network edges, provides a which, together with access lists at the network edges, provides a
significant security feature. For further details of the specific significant security feature. For further details of specific
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] ([RFC3473], [RFC4203], [RFC5307], [RFC4204], and [RFC5440]).
provides an overview of security vulnerabilities and protection [RFC5920] provides an overview of security vulnerabilities and
mechanisms for the GMPLS control plane. protection mechanisms for the GMPLS control plane.
8. IANA Considerations 8. Acknowledgments
This document makes not requests for IANA action. We would like to thank Maarten Vissers and Lou Berger for their
reviews and useful comments.
9. Acknowledgments 9. Contributors
We would like to thank Maarten Vissers and Lou Berger for their Jianrui Han
review and useful comments. 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
10. References Malcolm Betts
EMail: malcolm.betts@rogers.com
10.1. Normative References Pietro Grandi
Alcatel-Lucent
Optics CTO
Via Trento 30
20059 Vimercate (Milano)
Italy
Phone: +39 039 6864930
EMail: pietro_vittorio.grandi@alcatel-lucent.it
[RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V. 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
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 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC 3209, December 2001. Tunnels", RFC 3209, December 2001.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC3471] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", RFC Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003. 3471, January 2003.
[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003. 3473, January 2003.
[RFC4201] K. Kompella, Y. Rekhter, Ed., "Link Bundling in MPLS [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling
Traffic Engineering (TE)", RFC 4201, October 2005. in MPLS Traffic Engineering (TE)", RFC 4201, October
2005.
[RFC4202] K. Kompella, Y. Rekhter, Ed., "Routing Extensions in [RFC4202] Kompella, K., Ed., and Y. Rekhter, Ed., "Routing
Support of Generalized Multi-Protocol Label Switching Extensions in Support of Generalized Multi-Protocol Label
(GMPLS)", RFC 4202, October 2005. Switching (GMPLS)", RFC 4202, October 2005.
[RFC4203] K. Kompella, Y. Rekhter, Ed., "OSPF Extensions in Support [RFC4203] Kompella, K., Ed., and Y. Rekhter, Ed., "OSPF Extensions
of Generalized Multi-Protocol Label Switching (GMPLS)", in Support of Generalized Multi-Protocol Label Switching
RFC 4203, October 2005. (GMPLS)", RFC 4203, October 2005.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC
4204, October 2005. 4204, October 2005.
[RFC4206] K. Kompella, Y. Rekhter, Ed., "Label Switched Paths (LSP) [RFC4206] Kompella, K. and Y. Rekhter, "Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October (GMPLS) Traffic Engineering (TE)", RFC 4206, October
2005. 2005.
[RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol [RFC4328] Papadimitriou, D., Ed., "Generalized Multi-Protocol Label
LabelSwitching (GMPLS) Signaling Extensions for G.709 Switching (GMPLS) Signaling Extensions for G.709 Optical
Optical Transport Networks Control", RFC 4328, Jan 2006. Transport Networks Control", RFC 4328, January 2006.
[RFC5307] K. Kompella, Y. Rekhter, Ed., "IS-IS Extensions in [RFC5307] Kompella, K., Ed., and Y. Rekhter, Ed., "IS-IS Extensions
Support of Generalized Multi-Protocol Label Switching in Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 5307, October 2008. (GMPLS)", RFC 5307, October 2008.
[RFC5440] JP. Vasseur, JL. Le Roux, Ed.," Path Computation Element [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path
(PCE) Communication Protocol (PCEP)", RFC 5440, March Computation Element (PCE) Communication Protocol (PCEP)",
2009. RFC 5440, March 2009.
[RFC6001] Dimitri Papadimitriou et al, "Generalized Multi-Protocol
Label Switching (GMPLS) Protocol Extensions for Multi-
Layer and Multi-Region Networks (MLN/MRN)", RFC6001,
February 21, 2010.
[RFC6107] K. Shiomoto, A. Farrel, "Procedures for Dynamically [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard,
Signaled Hierarchical Label Switched Paths", RFC6107, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol
February 2011. Extensions for Multi-Layer and Multi-Region Networks
(MLN/MRN)", RFC 6001, October 2010.
[RFC6344] G. Bernstein et al, "Operating Virtual Concatenation [RFC6107] Shiomoto, K., Ed., and A. Farrel, Ed., "Procedures for
(VCAT) and the Link Capacity Adjustment Scheme (LCAS) Dynamically Signaled Hierarchical Label Switched Paths",
with Generalized Multi-Protocol Label Switching (GMPLS)", RFC 6107, February 2011.
RFC6344, August, 2011.
[G709-2012] ITU-T, "Interface for the Optical Transport Network [RFC6344] Bernstein, G., Ed., Caviglia, D., Rabbat, R., and H. van
(OTN)", G.709/Y.1331 Recommendation, February 2012. 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 10.2. Informative References
[G798-V4] ITU-T, "Characteristics of optical transport network [G798] ITU-T, "Characteristics of optical transport network
hierarchy equipment functional blocks", G.798 hierarchy equipment functional blocks", G.798
Recommendation, October 2010. Recommendation, December 2012.
[G7042] ITU-T, "Link capacity adjustment scheme (LCAS) for
virtual concatenated signals", G.7042/Y.1305, March 2006.
[G872-2001] ITU-T, "Architecture of optical transport networks", [G872-2001] ITU-T, "Architecture of optical transport networks",
G.872 Recommendation, November 2001. G.872 Recommendation, November 2001.
[G872-2012] ITU-T, "Architecture of optical transport networks", [G872-2012] ITU-T, "Architecture of optical transport networks",
G.872 Recommendation, October 2012. G.872 Recommendation, October 2012.
[G7044] ITU-T, "Hitless adjustment of ODUflex", G.7044/Y.1347,
October 2011.
[G7041] ITU-T, "Generic framing procedure", G.7041/Y.1303, April [G7041] ITU-T, "Generic framing procedure", G.7041/Y.1303, April
2011. 2011.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [G7042] ITU-T, "Link capacity adjustment scheme (LCAS) for
(GMPLS) Architecture", RFC 3945, October 2004. virtual concatenated signals", G.7042/Y.1305, March 2006.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path [G7044] ITU-T, "Hitless adjustment of ODUflex (HAO)",
Computation Element (PCE)-Based Architecture", G.7044/Y.1347, October 2011.
RFC 4655, August 2006.
[RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
and PCE Control of Wavelength Switched Optical Networks Switching (GMPLS) Architecture", RFC 3945, October 2004.
(WSON)", RFC6163, April 2011.
[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 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC5920, July 2010. Networks", RFC 5920, July 2010.
[RFC7025] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai [RFC7025] Otani, T., Ogaki, K., Caviglia, D., Zhang, F., and C.
Zhang, "Requirements for GMPLS applications of PCE", Margaria, "Requirements for GMPLS Applications of PCE",
RFC7025, September 2013. RFC 7025, September 2013.
[TDM-OAM] A. Kern, A. Takacs, "GMPLS RSVP-TE Extensions for [TDM-OAM] Kern, A., and A. Takacs, "GMPLS RSVP-TE Extensions for
SONET/SDH and OTN OAM Configuration", draft-ietf-ccamp- SONET/SDH and OTN OAM Configuration", Work in Progress,
rsvp-te-sdh-otn-oam-ext, Work in Progress. November 2013.
11. Authors' Addresses Authors' Addresses
Fatai Zhang (editor) Fatai Zhang (editor)
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129
P.R. China
Phone: +86-755-28972912 Phone: +86-755-28972912
Email: zhangfatai@huawei.com EMail: zhangfatai@huawei.com
Dan Li Dan Li
Huawei Technologies Co., Ltd. Huawei Technologies
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129
P.R. China
Phone: +86-755-28973237 Phone: +86-755-28973237
Email: huawei.danli@huawei.com EMail: huawei.danli@huawei.com
Han Li Han Li
China Mobile Communications Corporation China Mobile Communications Corporation
53 A Xibianmennei Ave. Xuanwu District 53 A Xibianmennei Ave. Xuanwu District
Beijing 100053 P.R. China Beijing 100053
P.R. China
Phone: +86-10-66006688 Phone: +86-10-66006688
Email: lihan@chinamobile.com EMail: lihan@chinamobile.com
Sergio Belotti Sergio Belotti
Alcatel-Lucent Alcatel-Lucent
Optics CTO Optics CTO
Via Trento 30 20059 Vimercate (Milano) Italy Via Trento 30
+39 039 6863033 20059 Vimercate (Milano)
Italy
Email: sergio.belotti@alcatel-lucent.it Phone: +39 039 6863033
EMail: sergio.belotti@alcatel-lucent.it
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Via A. Negrone 1/A Via A. Negrone 1/A
Genova - Sestri Ponente Genova - Sestri Ponente
Italy Italy
EMail: daniele.ceccarelli@ericsson.com
Email: daniele.ceccarelli@ericsson.com
12. 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
+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
Intellectual Property
The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.
Copies of Intellectual Property disclosures made to the IETF
Secretariat and any assurances of licenses to be made available, or
the result of an attempt made to obtain a general license or
permission for the use of such proprietary rights by implementers or
users of this specification can be obtained from the IETF on-line IPR
repository at http://www.ietf.org/ipr
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
any standard or specification contained in an IETF Document. Please
address the information to the IETF at ietf-ipr@ietf.org.
The definitive version of an IETF Document is that published by, or
under the auspices of, the IETF. Versions of IETF Documents that are
published by third parties, including those that are translated into
other languages, should not be considered to be definitive versions
of IETF Documents. The definitive version of these Legal Provisions
is that published by, or under the auspices of, the IETF. Versions of
these Legal Provisions that are published by third parties, including
those that are translated into other languages, should not be
considered to be definitive versions of these Legal Provisions.
For the avoidance of doubt, each Contributor to the IETF Standards
Process licenses each Contribution that he or she makes as part of
the IETF Standards Process to the IETF Trust pursuant to the
provisions of RFC 5378. No language to the contrary, or terms,
conditions or rights that differ from or are inconsistent with the
rights and licenses granted under RFC 5378, shall have any effect and
shall be null and void, whether published or posted by such
Contributor, or included with or in such Contribution.
Disclaimer of Validity
All IETF Documents and the information contained therein are provided
on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
FOR A PARTICULAR PURPOSE.
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.
 End of changes. 231 change blocks. 
570 lines changed or deleted 619 lines changed or added

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