draft-ietf-ccamp-gmpls-g709-framework-12.txt   draft-ietf-ccamp-gmpls-g709-framework-13.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: August 21, 2013 February 21, 2013 Expires: December 18, 2013 June 18, 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-12.txt draft-ietf-ccamp-gmpls-g709-framework-13.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 August 21, 2013. This Internet-Draft will expire on December 18, 2013.
Abstract Abstract
This document provides a framework to allow the development of This document provides a framework to allow the development of
protocol extensions to support Generalized Multi-Protocol Label protocol extensions to support Generalized Multi-Protocol Label
Switching (GMPLS) and Path Computation Element (PCE) control of Switching (GMPLS) and Path Computation Element (PCE) control of
Optical Transport Networks (OTN) as specified in ITU-T Recommendation Optical Transport Networks (OTN) as specified in ITU-T Recommendation
G.709 as published in 2012. G.709 as published in 2012.
Table of Contents Table of Contents
skipping to change at page 2, line 25 skipping to change at page 2, line 25
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 Label Switch Path (LSP) Hierarchy ...... 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 ............... 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 ............. 19
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
1. Introduction 1. Introduction
skipping to change at page 3, line 12 skipping to change at page 3, line 12
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 protocol suite including provision [RFC4328] provides the The GMPLS signaling extensions defined in [RFC4328] provide 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. Later revisions of the G.709 revision of the G.709 specification. The 2012 revision of the G.709
specification, i.e., [G709-2012], has included some new features; for specification, [G709-2012], includes new features, for example,
example, various multiplexing structures, two types of Tributary various multiplexing structures, two types of Tributary Slots (TSs)
Slots (TSs) (i.e., 1.25Gbps and 2.5Gbps), and extension of the (i.e., 1.25Gbps and 2.5Gbps), and extension of the Optical channel
Optical channel Data Unit-j (ODUj) definition to include the ODUflex Data Unit-j (ODUj) definition to include the ODUflex function.
function.
This document reviews relevant aspects of OTN technology evolution This document reviews relevant aspects of OTN technology evolution
that affect the GMPLS control plane protocols and examines why and that affect the GMPLS control plane protocols and examines why and
how to update the mechanisms described in [RFC4328]. This document how to update the mechanisms described in [RFC4328]. This document
additionally provides a framework for the GMPLS control of OTN additionally provides a framework for the GMPLS control of OTN
networks and includes a discussion of the implication for the use of networks and includes a discussion of the implication for the use of
the PCE [RFC4655]. the PCE [RFC4655].
For the purposes of the control plane the OTN can be considered as For the purposes of the control plane the OTN can be considered as
being comprised of ODU and wavelength (Optical Channel (OCh)) layers. being comprised of ODU and wavelength (Optical Channel (OCh)) layers.
skipping to change at page 4, line 14 skipping to change at page 4, line 14
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
bit rate tolerance of +/-100 ppm. bit rate tolerance of +/-100 ppm (parts per million).
3. G.709 Optical Transport Network 3. G.709 Optical Transport Network
This section provides an informative overview of those aspects of the This section provides an informative overview of those aspects of the
OTN impacting control plane protocols. This overview is based on the OTN impacting control plane protocols. This overview is based on the
ITU-T Recommendations that contain the normative definition of the ITU-T Recommendations that contain the normative definition of the
OTN. Technical details regarding OTN architecture and interfaces are OTN. Technical details regarding OTN architecture and interfaces are
provided in the relevant ITU-T Recommendations. provided in the relevant ITU-T Recommendations.
Specifically, [G872-2012] describes the functional architecture of Specifically, [G872-2012] describes the functional architecture of
skipping to change at page 5, line 21 skipping to change at page 5, line 21
The client signals are mapped into a LO ODUj. The current values of j The client signals are mapped into a LO ODUj. The current values of j
defined in [G709-2012] are: 0, 1, 2, 2e, 3, 4, Flex. The approximate defined in [G709-2012] are: 0, 1, 2, 2e, 3, 4, Flex. The approximate
bit rates of these signals are defined in [G709-2012] and are bit rates of these signals are defined in [G709-2012] and are
reproduced in Tables 1 and 2. reproduced in Tables 1 and 2.
Table 1 - ODU types and bit rates Table 1 - ODU types and bit rates
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| ODU Type | ODU nominal bit rate | | ODU Type | ODU nominal bit rate |
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| ODU0 | 1,244,160 kbits/s | | ODU0 | 1,244,160 Kbps |
| ODU1 | 239/238 x 2,488,320 kbit/s | | ODU1 | 239/238 x 2,488,320 Kbps |
| ODU2 | 239/237 x 9,953,280 kbit/s | | ODU2 | 239/237 x 9,953,280 Kbps |
| ODU3 | 239/236 x 39,813,120 kbit/s | | ODU3 | 239/236 x 39,813,120 Kbps |
| ODU4 | 239/227 x 99,532,800 kbit/s | | ODU4 | 239/227 x 99,532,800 Kbps |
| ODU2e | 239/237 x 10,312,500 kbit/s | | 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 kbit/s NOTE - The nominal ODUk rates are approximately: 2,498,775.126 Kbps
(ODU1), 10,037,273.924 kbit/s (ODU2), 40,319,218.983 kbit/s (ODU3), (ODU1), 10,037,273.924 Kbps (ODU2), 40,319,218.983 Kbps (ODU3),
104,794,445.815 kbit/s (ODU4) and 10,399,525.316 kbit/s (ODU2e). 104,794,445.815 Kbps (ODU4) and 10,399,525.316 Kbps (ODU2e).
Table 2 - ODU types and tolerance 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 |
skipping to change at page 6, line 36 skipping to change at page 6, line 36
- 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
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 TS of the OPUk. Note that in the case where j=k the mapped into the TSs (Tributary Slots) of the OPUk. Note that in the
ODUj is mapped into the OTU/OCh without multiplexing. case where j=k the ODUj is mapped into the OTU/OCh without
multiplexing.
The initial versions of G.709 referenced by [RFC4328] only provided a The initial versions of G.709 referenced by [RFC4328] only provided a
single TS granularity and nominally 2.5Gb/s. [G709-2012] added an single TS granularity, nominally 2.5Gbps. [G709-2012] added an
additional TS granularity, nominally 1.25Gb/s. The number and type of additional TS granularity, nominally 1.25Gbps. The number and type of
TSs provided by each of the currently identified OTUk is provided TSs provided by each of the currently identified OTUk is provided
below: below:
Tributary Slot Granularity Tributary Slot Granularity
2.5Gb/s 1.25Gb/s Nominal Bit rate 2.5Gbps 1.25Gbps Nominal Bit rate
OTU1 1 2 2.5Gb/s OTU1 1 2 2.5Gbps
OTU2 4 8 10Gb/s OTU2 4 8 10Gbps
OTU3 16 32 40Gb/s OTU3 16 32 40Gbps
OTU4 -- 80 100Gb/s OTU4 -- 80 100Gbps
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.25Gbps TS at one end of a link and
2.5Gb/s TS at the other, the 'new' equipment will fall back to the 2.5Gbps TS at the other, [G709-2012] requires 'new' equipment fall
use of a 2.5Gb/s TS if connected to legacy equipment. This back to the use of a 2.5Gbps TS when connected to legacy equipment.
information is carried in band by the payload type. 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 TS 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 TS in an OTU3 but only values of j and k. For example an ODU2e uses 9 TSs in an OTU3 but
8 in an OTU4. Examples of the number of TS used for various cases are only 8 in an OTU4. Examples of the number of TSs used for various
provided below (Referring to Table 7-9 of [G709-2012]): cases are provided below (Referring to Table 7-9 of [G709-2012]):
- ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS - ODU0 into ODU1, ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS
granularity granularity
o ODU0 occupies 1 of the 2, 8, 32 or 80 TS for ODU1, ODU2, ODU3 o ODU0 occupies 1 of the 2, 8, 32 or 80 TSs 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 TSs 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 TSs 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 TSs for ODU3 or ODU4
- ODU2 into ODU3 multiplexing with 2.5Gbps TS granularity - ODU2 into ODU3 multiplexing with 2.5Gbps TS granularity
o ODU2 occupies 4 of the 16 TS 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.25Gbps TS granularity
o ODU3 occupies 31 of the 80 TS 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.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 TSs for ODU2, ODU3 or
(n <= Total TS numbers 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.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 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 specific
OTUk TSs is determined locally, and it can also be explicitly 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, 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 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 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 TPN and TS must be the
skipping to change at page 8, line 41 skipping to change at page 8, line 41
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 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 granularity is 2.5Gbps, and by 8
when the TS size is 1.25 Gbit/s. entries when the TS granularity is 1.25Gbps.
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-V4]):
- 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 MSI
valued received in-band, after a three-frame integration. valued received in-band, after a three-frame integration.
skipping to change at page 9, line 48 skipping to change at page 9, line 48
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 connections, optical connections fully in the optical domain and
domain, flexible optical connections involving hybrid sub- optical connections involving hybrid sub-lambda/lambda nodes
lambda/lambda nodes involving 3R, etc. 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 LO ODUj can be either mapped into the OTUk signal (j = k), or
multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is
mapped into an OCh. mapped into an OCh.
From the perspective of control plane, there are two kinds of network From the perspective of control plane, there are two kinds of network
topology to be considered. topology to be considered.
skipping to change at page 10, line 43 skipping to change at page 10, line 41
| 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 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 TSs) required by each transit node to allow the
of the ODUj to OTUk mapping (j = k) or multiplexing (j < k), and configuration of the ODUj to OTUk mapping (j = k) or multiplexing (j
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), node (e.g., Reconfiguration Optical Add/Drop Multiplexer (ROADM),
Optical Cross-Connect (OXC)) that are capable of OCh switching, which Optical Cross-Connect (OXC)) that are capable of OCh switching, which
is illustrated in Figure 3 and Figure 4. There are ODU layer and OCh is illustrated in Figure 3 and Figure 4. There are ODU layer and OCh
layer, so it is simply a Multi-Layer Networks (MLN). OCh connections layer, so it is simply a Multi-Layer Networks (MLN) (see [RFC6001]).
may be created on demand, which is described in section 5.1.
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 OCh represented. In Figure 3, the operator choice is to hide the real OCh
layer network topology. layer network topology.
Node E Node E
Link #5 +--------+ Link #4 Link #5 +--------+ Link #4
skipping to change at page 12, line 34 skipping to change at page 12, line 34
5.1. Implications for Label Switch Path (LSP) Hierarchy 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. 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], [RFC6001] and [RFC6107], etc.
As discussed in section 4, the route path computation for OCh is in As discussed in section 4, the route path computation for OCh is in
the scope of Wavelength Switched Optical Network (WSON) [RFC6163]. the scope of Wavelength Switched Optical Network (WSON) [RFC6163].
Therefore, this document only considers ODU layer for ODU connection Therefore, this document only considers ODU layer for ODU connection
request. request.
LSP hierarchy can also be applied within the ODU layers. One of the LSP hierarchy can also be applied within the ODU layers. One of the
typical scenarios for ODU layer hierarchy is to maintain typical scenarios for ODU layer hierarchy is to maintain
compatibility with introducing new [G709-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 ODUflex) into a legacy network configuration (i.e., the legacy OTN
skipping to change at page 13, line 49 skipping to change at page 13, line 49
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 ODUj including: support the new ODUj including:
- ODU0 - ODU0
- ODU2e - ODU2e
- ODU4 - ODU4
- ODUflex - ODUflex
For ODUflex, since it has a variable bit rate and bit rate For ODUflex signal type, its bit rate must be carried additionally
tolerance that is always specified as +/-100 ppm per Table 7-2 of in the Traffic Parameter to setup an ODUflex connection.
[G709-2012], the (node local) mapping process should be 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 stuffing
bytes. Therefore, bit rate must be carried in the Traffic
Parameter in the signaling of connection setup request besides
considering the fixed bit rate tolerance, i.e., +/-100 ppm.
For other ODU signal types, their bit rates and tolerances are For other ODU signal types, their bit rates and tolerances are
fixed and can be deduced from the signal types. fixed and can be deduced from the signal types.
- Support for LSP setup using different Tributary Slot Granularity - Support for LSP setup using different TS granularity
(TSG)
The signaling protocol should be able to identify the type of TS The signaling protocol should be able to identify the TS
(i.e., the 2.5 Gbps TS granularity and the new 1.25 Gbps TS granularity (i.e., the 2.5Gbps TS granularity and the new 1.25Gbps
granularity) to be used for establishing an Hierarchical LSP which TS granularity) to be used for establishing an Hierarchical LSP
will be used to carry service LSP(s) requiring specific TS type. which will be used to carry service LSP(s) requiring specific 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 TS A new label format must be defined to carry the exact TSs
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 setting up the ODU (with 1.25Gbps 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 new extension object has more information in Section 3.1.2.1). A signaling mechanism must
to be defined to carry TPN information if control plane is used to be identified to carry TPN information if control plane is used to
configure MSI information. configure MSI information.
- Support for ODU Virtual Concatenation (VCAT) and Link Capacity - Support for ODU Virtual Concatenation (VCAT) and Link Capacity
Adjustment Scheme (LCAS) Adjustment Scheme (LCAS)
GMPLS signaling should support the creation of Virtual GMPLS signaling should support the creation of Virtual
Concatenation of ODUk signal with k=1, 2, 3. The signaling should Concatenation of ODUk signal with k=1, 2, 3. The signaling should
also support the control of dynamic capacity changing of a VCAT also support the control of dynamic capacity changing of a VCAT
container using LCAS ([G7042]). [RFC6344] has a clear description container using LCAS ([G7042]). [RFC6344] has a clear description
of VCAT and LCAS control in SONET/SDH and OTN networks. of VCAT and LCAS control in SONET/SDH and OTN networks.
skipping to change at page 16, line 4 skipping to change at page 15, line 44
- 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
The bit rate (i.e., bandwidth) of TS is dependent on the TS
The bit rate (i.e., bandwidth) of each TS is dependent on the TS
granularity and the signal type of the link. For example, the granularity and the signal type of the link. For example, the
bandwidth of a 1.25G TS in an OTU2 is about 1.249409620 Gbps, 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.254703729 while the bandwidth of a 1.25G TS in an OTU3 is about
Gbps. 1.254703729Gbps.
One LO ODU may need different number of TSs when multiplexed into One LO ODU may need different number of TSs when multiplexed into
different HO ODUs. For example, for ODU2e, 9 TSs are needed when different HO ODUs. For example, for ODU2e, 9 TSs are needed when
multiplexed into an ODU3, while only 8 TSs are needed when multiplexed into an ODU3, while only 8 TSs are needed when
multiplexed into an ODU4. For ODUflex, the total number of TSs to multiplexed into an ODU4. For ODUflex, the total number of TSs to
be reserved in a HO ODU equals the maximum of [bandwidth of be reserved in a HO ODU equals the maximum of [bandwidth of
ODUflex / bandwidth of TS of the HO ODU]. ODUflex / bandwidth of TS of the HO ODU].
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 link bandwidth information for performing accurate
performing accurate route computation for any of the fixed rate route computation for any of the fixed rate ODUs as well as
ODUs as well as ODUflex. 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 restricted to signal being advertised by an interface could be restricted to
switched (i.e. forwarded to switching matrix without switched (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 of them. The capability advertised by an
interface needs further distinction in order to separate interface needs further distinction in order to separate
skipping to change at page 16, line 49 skipping to change at page 16, line 44
[G709-2012] defines two types of TS but each link can only [G709-2012] defines two types of TS 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 end points 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 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 up to 8 priority levels as defined in
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 amount of TE links that has to be
handled by routing protocol. The routing protocol should be handled by routing protocol. The routing protocol should be
capable of supporting bundling multiple OTU links, at the same capable of supporting bundling multiple OTU links, at the same
line rate and muxing hierarchy, between a pair of nodes as a TE line rate and muxing hierarchy, between a pair of nodes as a TE
link. Note that link bundling is optional and is implementation link. Note that link bundling is optional and is implementation
dependent. dependent.
skipping to change at page 17, line 42 skipping to change at page 17, line 36
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.
It is not necessary to use LMP to correlate link-end capabilities if
the information is available from another source such as management
configuration or automatic discovery/negotiation within the data
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. User- routing. Since in certain cases, routing is not present (e.g. User-
Network Interface (UNI) case) we need to extend link management Network Interface (UNI) case) we need to extend link management
protocol capabilities to cover this aspect. In case of routing protocol capabilities to cover this aspect. In case of routing
presence, the discovering procedure by LMP could also be optional. presence, the 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.25Gb/s granularity should fall back to 2.5Gb/s node with 1.25Gbps granularity should fall back to 2.5Gbps
granularity. granularity.
Therefore, it is necessary for the two ends of a link to Therefore, it is necessary for the two ends of a link to
correlate the granularity of the TS. This ensures the correct use correlate the granularity of the TS. This ensures the correct use
and of the TE link. and of the TE link.
- Correlating the supported LO ODU signal types and multiplexing - Correlating the supported LO ODU signal types and multiplexing
hierarchy capability hierarchy capability
Many new ODU signal types have been introduced in [G709-2012], Many new ODU signal types have been introduced in [G709-2012],
skipping to change at page 20, line 7 skipping to change at page 19, line 44
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, PCE signaling message of path setup. For the same consideration, 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.
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 MI AUTOpayloadtype is activated (see [G798-V4]), a node supporting
can interwork with the other nodes that supporting 2.5Gbps TS by 1.25Gbps TS can interwork with the other nodes that supporting
combining Specific TSs together in data plane. The control plane must 2.5Gbps TS by combining Specific TSs together in data plane. The
support this TS combination. control 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 |
skipping to change at page 23, line 14 skipping to change at page 23, line 11
[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, [G7044] ITU-T, "Hitless adjustment of ODUflex", G.7044/Y.1347,
October 2011. October 2011.
[G7041] ITU-T, "Generic framing procedure", G.7041/Y.1303, April
2011.
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching
(GMPLS) Architecture", RFC 3945, October 2004. (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", Computation Element (PCE)-Based Architecture",
RFC 4655, August 2006. RFC 4655, August 2006.
[RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS
and PCE Control of Wavelength Switched Optical Networks and PCE Control of Wavelength Switched Optical Networks
(WSON)", RFC6163, April 2011. (WSON)", RFC6163, April 2011.
 End of changes. 45 change blocks. 
99 lines changed or deleted 96 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/