draft-ietf-ccamp-gmpls-g709-framework-09.txt   draft-ietf-ccamp-gmpls-g709-framework-10.txt 
Network Working Group Fatai Zhang, Ed. Network Working Group Fatai Zhang, Ed.
Internet Draft Dan Li Internet Draft Dan Li
Category: Informational Huawei Category: Informational Huawei
Han Li Han Li
CMCC CMCC
S.Belotti S.Belotti
Alcatel-Lucent Alcatel-Lucent
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
Expires: February 25, 2013 August 25, 2012 Expires: May 13, 2013 November 13, 2012
Framework for GMPLS and PCE Control of Framework for GMPLS and PCE Control of
G.709 Optical Transport Networks G.709 Optical Transport Networks
draft-ietf-ccamp-gmpls-g709-framework-09.txt draft-ietf-ccamp-gmpls-g709-framework-10.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 25, 2013. This Internet-Draft will expire on May 13, 2013.
Abstract Abstract
This document provides a framework to allow the development of This document provides a framework to allow the development of
protocol extensions to support Generalized Multi-Protocol Label protocol extensions to support Generalized Multi-Protocol Label
Switching (GMPLS) and Path Computation Element (PCE) control of Switching (GMPLS) and Path Computation Element (PCE) control of
Optical Transport Networks (OTN) as specified in ITU-T Recommendation Optical Transport Networks (OTN) as specified in ITU-T Recommendation
G.709 as consented in October 2009. G.709 as published in 2009.
Table of Contents Table of Contents
1. Introduction .................................................. 2 1. Introduction .................................................. 2
2. Terminology ................................................... 3 2. Terminology ................................................... 3
3. G.709 Optical Transport Network (OTN) ......................... 4 3. G.709 Optical Transport Network ............................... 4
3.1. OTN Layer Network ........................................ 4 3.1. OTN Layer Network ........................................ 4
3.1.1. Client signal mapping ............................... 5 3.1.1. Client signal mapping ............................... 5
3.1.2. Multiplexing ODUj onto Links ........................ 6 3.1.2. Multiplexing ODUj onto Links ........................ 6
3.1.2.1. Structure of MSI information ................... 8 3.1.2.1. Structure of MSI information ................... 8
4. Connection management in OTN .................................. 9 4. Connection management in OTN .................................. 9
4.1. Connection management of the ODU ........................ 10 4.1. Connection management of the ODU ........................ 10
5. GMPLS/PCE Implications ....................................... 12 5. GMPLS/PCE Implications ....................................... 12
5.1. Implications for LSP Hierarchy with GMPLS TE ............ 12 5.1. Implications for Label Switch Path (LSP) Hierarchy ...... 12
5.2. Implications for GMPLS Signaling ........................ 13 5.2. Implications for GMPLS Signaling ........................ 13
5.3. Implications for GMPLS Routing .......................... 15 5.3. Implications for GMPLS Routing .......................... 15
5.4. Implications for Link Management Protocol (LMP) ......... 17 5.4. Implications for Link Management Protocol ............... 17
5.5. Implications for Control Plane Backward Compatibility ... 18 5.5. Implications for Control Plane Backward Compatibility ... 18
5.6. Implications for Path Computation Elements .............. 19 5.6. Implications for Path Computation Elements .............. 19
6. Data Plane Backward Compatibility Considerations ............. 20 6. Data Plane Backward Compatibility Considerations ............. 20
7. Security Considerations ...................................... 20 7. Security Considerations ...................................... 20
8. IANA Considerations .......................................... 21 8. IANA Considerations .......................................... 21
9. Acknowledgments .............................................. 21 9. Acknowledgments .............................................. 21
10. References .................................................. 21 10. References .................................................. 21
10.1. Normative References ................................... 21 10.1. Normative References ................................... 21
10.2. Informative References ................................. 22 10.2. Informative References ................................. 22
11. Authors' Addresses .......................................... 23 11. Authors' Addresses .......................................... 23
12. Contributors ................................................ 24 12. Contributors ................................................ 24
APPENDIX A: ODU connection examples ............................. 25
1. Introduction 1. Introduction
OTN has become a mainstream layer 1 technology for the transport OTN has become a mainstream layer 1 technology for the transport
network. Operators want to introduce control plane capabilities based network. Operators want to introduce control plane capabilities based
on Generalized Multi-Protocol Label Switching (GMPLS) to OTN networks, on GMPLS to OTN networks, to realize the benefits associated with a
to realize the benefits associated with a high-function control plane high-function control plane (e.g., improved network resiliency,
(e.g., improved network resiliency, resource usage efficiency, etc.). resource usage efficiency, etc.).
GMPLS extends MPLS to encompass time division multiplexing (TDM) GMPLS extends Multi-Protocol Label Switching (MPLS) to encompass time
networks (e.g., SONET/SDH, PDH, and G.709 sub-lambda), lambda division multiplexing (TDM) networks (e.g., Synchronous Optical
switching optical networks, and spatial switching (e.g., incoming NETwork (SONET)/ Synchronous Digital Hierarchy (SDH), Plesiochronous
port or fiber to outgoing port or fiber). The GMPLS architecture is Digital Hierarchy (PDH), and G.709 sub-lambda), lambda switching
provided in [RFC3945], signaling function and Resource ReserVation optical networks, and spatial switching (e.g., incoming port or fiber
Protocol-Traffic Engineering (RSVP-TE) extensions are described in to outgoing port or fiber). The GMPLS architecture is provided in
[RFC3471] and [RFC3473], routing and OSPF extensions are described in [RFC3945], signaling function and Resource ReserVation Protocol-
[RFC4202] and [RFC4203], and the Link Management Protocol (LMP) is Traffic Engineering (RSVP-TE) extensions are described in [RFC3471]
described in [RFC4204]. 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 protocol suite including provision [RFC4328] provides the The GMPLS protocol suite including provision [RFC4328] provides the
mechanisms for basic GMPLS control of OTN networks based on the 2001 mechanisms for basic GMPLS control of OTN networks based on the 2001
revision of the G.709 specification [G709-V1]. Later revisions of the revision of the G.709 specification [G709-V1]. Later revisions of the
G.709 specification, including [G709-V3], have included some new G.709 specification, including [G709-V3], have included some new
features; for example, various multiplexing structures, two types of features; for example, various multiplexing structures, two types of
TSs (i.e., 1.25Gbps and 2.5Gbps), and extension of the Optical Data Tributary Slots (TSs) (i.e., 1.25Gbps and 2.5Gbps), and extension of
Unit (ODU) ODUj definition to include the ODUflex function. the Optical channel 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 additionally provides a framework for the GMPLS control of OTN
networks and includes a discussion of the implication for the use of networks and includes a discussion of the implication for the use of
the Path Computation Element (PCE) [RFC4655]. the PCE [RFC4655].
For the purposes of the control plane the OTN can be considered as For the purposes of the control plane the OTN can be considered as
being comprised of ODU and wavelength (OCh) layers. This document being comprised of ODU and wavelength (Optical Channel (OCh)) layers.
focuses on the control of the ODU layer, with control of the This document focuses on the control of the ODU layer, with control
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
ODU: Optical Channel Data Unit OPU: Optical channel Payload 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, 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 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, 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
skipping to change at page 4, line 14 skipping to change at page 4, line 16
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, 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 up to +/-100 ppm. bit rate tolerance up to +/-100 ppm.
3. G.709 Optical Transport Network (OTN) 3. G.709 Optical Transport Network
This section provides an informative overview of those aspects of the This section provides an informative overview of those aspects of the
OTN impacting control plane protocols. This overview is based on the OTN impacting control plane protocols. This overview is based on the
ITU-T Recommendations that contain the normative definition of the ITU-T Recommendations that contain the normative definition of the
OTN. Technical details regarding OTN architecture and interfaces are OTN. Technical details regarding OTN architecture and interfaces are
provided in the relevant ITU-T Recommendations. provided in the relevant ITU-T Recommendations.
Specifically, [G872-2001] and [G872Am2] describe the functional Specifically, [G872-2001] and [G872-Am2] describe the functional
architecture of optical transport networks providing optical signal architecture of optical transport networks providing optical signal
transmission, multiplexing, routing, supervision, performance transmission, multiplexing, routing, supervision, performance
assessment, and network survivability. [G709-V1] defines the assessment, and network survivability. [G709-V1] defines the
interfaces of the optical transport network to be used within and interfaces of the optical transport network to be used within and
between subnetworks of the optical network. With the evolution and between subnetworks of the optical network. With the evolution and
deployment of OTN technology many new features have been specified in deployment of OTN technology many new features have been specified in
ITU-T recommendations, including for example, new ODU0, ODU2e, ODU4 ITU-T recommendations, including for example, new ODU0, ODU2e, ODU4
and ODUflex containers as described in [G709-V3]. and ODUflex containers as described in [G709-V3].
3.1. OTN Layer Network 3.1. OTN Layer Network
The simplified signal hierarchy of OTN is shown in Figure 1, which The simplified signal hierarchy of OTN is shown in Figure 1, which
illustrates the layers that are of interest to the control plane. illustrates the layers that are of interest to the control plane.
Other layers below OCh (e.g. Optical Transmission Section - OTS) are Other layers below OCh (e.g. Optical Transmission Section (OTS)) are
not included in this Figure. The full signal hierarchy is provided in not included in this Figure. The full signal hierarchy is provided in
[G709-V3]. [G709-V3].
Client signal Client signal
| |
ODUj ODUj
| |
OTU/OCh OTU/OCh
OMS OMS
Figure 1 - Basic OTN signal hierarchy Figure 1 - Basic OTN signal hierarchy
Client signals are mapped into ODUj containers. These ODUj containers Client signals are mapped into ODUj containers. These ODUj containers
are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are are multiplexed onto the OTU/OCh. The individual OTU/OCh signals are
combined in the Optical Multiplex Section (OMS) using WDM combined in the OMS using Wavelength Division Multiplexing (WDM), and
multiplexing, and this aggregated signal provides the link between this aggregated signal provides the link between the nodes.
the nodes.
3.1.1. Client signal mapping 3.1.1. Client signal mapping
The client signals are mapped into a Low Order (LO) ODUj. Appendix A The client signals are mapped into a LO ODUj. The current values of j
gives more information about LO ODU. defined in [G709-V3] are: 0, 1, 2, 2e, 3, 4, Flex. The approximate
bit rates of these signals are defined in [G709-V3A2] and are
The current values of j defined in [G709-V3] are: 0, 1, 2, 2e, 3, 4, reproduced in Tables 1 and 2.
Flex. The approximate bit rates of these signals are defined in
[G709-V3] and are reproduced in Tables 1 and 2.
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| ODU Type | ODU nominal bit rate | | ODU Type | ODU nominal bit rate |
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| ODU0 | 1 244 160 kbits/s | | ODU0 | 1,244,160 kbits/s |
| ODU1 | 239/238 x 2 488 320 kbit/s | | ODU1 | 239/238 x 2,488,320 kbit/s |
| ODU2 | 239/237 x 9 953 280 kbit/s | | ODU2 | 239/237 x 9,953,280 kbit/s |
| ODU3 | 239/236 x 39 813 120 kbit/s | | ODU3 | 239/236 x 39,813,120 kbit/s |
| ODU4 | 239/227 x 99 532 800 kbit/s | | ODU4 | 239/227 x 99,532,800 kbit/s |
| ODU2e | 239/237 x 10 312 500 kbit/s | | ODU2e | 239/237 x 10,312,500 kbit/s |
| | | | | |
| ODUflex for CBR | | | ODUflex for | |
| Client signals | 239/238 x client signal bit rate | |Constant Bit Rate (CBR)| 239/238 x client signal bit rate |
| Client signals | |
| | | | | |
| ODUflex for GFP-F | | | ODUflex for Generic | |
| Mapped client signal | Configured bit rate | | Framing Procedure | Configured bit rate |
| - Framed (GFP-F) | |
| Mapped client signal | |
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
Table 1 - ODU types and bit rates Table 1 - ODU types and bit rates
NOTE - The nominal ODUk rates are approximately: 2 498 775.126 kbit/s NOTE - The nominal ODUk rates are approximately: 2,498,775.126 kbit/s
(ODU1), 10 037 273.924 kbit/s (ODU2), 40 319 218.983 kbit/s (ODU3), (ODU1), 10,037,273.924 kbit/s (ODU2), 40,319,218.983 kbit/s (ODU3),
104 794 445.815 kbit/s (ODU4) and 10 399 525.316 kbit/s (ODU2e). 104,794,445.815 kbit/s (ODU4) and 10,399,525.316 kbit/s (ODU2e).
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| 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 |
skipping to change at page 6, line 30 skipping to change at page 6, line 30
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
Table 2 - ODU types and tolerance Table 2 - ODU types and tolerance
One of two options is for mapping client signals into ODUflex One of two options is for mapping client signals into ODUflex
depending on the client signal type: depending on the client signal type:
- Circuit clients are proportionally wrapped. Thus the bit rate and - Circuit clients are proportionally wrapped. Thus the bit rate and
tolerance are defined by the client signal. tolerance are defined by the client signal.
- Packet clients are mapped using the Generic Framing Procedure - Packet clients are mapped using the Generic Framing Procedure
(GFP). [G709-V3] recommends that the ODUflex(GFP) will fill an (GFP). [G709-V3A2] recommends that the ODUflex(GFP) will fill an
integral number of tributary slots of the smallest HO ODUk path integral number of tributary slots of the smallest HO ODUk path
over which the ODUflex(GFP) may be carried, and the tolerance over which the ODUflex(GFP) may be carried, and the tolerance
should be +/-100ppm. should be +/-100ppm.
3.1.2. Multiplexing ODUj onto Links 3.1.2. Multiplexing ODUj onto Links
The links between the switching nodes are provided by one or more The links between the switching nodes are provided by one or more
wavelengths. Each wavelength carries one OCh, which carries one OTU, wavelengths. Each wavelength carries one OCh, which carries one OTU,
which carries one ODU. Since all of these signals have a 1:1:1 which carries one ODU. Since all of these signals have a 1:1:1
relationship, we only refer to the OTU for clarity. The ODUjs are relationship, we only refer to the OTU for clarity. The ODUjs are
mapped into the TS of the OPUk. Note that in the case where j=k the mapped into the TS of the OPUk. Note that in the case where j=k the
ODUj is mapped into the OTU/OCh without multiplexing. ODUj is mapped into the OTU/OCh without multiplexing.
The initial versions of G.709 [G709-V1] only provided a single TS The initial versions of G.709 [G709-V1] only provided a single TS
granularity, nominally 2.5Gb/s. [G709-V3], approved in 2009, added an granularity, nominally 2.5Gb/s. [G709-V3] added an additional TS
additional TS granularity, nominally 1.25Gb/s. The number and type of granularity, nominally 1.25Gb/s. The number and type of TSs provided
TSs provided by each of the currently identified OTUk is provided by each of the currently identified OTUk is provided below:
below:
Tributary Slot Granularity
2.5Gb/s 1.25Gb/s Nominal Bit rate 2.5Gb/s 1.25Gb/s Nominal Bit rate
OTU1 1 2 2.5Gb/s OTU1 1 2 2.5Gb/s
OTU2 4 8 10Gb/s OTU2 4 8 10Gb/s
OTU3 16 32 40Gb/s OTU3 16 32 40Gb/s
OTU4 -- 80 100Gb/s OTU4 -- 80 100Gb/s
To maintain backwards compatibility while providing the ability to To maintain backwards compatibility while providing the ability to
interconnect nodes that support 1.25Gb/s TS at one end of a link and interconnect nodes that support 1.25Gb/s TS at one end of a link and
2.5Gb/s TS at the other, the 'new' equipment will fall back to the 2.5Gb/s TS at the other, the 'new' equipment will fall back to the
use of a 2.5Gb/s TS if connected to legacy equipment. This use of a 2.5Gb/s TS if connected to legacy equipment. This
information is carried in band by the payload type. information is carried in band by the payload type.
The actual bit rate of the TS in an OTUk depends on the value of k. The actual bit rate of the TS in an OTUk depends on the value of k.
Thus the number of TS occupied by an ODUj may vary depending on the Thus the number of TS occupied by an ODUj may vary depending on the
values of j and k. For example an ODU2e uses 9 TS in an OTU3 but values of j and k. For example an ODU2e uses 9 TS in an OTU3 but only
only 8 in an OTU4. Examples of the number of TS used for various 8 in an OTU4. Examples of the number of TS used for various cases are
cases are provided below: provided below (Referring to Table 7-9 of [G709-V3A2]):
- ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS - ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS
granularity granularity
o ODU0 occupies 1 of the 2, 8, 32 or 80 TS for ODU1, ODU2, ODU3 o ODU0 occupies 1 of the 2, 8, 32 or 80 TS for ODU1, ODU2, ODU3
or ODU4 or ODU4
- ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS - ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS
granularity granularity
o ODU1 occupies 2 of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4 o ODU1 occupies 2 of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4
- ODU1 into ODU2, ODU3 multiplexing with 2.5Gbps TS granularity - ODU1 into ODU2, ODU3 multiplexing with 2.5Gbps TS granularity
o ODU1 occupies 1 of the 4 or 16 TS for ODU2 or ODU3 o ODU1 occupies 1 of the 4 or 16 TS for ODU2 or ODU3
- ODU2 into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity - ODU2 into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity
o ODU2 occupies 8 of the 32 or 80 TS for ODU3 or ODU4 o ODU2 occupies 8 of the 32 or 80 TS for ODU3 or ODU4
skipping to change at page 8, line 11 skipping to change at page 8, line 14
- ODUflex into ODU2, ODU3 or ODU4 multiplexing with 1.25Gbps TS - ODUflex into ODU2, ODU3 or ODU4 multiplexing with 1.25Gbps TS
granularity granularity
o ODUflex occupies n of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4 o ODUflex occupies n of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4
(n <= Total TS numbers of ODUk) (n <= Total TS numbers of ODUk)
- ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity - ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity
o ODU2e occupies 9 of the 32 TS for ODU3 or 8 of the 80 TS for o ODU2e occupies 9 of the 32 TS for ODU3 or 8 of the 80 TS for
ODU4 ODU4
In general the mapping of an ODUj (including ODUflex) into the OTUk In general the mapping of an ODUj (including ODUflex) into a specific
TSs is determined locally, and it can also be explicitly controlled OTUk TSs is determined locally, and it can also be explicitly
by a specific entity (e.g., head end, NMS) through Explicit Label controlled by a specific entity (e.g., head end, Network Management
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 a 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 Multiplex correct demultiplexing. This information, known as MSI, is
Structure Information (MSI), is transported in the OPUk overhead and transported in the OPUk overhead and is local to each link. In case
is local to each link. In case of bidirectional paths the association of bidirectional paths the association between TPN and TS must be the
between TPN and TS must be the same in both directions. 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.
- Tributary Port Number (TPN): the port number of the ODUj - TPN: the port number of the ODUj transported by the HO ODUk. The
transported by the HO ODUk. The TPN is the same for all the TSs TPN is the same for all the TSs assigned to the transport of the
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 a HO ODU3 is described by 4 entries
in the OPU3 overhead when the TS size is 2.5 Gbit/s, and by 8 entries in the OPU3 overhead when the TS size is 2.5 Gbit/s, and by 8 entries
when the TS size is 1.25 Gbit/s. when the TS size is 1.25 Gbit/s.
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]):
- The TxMSI information inserted in OPU (e.g., OPU3) overhead by the
source of the HO ODUk trail.
- The expectedMSI information that is used to check the acceptedMSI - The Transmitted MSI (TxMSI) information inserted in OPU (e.g.,
information. The acceptedMSI information is the MSI valued OPU3) overhead by the source of the HO ODUk trail.
received in-band, after a 3 frames integration.
The sink of the HO ODU trail checks the complete content of the - The expected MSI (ExMSI) information that is used to check the
acceptedMSI information against the expectedMSI. accepted MSI (AcMSI) information. The AcMSI information is the MSI
valued received in-band, after a three-frame integration.
If the acceptedMSI is different from the expectedMSI, then the As described in [G798-V4], the sink of the HO ODU trail checks the
traffic is dropped and a payload mismatch alarm is generated. 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 either by network management Provisioning of TPN can be performed either by network management
system or control plane. In the last case, control plane is also system or control plane. In the last case, 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. base.
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 optical channels (OCh). This document connectivity of ODU paths and OCh. This document focuses on the
focuses on the connection management of ODU paths. The management of connection management of ODU paths. The management of OCh paths is
OCh paths is described in [RFC6163]. described in [RFC6163].
While [G872-2001] considered the ODU as a set of layers in the same While [G872-2001] considered the ODU as a set of layers in the same
way as SDH has been modeled, recent ITU-T OTN architecture progress way as SDH has been modeled, recent ITU-T OTN architecture progress
[G872-Am2] includes an agreement to model the ODU as a single layer [G872-Am2] includes an agreement to model the ODU as a single layer
network with the bit rate as a parameter of links and connections. network with the bit rate as a parameter of links and connections.
This allows the links and nodes to be viewed in a single topology as This allows the links and nodes to be viewed in a single topology as
a common set of resources that are available to provide ODUj a common set of resources that are available to provide ODUj
connections independent of the value of j. Note that when the bit connections independent of the value of j. Note that when the bit
rate of ODUj is less than the server bit rate, ODUj connections are rate of ODUj is less than the server bit rate, ODUj connections are
supported by HO-ODU (which has a one-to-one relationship with the supported by HO ODU (which has a one-to-one relationship with the
OTU). OTU).
From an ITU-T perspective, the ODU connection topology is represented From an ITU-T perspective, the ODU connection topology is represented
by that of the OTU link layer, which has the same topology as that of by that of the OTU link layer, which has the same topology as that of
the OCh layer (independent of whether the OTU supports HO-ODU, where the OCh layer (independent of whether the OTU supports HO ODU, where
multiplexing is utilized, or LO-ODU in the case of direct mapping). multiplexing is utilized, or LO ODU in the case of direct mapping).
Thus, the OTU and OCh layers should be visible in a single Thus, the OTU and OCh layers should be visible in a single
topological representation of the network, and from a logical topological representation of the network, and from a logical
perspective, the OTU and OCh may be considered as the same logical, perspective, the OTU and OCh may be considered as the same logical,
switchable entity. switchable entity.
Note that the OTU link layer topology may be provided via various Note that the OTU link layer topology may be provided via various
infrastructure alternatives, including point-to-point optical infrastructure alternatives, including point-to-point optical
connections, flexible optical connections fully in the optical domain, connections, flexible optical connections fully in the optical domain,
flexible optical connections involving hybrid sub-lambda/lambda nodes flexible optical connections involving hybrid sub-lambda/lambda nodes
involving 3R, etc. involving 3R, etc.
The document will be updated to maintain consistency with G.872
progress when it is consented for publication.
4.1. Connection management of the ODU 4.1. Connection management of the ODU
LO ODUj can be either mapped into the OTUk signal (j = k), or LO ODUj can be either mapped into the OTUk signal (j = k), or
multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is
mapped into an OCh. See Appendix A for more information. mapped into an OCh.
From the perspective of control plane, there are two kinds of network From the perspective of control plane, there are two kinds of network
topology to be considered. topology to be considered.
(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,
which is illustrated in Figure 2. In this layer there are ODU links as illustrated in Figure 2. In this layer there are ODU links with a
with a variety of TSs available, and nodes that are ODXCs. Lo ODU variety of TSs available, and nodes that are Optical Digital Cross
connections can be setup based on the network topology. Connects (ODXCs). Lo ODU connections can be setup based on the
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 | |
| |--------| |--------| |--------| | | |--------| |--------| |--------| |
skipping to change at page 10, line 47 skipping to change at page 10, line 48
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 TS available and that offers the lowest cost. Signaling is
then invoked to set up the path and to provide the information (e.g., then invoked to set up the path and to provide the information (e.g.,
selected TS) required by each transit node to allow the configuration selected TS) required by each transit node to allow the configuration
of the ODUj to OTUk mapping (j = k) or multiplexing (j < k), and of the ODUj to OTUk mapping (j = k) or multiplexing (j < k), and
demapping (j = k) or demultiplexing (j < k). 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., ROADM, OXC) that are capable of OCh switching, which is node (e.g., Reconfiguration Optical Add/Drop Multiplexer (ROADM),
illustrated in Figure 3 and Figure 4. There are ODU layer and OCh Optical Cross-Connect (OXC)) that are capable of OCh switching, which
layer, so it is simply a MLN. OCh connections may be created on is illustrated in Figure 3 and Figure 4. There are ODU layer and OCh
demand, which is described in section 5.1. layer, so it is simply a Multi-Layer Networks (MLN). OCh connections
may be created on demand, which is described in section 5.1.
In this case, an operator may choose to allow the underlined OCh In this case, an operator may choose to allow the underlined 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 below, instead, a cloud representing OCh capable switching nodes is
represented. In Figure 3, the operator choice is to hide the real RWA represented. In Figure 3, the operator choice is to hide the real OCh
network topology. layer network topology.
Node E Node E
Link #5 +--------+ Link #4 Link #5 +--------+ Link #4
+------------------------| |------------------------+ +------------------------| |------------------------+
| ------ | | ------ |
| // \\ | | // \\ |
| || || | | || || |
| | RWA 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 - RWA 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 - RWA 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 substitute by the real In Figure 4, the cloud of previous figure is substitute by the real
topology. The nodes f, g, h are nodes with OCH switching capability. topology. The nodes f, g, 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., Figure 3 and Figure 4), we have considered the
case in which LO-ODUj connections are supported by OCh connection, case in which LO ODUj connections are supported by OCh connection,
and the case in which the supporting underlying connection can be and the case in which the supporting underlying connection can be
also made by a combination of HO-ODU/OCh connections. also 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 RWA 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 ODU level as a Forwarding Adjacency,
which will be used to create the ODU connection. 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 LSP Hierarchy with GMPLS TE 5.1. Implications for Label Switch Path (LSP) Hierarchy
The path computation for ODU connection request is based on the The path computation for ODU connection request is based on the
topology of ODU layer, including OCh layer visibility. topology of 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 is
OCh/OTUk, the other is ODUj. [RFC4206] and [RFC6107] define the 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], [RFC6107] and related MLN drafts. defined in [RFC4206], [RFC6107] and related MLN drafts.
As discussed in section 4, the route path computation for OCh is in As discussed in section 4, the route path computation for OCh is in
the scope of WSON [RFC6163]. Therefore, this document only considers the scope of Wavelength Switched Optical Network (WSON) [RFC6163].
ODU layer for ODU connection request. Therefore, this document only considers ODU layer for ODU connection
request.
LSP hierarchy can also be applied within the ODU layers. One of the LSP hierarchy can also be applied within the ODU layers. One of the
typical scenarios for ODU layer hierarchy is to maintain typical scenarios for ODU layer hierarchy is to maintain
compatibility with introducing new [G709-V3] services (e.g., ODU0, compatibility with introducing new [G709-V3] services (e.g., ODU0,
ODUflex) into a legacy network configuration (containing [G709-V1] or ODUflex) into a legacy network configuration (containing [G709-V1] or
[G709-V2] OTN equipment). In this scenario, it may be needed to [G709-V2] OTN equipment). In this scenario, it may be needed to
consider introducing hierarchical multiplexing capability in specific consider introducing hierarchical multiplexing capability in specific
network transition scenarios. One method for enabling multiplexing network transition scenarios. One method for enabling multiplexing
hierarchy is by introducing dedicated boards in a few specific places hierarchy is by introducing dedicated boards in a few specific places
in the network and tunneling these new services through [G709-V1] or in the network and tunneling these new services through [G709-V1] or
skipping to change at page 13, line 18 skipping to change at page 13, line 21
planning, or by the signaling of the inner ODUj connection. For the planning, or by the signaling of the inner ODUj connection. For the
former case, the outer ODUk connection can be created in advance former case, the outer ODUk connection can be created in advance
based on network planning. For the latter case, the multi-layer based on network planning. For the latter case, the multi-layer
network signaling described in [RFC4206], [RFC6107] and [RFC6001] network signaling described in [RFC4206], [RFC6107] and [RFC6001]
(including related modifications, if needed) are relevant to create (including related modifications, if needed) are relevant to create
the ODU connections with multiplexing hierarchy. In both cases, the the ODU connections with multiplexing hierarchy. In both cases, the
outer ODUk connection is advertised as a Forwarding Adjacency (FA). outer ODUk connection is advertised as a Forwarding Adjacency (FA).
5.2. Implications for GMPLS Signaling 5.2. Implications for GMPLS Signaling
The signaling function and Resource reSerVation Protocol-Traffic The signaling function and RSVP-TE extensions are described in
Engineering (RSVP-TE) extensions are described in [RFC3471] and [RFC [RFC3471] and [RFC 3473]. For OTN-specific control, [RFC4328] defines
3473]. For OTN-specific control, [RFC4328] defines signaling signaling extensions to support G.709 Optical Transport Networks
extensions to support G.709 Optical Transport Networks Control as Control as defined in [G709-V1].
defined in [G709-V1].
As described in Section 3, [G709-V3] introduced some new features As described in Section 3, [G709-V3] introduced some new features
that include the ODU0, ODU2e, ODU4 and ODUflex containers. The that include the ODU0, ODU2e, ODU4 and ODUflex containers. The
mechanisms defined in [RFC4328] do not support such new OTN features, mechanisms defined in [RFC4328] do not support such new OTN features,
and protocol extensions will be necessary to allow them to be and protocol extensions will be necessary to allow them to be
controlled by a GMPLS control plane. controlled by a GMPLS control plane.
[RFC4328] defines the LSP Encoding Type, the Switching Type and the [RFC4328] defines the LSP Encoding Type, the Switching Type and the
Generalized Protocol Identifier (Generalized-PID) constituting the Generalized Protocol Identifier (Generalized-PID) constituting the
common part of the Generalized Label Request. The G.709 Traffic common part of the Generalized Label Request. The G.709 Traffic
Parameters are also defined in [RFC4328]. The following signaling Parameters are also defined in [RFC4328]. The following signaling
aspects should be considered additionally since [RFC4328] was aspects should be considered additionally since [RFC4328] was
published: published:
- Support for specifying the new signal types and the related - Support for specifying the new signal types and the related
traffic information traffic information
The traffic parameters should be extended in signaling message to The traffic parameters should be extended in signaling message to
support the new optical Channel Data Unit (ODUj) including: support the new ODUj including:
- ODU0 - ODU0
- ODU2e - ODU2e
- ODU4 - ODU4
- ODUflex - ODUflex
For ODUflex, since it has a variable bandwidth/bit rate BR and a For ODUflex, since it has a variable bandwidth/bit rate BR and a
bit rate tolerance T, the (node local) mapping process should be bit rate tolerance T, the (node local) mapping process should be
aware of the bit rate and tolerance of the ODUj being multiplexed aware of the bit rate and tolerance of the ODUj being multiplexed
in order to select the correct number of TS and the fixed/variable in order to select the correct number of TS and the fixed/variable
skipping to change at page 14, line 16 skipping to change at page 14, line 18
connection setup request. connection setup request.
For other ODU signal types, the bit rates and tolerances of them For other ODU signal types, the bit rates and tolerances of them
are fixed and can be deduced from the signal types. are fixed and can be deduced from the signal types.
- Support for LSP setup using different Tributary Slot Granularity - Support for LSP setup using different Tributary Slot Granularity
(TSG) (TSG)
The signaling protocol should be able to identify the type of TS The signaling protocol should be able to identify the type of TS
(i.e., the 2.5 Gbps TS granularity and the new 1.25 Gbps TS (i.e., the 2.5 Gbps TS granularity and the new 1.25 Gbps TS
granularity) to be used for establishing an H-LSP which will be granularity) to be used for establishing an Hierarchical LSP which
used to carry service LSP(s) requiring specific TS type. will be used to carry service LSP(s) requiring specific TS type.
- 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
New label must be defined to carry the exact TS allocation A new label format must be defined to carry the exact TS
information related to the extended mapping and multiplexing allocation information related to the extended mapping and
hierarchy (For example, ODU0 into ODU2 multiplexing (with 1.25Gbps multiplexing hierarchy (For example, ODU0 into ODU2 multiplexing
TS granularity)), in order to setting up the ODU connection. (with 1.25Gbps TS granularity)), in order to setting up the ODU
connection.
- Support for Tributary Port Number allocation and negotiation - Support for TPN allocation and negotiation
Tributary Port Number needs to be configured as part of the MSI TPN needs to be configured as part of the MSI information (See
information (See more information in Section 3.1.2.1). A new more information in Section 3.1.2.1). A new extension object has
extension object has to be defined to carry TPN information if to be defined to carry TPN information if control plane is used to
control plane is used to configure MSI information. configure MSI information.
- Support for ODU Virtual Concatenation (VCAT) and Link Capacity - Support for ODU Virtual Concatenation (VCAT) and Link Capacity
Adjustment Scheme (LCAS) Adjustment Scheme (LCAS)
GMPLS signaling should support the creation of Virtual GMPLS signaling should support the creation of Virtual
Concatenation of ODUk signal with k=1, 2, 3. The signaling should Concatenation of ODUk signal with k=1, 2, 3. The signaling should
also support the control of dynamic capacity changing of a VCAT also support the control of dynamic capacity changing of a VCAT
container using LCAS ([G.7042]). [RFC6344] has a clear description container using LCAS ([G.7042]). [RFC6344] has a clear description
of VCAT and LCAS control in SONET/SDH and OTN networks. of VCAT and LCAS control in SONET/SDH and OTN networks.
- Support for Control of Hitless Adjustment of ODUflex (GFP) - Support for Control of Hitless Adjustment of ODUflex (GFP)
[G.7044] has been created in ITU-T to specify hitless adjustment [G.7044] has been created in ITU-T to specify Hitless Adjustment
of ODUflex (GFP) (HAO) that is used to increase or decrease the of ODUflex (GFP) (HAO) that is used to increase or decrease the
bandwidth of an ODUflex (GFP) that is transported in an OTN bandwidth of an ODUflex (GFP) that is transported in an OTN
network. network.
The procedure of ODUflex (GFP) adjustment requires the The procedure of ODUflex (GFP) adjustment requires the
participation of every node along the path. Therefore, it is participation of every node along the path. Therefore, it is
recommended to use the control plane signaling to initiate the recommended to use the control plane signaling to initiate the
adjustment procedure in order to avoid the manual configuration at adjustment procedure in order to avoid the manual configuration at
each node along the path. each node along the path.
From the perspective of control plane, the control of ODUflex From the perspective of control plane, the control of ODUflex
resizing is similar to control of bandwidth increasing and resizing is similar to control of bandwidth increasing and
decreasing described in [RFC3209]. Therefore, the SE style can be decreasing described in [RFC3209]. Therefore, the Shared Explicit
used for control of HAO. (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, it
needs to evaluate the available bandwidth on each candidate link. needs to evaluate the available bandwidth on each candidate link.
The routing protocol should be extended to convey some information to The routing protocol should be extended to convey sufficient
represent ODU TE topology. information to represent ODU Traffic Engineering (TE) topology.
GMPLS Routing [RFC4202] defines Interface Switching Capability
Descriptor of TDM which can be used for ODU. However, some issues
discussed below, should also be considered.
Interface Switching Capability Descriptors present a new constraint Interface Switching Capability Descriptors defined in [RFC4202]
for LSP path computation. [RFC4203] defines the switching capability present a new constraint for LSP path computation. [RFC4203]
and related Maximum LSP Bandwidth and the Switching Capability defines the switching capability and related Maximum LSP Bandwidth
specific information. When the Switching Capability field is TDM the and the Switching Capability specific information. When the Switching
Switching Capability Specific Information field includes Minimum LSP Capability field is TDM the Switching Capability Specific Information
Bandwidth, an indication whether the interface supports Standard or field includes Minimum LSP Bandwidth, an indication whether the
Arbitrary SONET/SDH, and padding. Hence a new Switching Capability interface supports Standard or Arbitrary SONET/SDH, and padding.
value needs to be defined for [G709-V3] ODU switching in order to Hence a new Switching Capability value needs to be defined for [G709-
allow the definition of a new Switching Capability Specific V3] ODU switching in order to allow the definition of a new Switching
Information field definition. The following requirements should be Capability Specific Information field definition. The following
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 As discussed in section 3.1.2, many different types of ODUj can
be multiplexed into the same OTUk. For example, both ODU0 and be multiplexed into the same OTUk. For example, both ODU0 and
ODU1 may be multiplexed into ODU2. An OTU link may support one or ODU1 may be multiplexed into ODU2. An OTU link may support one or
more types of ODUj signals. The routing protocol should be more types of ODUj signals. The routing protocol should be
capable of carrying this multiplexing capability. capable of carrying this multiplexing capability.
- Support any ODU and ODUflex - Support any ODU and ODUflex
skipping to change at page 16, line 26 skipping to change at page 16, line 26
Therefore, the routing protocol should be capable of carrying the Therefore, the routing protocol should be capable of carrying the
necessary and sufficient link bandwidth information for necessary and sufficient link bandwidth information for
performing accurate route computation for any of the fixed rate performing accurate route computation for any of the fixed rate
ODUs as well as ODUflex. ODUs as well as ODUflex.
- Support for differentiating between terminating and switching - 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 being advertised by an interface could be just switched signal being advertised by an interface could be restricted to
(i.e. forwarded to switching matrix without switched (i.e. forwarded to switching matrix without
multiplexing/demultiplexing actions), just terminated (demuxed) multiplexing/demultiplexing actions), restricted to terminated
or both of them. The capability advertised by an interface needs (demuxed) or both of them. The capability advertised by an
further distinction in order to separate termination and interface needs further distinction in order to separate
switching capabilities. termination and switching capabilities.
Therefore, to allow the required flexibility, the routing Therefore, to allow the required flexibility, the routing
protocol should clearly distinguish the terminating and switching protocol should clearly distinguish the terminating and switching
capability. capability.
- Support for Tributary Slot Granularity advertisement - Support for Tributary Slot Granularity advertisement
[G709-V3] defines two types of TS but each link can only support [G709-V3] defines two types of TS but each link can only support
a single type at a given time. In order to perform a correct path a single type at a given time. In order to perform a correct path
computation (i.e. the LSP end points have matching Tributary Slot computation (i.e. the LSP end points have matching Tributary Slot
skipping to change at page 17, line 7 skipping to change at page 17, line 7
- Support different priorities for resource reservation - Support different priorities for resource reservation
How many priorities levels should be supported depends on the How many priorities levels should be supported depends on the
operator's policy. Therefore, the routing protocol should be operator's policy. Therefore, the routing protocol should be
capable of supporting either no priorities or up to 8 priority capable of supporting either no priorities or up to 8 priority
levels as defined in [RFC4202]. levels as defined in [RFC4202].
- Support link bundling - Support link bundling
Link bundling can improve routing scalability by reducing the As described in [RFC4201], link bundling can improve routing
amount of TE links that has to be handled by routing protocol. scalability by reducing the amount of TE links that has to be
The routing protocol should be capable of supporting bundling handled by routing protocol. The routing protocol should be
multiple OTU links, at the same line rate and muxing hierarchy, capable of supporting bundling multiple OTU links, at the same
between a pair of nodes as a TE link. Note that link bundling is line rate and muxing hierarchy, between a pair of nodes as a TE
optional and is implementation dependent. link. Note that link bundling is optional and is 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 the routing protocol should be capable of differentiating so the routing protocol should be capable of differentiating
whether an ODU link can support hitless adjustment of ODUflex whether an ODU link can support hitless adjustment of ODUflex
(GFP) or not, and how much resource can be used for resizing. (GFP) or not, and how much resource can be used for resizing.
This can be achieved by introducing a new signal type This can be achieved by introducing a new signal type
"ODUflex(GFP-F), resizable" that implies the support for hitless "ODUflex(GFP-F), resizable" that implies the support for hitless
adjustment of ODUflex (GFP) by that link. adjustment of 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, ODU3 containers. Such dedicated
boards may have some constraints with respect to switching matrix boards may have some constraints with respect to switching matrix
access; detection and representation of such constraints is for access; detection and representation of such constraints is for
further study. further study.
5.4. Implications for Link Management Protocol (LMP) 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.
The Link Management Protocol (LMP) [RFC4204] provides a control plane LMP [RFC4204] provides a control plane protocol for exchanging and
protocol for exchanging and correlating link capabilities. correlating link capabilities.
It is not necessary to use LMP to correlate link-end capabilities if It is not necessary to use LMP to correlate link-end capabilities if
the information is available from another source such as management the information is available from another source such as management
configuration or automatic discovery/negotiation within the data configuration or automatic discovery/negotiation within the data
plane. plane.
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 case, routing is not present (e.g. UNI case) routing. Since in certain case, routing is not present (e.g. User-
we need to extend link management protocol capabilities to cover this Network Interface (UNI) case) we need to extend link management
aspect. In case of routing presence, the discovering procedure by LMP protocol capabilities to cover this aspect. In case of routing
could also be optional. presence, the discovering procedure by 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.25Gb/s granularity should fall back to 2.5Gb/s node with 1.25Gb/s granularity should fall back to 2.5Gb/s
granularity. granularity.
Therefore, it is necessary for the two ends of a link to Therefore, it is necessary for the two ends of a link to
correlate the granularity of the TS. This ensures the correct use correlate the granularity of the TS. This ensures the correct use
skipping to change at page 18, line 37 skipping to change at page 18, line 37
supports ODU0 into ODU1 into ODU3 multiplexing while the other supports ODU0 into ODU1 into ODU3 multiplexing while the other
end supports ODU0 into ODU2 into ODU3 multiplexing). end supports ODU0 into ODU2 into ODU3 multiplexing).
For the control and management consideration, it is necessary for For the control and management consideration, it is necessary for
the two ends of an HO ODU link to correlate which types of LO ODU the two ends of an HO ODU link to correlate which types of LO ODU
can be supported and what multiplexing hierarchy capabilities can can be supported and what multiplexing hierarchy capabilities can
be provided by the other end. be provided by the other end.
5.5. Implications for Control Plane Backward Compatibility 5.5. Implications for Control Plane Backward Compatibility
With the introduction of G709-v3, there may be OTN networks composed With the introduction of [G709-V3], there may be OTN networks
of a mixture of nodes, some of which support [G709-V1] and run composed of a mixture of nodes, some of which support [G709-V1] and
control plane protocols defined in [RFC4328], while others support run control plane protocols defined in [RFC4328], while others
[G709-V3] and new OTN control plane characterized in this document. support [G709-V3] and 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,
G709-V1 nodes with a new OTN control plane, but such nodes can be consists on nodes supporting [G709-V1] with a new OTN control plane,
considered as new nodes with limited capabilities. but such nodes can be considered as new nodes with limited
capabilities.
This section discusses the compatibility of nodes implementing the This section discusses the compatibility of nodes implementing the
control plane procedures defined [RFC4328], in support of [G709-V1], control plane procedures defined [RFC4328], in support of [G709-V1],
and the control plane procedures defined to support [G709-V3], as and the control plane procedures defined to support [G709-V3], as
outlined by this document. outlined by this document.
Compatibility needs to be considered only when controlling ODU1 or Compatibility needs to be considered only when controlling ODU1 or
ODU2 or ODU3 connection, because [G709-V1] only support these three ODU2 or ODU3 connection, because [G709-V1] only support these three
ODU signal types. In such cases, there are several possible options ODU signal types. In such cases, there are several possible options
including: including:
skipping to change at page 19, line 34 skipping to change at page 19, line 37
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
[PCE-APS] describes the requirements for GMPLS applications of PCE in [PCE-APS] 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 PCC or another PCE requests a path attributes appropriately once a Path Computation Client (PCC) or
computation. The TE attributes which can be contained in the path another PCE requests a path computation. The TE attributes which can
calculation request message from the PCC or the PCE defined in be contained in the path calculation request message from the PCC or
[RFC5440] includes switching capability, encoding type, signal type, the PCE defined in [RFC5440] includes switching capability, encoding
etc. type, signal type, etc.
As described in section 5.2.1, new signal types and new signals with As described in section 5.2.1, 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, PCECP signaling message of path setup. For the same consideration, PCE
also has a desire to be extended to carry the new signal type and Communication Protocol (PCECP) also has a desire to be extended to
related variable bandwidth information when a PCC requests a path carry the new signal type and related variable bandwidth information
computation. when a PCC requests a path computation.
6. Data Plane Backward Compatibility Considerations 6. Data Plane Backward Compatibility Considerations
If TS auto-negotiation is supported, a node supporting 1.25Gbps TS If TS auto-negotiation is supported, a node supporting 1.25Gbps TS
can interwork with the other nodes that supporting 2.5Gbps TS by can interwork with the other nodes that supporting 2.5Gbps TS by
combining Specific TSs together in data plane. The control plane must combining Specific TSs together in data plane. The control plane must
support this TS combination. support this TS combination.
Path Path
+----------+ ------------> +----------+ +----------+ ------------> +----------+
skipping to change at page 20, line 35 skipping to change at page 20, line 35
Figure 5 - Interworking between 1.25Gbps TS and 2.5Gbps TS Figure 5 - Interworking between 1.25Gbps TS and 2.5Gbps 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.5Gbps TS while
node B supports the 1.25Gbps TS. In this case, the TS#i and TS#i+4 node B supports the 1.25Gbps TS. In this case, the TS#i and TS#i+4
(where i<=4) of node B are combined together. When creating an ODU1 (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 service in this ODU2 link, node B reserves the TS#i and TS#i+4 with
the granularity of 1.25Gbps. But in the label sent from B to A, it is the granularity of 1.25Gbps. But in the label sent from B to A, it is
indicated that the TS#i with the granularity of 2.5Gbps is reserved. indicated that the TS#i with the granularity of 2.5Gbps is reserved.
In the contrary 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.5Gbps is reserved,
node B will reserved the TS#i and TS#i+4 with the granularity of node B will reserved the TS#i and TS#i+4 with the granularity of
1.25Gbps in its data plane. 1.25Gbps in its data plane.
7. Security Considerations 7. Security Considerations
The use of control plane protocols for signaling, routing, and path The use of control plane protocols for signaling, routing, and path
computation opens an OTN to security threats through attacks on those computation opens an OTN to security threats through attacks on those
protocols. The data plane technology for an OTN does not introduce protocols. Although, this is not greater than the risks presented by
any specific vulnerabilities, and so the control plane may be secured the existing OTN control plane as defined by [RFC4203] and [RFC4328].
using the mechanisms defined for the protocols discussed.
For further details of the specific security measures refer to the For further details of the specific security measures refer to the
documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], documents that define the protocols ([RFC3473], [RFC4203], [RFC4205],
[RFC4204], and [RFC5440]). [RFC5920] provides an overview of security [RFC4204], and [RFC5440]). [RFC5920] provides an overview of security
vulnerabilities and protection mechanisms for the GMPLS control plane. vulnerabilities and protection mechanisms for the GMPLS control plane.
8. IANA Considerations 8. IANA Considerations
This document makes not requests for IANA action. This document makes not requests for IANA action.
skipping to change at page 22, line 36 skipping to change at page 22, line 36
[RFC5440] JP. Vasseur, JL. Le Roux, Ed.," Path Computation Element [RFC5440] JP. Vasseur, JL. Le Roux, Ed.," Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, March (PCE) Communication Protocol (PCEP)", RFC 5440, March
2009. 2009.
[RFC6344] G. Bernstein et al, "Operating Virtual Concatenation [RFC6344] G. Bernstein et al, "Operating Virtual Concatenation
(VCAT) and the Link Capacity Adjustment Scheme (LCAS) (VCAT) and the Link Capacity Adjustment Scheme (LCAS)
with Generalized Multi-Protocol Label Switching (GMPLS)", with Generalized Multi-Protocol Label Switching (GMPLS)",
RFC6344, August, 2011. RFC6344, August, 2011.
[G709-V3] ITU-T, "Interfaces for the Optical Transport Network [G709-V3] ITU-T, "Interfaces for the Optical Transport Network
(OTN)", G.709 Recommendation and Amendment2, April 2011. (OTN)", G.709 Recommendation, December 2009.
[G709-V3A2] ITU-T, "Interfaces for the Optical Transport Network
(OTN)", G.709 Recommendation Amendment2, April 2011.
10.2. Informative References 10.2. Informative References
[G709-V1] ITU-T, "Interface for the Optical Transport Network [G709-V1] ITU-T, "Interface for the Optical Transport Network
(OTN)," G.709 Recommendation and Amendment1, November (OTN)," G.709 Recommendation (and Amendment 1), November
2001. 2001.
[G709-V2] ITU-T, "Interface for the Optical Transport Network [G709-V2] ITU-T, "Interface for the Optical Transport Network
(OTN)," G.709 Recommendation, March 2003. (OTN)," G.709 Recommendation, March 2003.
[G798-V4] ITU-T, "Characteristics of optical transport network
hierarchy equipment functional blocks", G.798
Recommendation, October 2010.
[G7042] ITU-T, "Link capacity adjustment scheme (LCAS) for [G7042] ITU-T, "Link capacity adjustment scheme (LCAS) for
virtual concatenated signals", G.7042/Y.1305, March 2006. virtual concatenated signals", G.7042/Y.1305, March 2006.
[G872-2001] ITU-T, "Architecture of optical transport networks", [G872-2001] ITU-T, "Architecture of optical transport networks",
G.872 Recommendation, November 2001. G.872 Recommendation, November 2001.
[G872-Am2] ITU-T, "Architecture of optical transport networks", [G872-Am2] ITU-T, "Architecture of optical transport networks",
G.872 Recommendation and Amendment 2, July 2010. G.872 Recommendation and Amendment 2, July 2010.
[G.7044] ITU-T, "Hitless adjustment of ODUflex", G.7044 (and [G.7044] ITU-T, "Hitless adjustment of ODUflex", G.7044 (and
skipping to change at page 25, line 20 skipping to change at page 25, line 25
Email: pietro_vittorio.grandi@alcatel-lucent.it Email: pietro_vittorio.grandi@alcatel-lucent.it
Eve Varma Eve Varma
Alcatel-Lucent Alcatel-Lucent
1A-261, 600-700 Mountain Av 1A-261, 600-700 Mountain Av
PO Box 636 PO Box 636
Murray Hill, NJ 07974-0636 Murray Hill, NJ 07974-0636
USA USA
Email: eve.varma@alcatel-lucent.com Email: eve.varma@alcatel-lucent.com
APPENDIX A: ODU connection examples
This appendix provides a description of ODU terminology and
connection examples. This section is not normative, and is just
intended to facilitate understanding.
In order to transmit a client signal, an ODU connection needs to be
created first. From the perspective of [G709-V3] and [G872-Am2], some
types of ODUs (i.e., ODU1, ODU2, ODU3, ODU4) may assume either a
client or server role within the context of a particular networking
domain:
(1) An ODUj client that is mapped into an OTUk server. For example,
if a STM-16 signal is encapsulated into ODU1, and then the ODU1 is
mapped into OTU1, the ODU1 is a LO ODU (from a multiplexing
perspective).
(2) An ODUj client that is mapped into an ODUk (j < k) server
occupying several TSs. For example, if ODU1 is multiplexed into ODU2,
and ODU2 is mapped into OTU2, the ODU1 is a LO ODU and the ODU2 is a
HO ODU (from a multiplexing perspective).
Thus, a LO ODUj 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. Consequently,
the HO ODUk represents the entity transporting a multiplex of LO ODUj
tributary signals in its OPUk area.
In the case of LO ODUj mapped into an OTUk (k = j) directly, Figure 6
give an example of this kind of LO ODU connection.
In Figure 6, The LO ODUj is switched at the intermediate ODXC node.
OCh and OTUk are associated with each other. From the viewpoint of
connection management, the management of OTUk is similar with OCh. LO
ODUj and OCh/OTUk have client/server relationships.
For example, one LO ODU1 connection can be setup between Node A and
Node C. This LO ODU1 connection is to be supported by OCh/OTU1
connections, which are to be set up between Node A and Node B and
between Node B and Node C. LO ODU1 can be mapped into OTU1 at Node A,
demapped from it in Node B, switched at Node B, and then mapped into
the next OTU1 and demapped from this OTU1 at Node C.
| LO ODUj |
+------------------------------(b)---------------------------+
| | OCh/OTUk | | OCh/OTUk | |
| +--------(a)---------+ +--------(a)---------+ |
| | | | | |
+------++-+ +--+---+--+ +-++------+
| |EO| |OE| |EO| |OE| |
| +--+----------------+--+ +--+----------------+--+ |
| ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+
Node A Node B Node C
Figure 6 - Connection of LO ODUj (1)
In the case of LO ODUj multiplexing into HO ODUk, Figure 7 gives an
example of this kind of LO ODU connection.
In Figure 7, OCh, OTUk, HO ODUk are associated with each other. The
LO ODUj is multiplexed/de-multiplexed into/from the HO ODU at each
ODXC node and switched at each ODXC node (i.e. trib port to line port,
line card to line port, line port to trib port). From the viewpoint
of connection management, the management of these HO ODUk and OTUk
are similar to OCh. LO ODUj and OCh/OTUk/HO ODUk have client/server
relationships. When a LO ODU connection is setup, it will be using
the existing HO ODUk (/OTUk/OCh) connections which have been set up.
Those HO ODUk connections provide LO ODU links, of which the LO ODU
connection manager requests a link connection to support the LO ODU
connection.
For example, one HO ODU2 (/OTU2/OCh) connection can be setup between
Node A and Node B, another HO ODU3 (/OTU3/OCh) connection can be
setup between Node B and Node C. LO ODU1 can be generated at Node A,
switched to one of the 10G line ports and multiplexed into a HO ODU2
at Node A, demultiplexed from the HO ODU2 at Node B, switched at Node
B to one of the 40G line ports and multiplexed into HO ODU3 at Node B,
demultiplexed from HO ODU3 at Node C and switched to its LO ODU1
terminating port at Node C.
| LO ODUj |
+----------------------------(b)-----------------------------+
| | OCh/OTUk/HO ODUk | | OCh/OTUk/HO ODUk | |
| +--------(c)---------+ +---------(c)--------+ |
| | | | | |
+------++-+ +--+---+--+ +-++------+
| |EO| |OE| |EO| |OE| |
| +--+----------------+--+ +--+----------------+--+ |
| ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+
Node A Node B Node C
Figure 7 - Connection of LO ODUj (2)
Intellectual Property Intellectual Property
The IETF Trust takes no position regarding the validity or scope of The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. such rights.
 End of changes. 80 change blocks. 
289 lines changed or deleted 202 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/