draft-ietf-ccamp-gmpls-g709-framework-01.txt   draft-ietf-ccamp-gmpls-g709-framework-02.txt 
Network Working Group Fatai Zhang Network Working Group Fatai Zhang
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
Expires: November 18, 2010 May 18, 2010 Expires: January 12, 2011 July 12, 2010
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-01.txt draft-ietf-ccamp-gmpls-g709-framework-02.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 37 skipping to change at page 1, line 37
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 November 18, 2010. This Internet-Draft will expire on January 12, 2011.
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 consented in October 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 (OTN).........................4
3.1. OTN Layer Network........................................4 3.1. OTN Layer Network........................................4
3.1.1. Client signal mapping...............................5
3.1.1.1. ODUj types and parameters......................6
3.1.2. Multiplexing ODUj onto Links........................7
3.1.2.1. Link Parameters................................8
3.1.2.2. Tributary Port Number Assignment...............9
4. Connection management in OTN.................................10 4. Connection management in OTN.................................10
4.1. Connection management of the ODU........................10 4.1. Connection management of the ODU........................10
5. GMPLS/PCE Implications.......................................13 5. GMPLS/PCE Implications.......................................13
5.1. Implications for LSP Hierarchy with GMPLS TE............13 5.1. Implications for LSP Hierarchy with GMPLS TE............13
5.2. Implications for GMPLS Signaling........................13 5.2. Implications for GMPLS Signaling........................13
5.2.1. Identifying OTN signals............................13 5.2.1. Identifying OTN signals............................14
5.2.2. Tributary Port Number..............................14 5.2.2. Tributary Port Number..............................15
5.2.3. Support for constraint signaling...................15
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 (LMP).........17
5.4.1. Correlating the Granularity of the TS..............17 5.4.1. Correlating the Granularity of the TS..............18
5.4.2. Correlating the Supported LO ODU Signal Types......17 5.4.2. Correlating the Supported LO ODU Signal Types......18
5.5. Implications for Path Computation Elements..............18 5.5. Implications for Path Computation Elements..............18
6. Security Considerations......................................18 6. Security Considerations......................................19
7. IANA Considerations..........................................18 7. IANA Considerations..........................................19
8. Acknowledgments..............................................18 8. Acknowledgments..............................................19
9. References...................................................19 9. References...................................................19
9.1. Normative References....................................19 9.1. Normative References....................................19
9.2. Informative References..................................20 9.2. Informative References..................................21
10. Authors' Addresses..........................................20 10. Authors' Addresses..........................................21
11. Contributors................................................21 11. Contributors................................................22
APPENDIX A: ODU connection examples.............................22 APPENDIX A: ODU connection examples.............................23
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 Generalized Multi-Protocol Label Switching (GMPLS) to OTN networks,
to realize the benefits associated with a high-function control plane to realize the benefits associated with a high-function control plane
(e.g., improved network resiliency, resource usage efficiency, etc.). (e.g., improved network resiliency, resource usage efficiency, etc.).
GMPLS extends MPLS to encompass time division multiplexing (TDM) GMPLS extends MPLS to encompass time division multiplexing (TDM)
networks (e.g., SONET/SDH, PDH, and G.709 sub-lambda), lambda networks (e.g., SONET/SDH, PDH, and G.709 sub-lambda), lambda
switching optical networks, and spatial switching (e.g., incoming switching optical networks, and spatial switching (e.g., incoming
port or fiber to outgoing port or fiber). The GMPLS architecture is port or fiber to outgoing port or fiber). The GMPLS architecture is
provided in [RFC3945], signaling function and Resource ReserVation provided in [RFC3945], signaling function and Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) extensions are described in Protocol-Traffic Engineering (RSVP-TE) extensions are described in
[RFC3471] and [RFC3473], routing and OSPF extensions are described in [RFC3471] and [RFC3473], routing and OSPF extensions are described in
[RFC4202] and [RFC4203], and the Link Management Protocol (LMP) is [RFC4202] and [RFC4203], and the Link Management Protocol (LMP) is
described in [RFC4204]. 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 2003 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 [G709-V3] have included some new features; for G.709 specification, including [G709-V3], have included some new
example, various multiplexing structures, two types of TSs (i.e., features; for example, various multiplexing structures, two types of
1.25Gbps and 2.5Gbps), and extension of the Optical Data Unit (ODU) TSs (i.e., 1.25Gbps and 2.5Gbps), and extension of the Optical Data
ODUj definition to include the ODUflex function. Unit (ODU) 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]. No additional Switching the Path Computation Element (PCE) [RFC4655]. No additional Switching
Type and LSP Encoding Type are required to support the control of the Type and LSP Encoding Type are required to support the control of the
evolved OTN, because the Switching Type and LSP Encoding Type defined evolved OTN, because the Switching Type and LSP Encoding Type defined
in [RFC4328] are still applicable. in [RFC4328] are still applicable.
skipping to change at page 4, line 16 skipping to change at page 4, line 22
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 (OTN)
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] describes the functional architecture of Specifically, [G872-2001] and [G872Am2] describe the functional
optical transport networks providing optical signal transmission, architecture of optical transport networks providing optical signal
multiplexing, routing, supervision, performance assessment, and transmission, multiplexing, routing, supervision, performance
network survivability. [G709-V1] defines the interfaces of the assessment, and network survivability. [G709-V1] defines the
optical transport network to be used within and between subnetworks interfaces of the optical transport network to be used within and
of the optical network. With the evolution and deployment of OTN between subnetworks of the optical network. With the evolution and
technology many new features have been specified in ITU-T deployment of OTN technology many new features have been specified in
recommendations, including for example, new ODU0, ODU2e, ODU4 and ITU-T recommendations, including for example, new ODU0, ODU2e, ODU4
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 Optical Multiplex Section (OMS) using WDM
multiplexing, and this aggregated signal provides the link between multiplexing, and 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 Low Order (LO) ODUj. Appendix A
gives more information about LO ODU. gives more information about LO ODU.
The current values of j defined in [G709-V3] are: 0, 1, 2, 2e, 3, 4, The current values of j defined in [G709-V3] are: 0, 1, 2, 2e, 3, 4,
Flex. The approximate bit rates of these signals are defined in Flex. The approximate bit rates of these signals are defined in
[G709-V3] and are reproduced in Tables 1 and 2. [G709-V3] and are reproduced in Tables 1 and 2.
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| ODU Type | ODU nominal bit rate | | ODU Type | ODU nominal bit rate |
skipping to change at page 5, line 31 skipping to change at page 5, line 37
| 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 CBR | |
| Client signals | 239/238 x client signal bit rate | | Client signals | 239/238 x client signal bit rate |
| | | | | |
| ODUflex for GFP-F | | | ODUflex for GFP-F | |
| Mapped client signal | Configured bit rate | | Mapped client signal | Configured bit rate |
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
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 |
skipping to change at page 6, line 23 skipping to change at page 6, line 23
| ODU2e | +- 100 ppm | | ODU2e | +- 100 ppm |
| | | | | |
| ODUflex for CBR | | | ODUflex for CBR | |
| Client signals | client signal bit rate tolerance, | | Client signals | client signal bit rate tolerance, |
| | with a maximum of+-100 ppm | | | with a maximum of+-100 ppm |
| | | | | |
| ODUflex for GFP-F | | | ODUflex for GFP-F | |
| Mapped client | +- 20 ppm | | Mapped client | +- 20 ppm |
| signal | | | signal | |
+-------------------+--------------------------------------+ +-------------------+--------------------------------------+
Table 2 ODU types and tolerance Table 2 - ODU types and tolerance
One of two options are 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 bit rate should be set to an (GFP). [G709-V3] recommends that the bit rate should be set to an
integer multiplier of the High Order (HO) Optical Channel Physical integer multiplier of the High Order (HO) Optical Channel Physical
Unit (OPU) OPUk TS rate, the tolerance should be +/- 20ppm, and Unit (OPU) OPUk TS rate, the tolerance should be +/- 20ppm, and
the bit rate should be determined by the node that performs the the bit rate should be determined by the node that performs the
mapping. mapping.
skipping to change at page 6, line 37 skipping to change at page 6, line 38
- 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 bit rate should be set to an (GFP). [G709-V3] recommends that the bit rate should be set to an
integer multiplier of the High Order (HO) Optical Channel Physical integer multiplier of the High Order (HO) Optical Channel Physical
Unit (OPU) OPUk TS rate, the tolerance should be +/- 20ppm, and Unit (OPU) OPUk TS rate, the tolerance should be +/- 20ppm, and
the bit rate should be determined by the node that performs the the bit rate should be determined by the node that performs the
mapping. mapping.
3.1.1.1 ODUj types and parameters 3.1.1.1. ODUj types and parameters
When ODUj connections are setup, two types of information should be When ODUj connections are setup, two types of information should be
conveyed in a connection request: conveyed in a connection request:
(a) End to end: (a) End to end:
Client payload type (e.g. STM64; Ethernet etc.) Client payload type (e.g. STM64; Ethernet etc.)
Bit rate and tolerance: Note for j = 0, 1, 2, 2e, 3, 4 this Bit rate and tolerance: Note for j = 0, 1, 2, 2e, 3, 4 this
information may be carried as an enumerated type. For the ODUflex information may be carried as an enumerated type. For the ODUflex
the actual bit rate and tolerance must be provided. the actual bit rate and tolerance must be provided.
(b) Hop by hop: (b) Hop by hop:
TS assignment and port number carried by the Multiplex Structure TS assignment and port number carried by the Multiplex Structure
Identifier (MSI) bytes as described in section 3.1.2. Identifier (MSI) bytes as described in section 3.1.2.
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 OPU. Since all of these signals have a 1:1:1 which carries one OPU. 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 OTUk. Note that in the case where j=k the mapped into the TS of the OTUk. 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. Amendment 3 [G709-V3], approved in granularity, nominally 2.5Gb/s. [G709-V3], approved in 2009, added an
2009, added an additional TS granularity, nominally 1.25Gb/s. The additional TS granularity, nominally 1.25Gb/s. The number and type of
number and type of TSs provided by each of the currently identified TSs provided by each of the currently identified OTUk is provided
OTUk is provided below: below:
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
skipping to change at page 8, line 35 skipping to change at page 8, line 35
- 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 the OTUk
TSs is determined locally, and it can also be explicitly controlled TSs is determined locally, and it can also be explicitly controlled
by a specific entity (e.g., head end, NMS) through Explicit Label by a specific entity (e.g., head end, NMS) through Explicit Label
Control [RFC3473]. Control [RFC3473].
3.1.2.1 Link Parameters 3.1.2.1. Link Parameters
Per [RFC4201], each OTU can be treated as a component link of a link Per [RFC4201], each OTU can be treated as a component link of a link
bundle. The available capacity between nodes is the sum of the bundle. The available capacity between nodes is the sum of the
available capacity on the OTUs that interconnect the nodes. This available capacity on the OTUs that interconnect the nodes. This
total capacity is represented as the capacity of a link bundle. total capacity is represented as the capacity of a link bundle.
Note that there will typically be more than one OTU between a pair of Note that there will typically be more than one OTU between a pair of
nodes so that the available capacity will typically be distributed nodes so that the available capacity will typically be distributed
across multiple OTUs. Thus, in order to be able to determine the across multiple OTUs. Thus, in order to be able to determine the
maximum payload that can be carried on a bundled link, the link state maximum payload that can be carried on a bundled link, the link state
skipping to change at page 9, line 17 skipping to change at page 9, line 17
purposes of routing) are: purposes of routing) are:
- Number of TS - Number of TS
- Maximum number of TS available for a LSP (i.e., Maximum LSP - Maximum number of TS available for a LSP (i.e., Maximum LSP
Bandwidth) Bandwidth)
- Bit rate of the TS. (Note: This may be efficiently encoded as a - Bit rate of the TS. (Note: This may be efficiently encoded as a
two integers representing the value of k and the granularity.) two integers representing the value of k and the granularity.)
3.1.2.2 Tributary Port Number Assignment 3.1.2.2. Tributary Port Number Assignment
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 Multiplex
Structure Information (MSI), is transported in the OPUk overhead and Structure Information (MSI), is transported in the OPUk overhead and
is organized as a set of entries, with one entry for each HO ODUj is organized as a set of entries, with one entry for each HO ODUj
TS. The information carried by each entry is: 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 Tributary Port Number (TPN): the port number of the ODUj
transported by the HO ODUk. The TPN is the same for all the TSs transported by the HO ODUk. The TPN is the same for all the TSs
assigned to the transport of the same ODUj instance. assigned to the transport of the 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.
The MSI information inserted in OPU3 overhead by the source of the HO The MSI information inserted in OPU3 overhead by the source of the HO
ODUk trail is checked by the sink of the HO ODUk trail. G.709 ODUk trail is checked by the sink of the HO ODUk trail. G.709 default
default behavior requires that the multiplexing structure of the HO behavior requires that the multiplexing structure of the HO ODUk be
ODUk be provided by means of pre-provisioned MSI information, termed provided by means of pre-provisioned MSI information, termed
expectedMSI. The sink of the HO ODU trail checks the complete expectedMSI. The sink of the HO ODU trail checks the complete content
content of the MSI information (including the TPN) that was received of the MSI information (including the TPN) that was received in-band,
in-band, termed acceptedMSI, against the expectedMSI. If the termed acceptedMSI, against the expectedMSI. If the acceptedMSI is
acceptedMSI is different from the expectedMSI, then the traffic is different from the expectedMSI, then the traffic is dropped and a
dropped and a payload mismatch alarm is generated. payload mismatch alarm is generated.
Note that the values of the TPN MUST be either agreed between the Note that the values of the TPN MUST be either agreed between the
source and the sink of the HO ODU trail either via control plane source and the sink of the HO ODU trail either via control plane
signaling or provisioning by the management plane. signaling or provisioning by the management plane.
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 optical channels (OCh). This document
focuses on the connection management of ODU paths. The management of focuses on the connection management of ODU paths. The management of
OCh paths is described in [WSON-FRAME]. OCh paths is described in [WSON-FRAME].
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
skipping to change at page 11, line 25 skipping to change at page 11, line 25
| +---------+ | | +---------+ |
| Node E | | Node E |
| | | |
+-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++ +-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++
| |Link #1 | |Link #2 | |Link #3 | | | |Link #1 | |Link #2 | |Link #3 | |
| |--------| |--------| |--------| | | |--------| |--------| |--------| |
| ODXC | | ODXC | | ODXC | | ODXC | | ODXC | | ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+ +---------+
Node A Node B Node C Node D Node A Node B Node C Node D
Figure 2 Example Topology for connection 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 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., ROADM,OXC) that are capable of OCh switching, which is
illustrated in Figure 3 and Figure 4. There are ODU layer and OCh illustrated in Figure 3 and Figure 4. There are ODU layer and OCh
layer, so it is simply a MLN. OCh connections may be created on layer, so it is simply a MLN. OCh connections may be created on
demand, which is described in section 5.1. 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 RWA
network topology. network topology.
Node E Node E
Link #5 +---------+ Link #4 Link #5 +--------+ Link #4
+--------------------------| |-------------------------+ +------------------------| |------------------------+
| ------ | | ------ |
| // \\ | | // \\ |
| || || | | || || |
| | RWA domain | | | | RWA 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 connection LO ODU connection management Figure 3 - RWA 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 - RWA 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 to node E from the RWA domain. HO-ODU/OCh connection between node C to node E from the RWA 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 framework for extensions The purpose of this section is to provide a framework for extensions
of the current GMPLS protocol suite and the PCE applications and of the current GMPLS protocol suite and the PCE applications and
protocols to encompass OTN enhancements and connection management. protocols to encompass OTN enhancements and connection management.
5.1. Implications for LSP Hierarchy with GMPLS TE 5.1. Implications for LSP Hierarchy with GMPLS TE
The path computation for LO 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, including OCh layer visibility.
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 LO ODUj. [RFC4206] defines the mechanisms to OCh/OTUk, the other is ODUj. [RFC4206] and [RFC4206bis] define the
accomplish creating the hierarchy of LSPs. The LSP management of mechanisms to accomplish creating the hierarchy of LSPs. The LSP
multiple layers in OTN can follow the procedures defined in [RFC4206] management of multiple layers in OTN can follow the procedures
and related MLN drafts. defined in [RFC4206], [RFC4206bis] 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 [WSON-Frame]. Therefore, this document only the scope of WSON [WSON-Frame]. Therefore, this document only
considers ODU layer for LO ODU connection request. considers ODU layer for ODU connection request.
For the ODU layers, in order to maintain compatibility with
introducing new [G709-V3] services (e.g., ODU0, ODUflex) into a
legacy network configuration (containing [G709-V1] or [G709-V2] OTN
equipment), it may be needed to consider introducing multi-stage
multiplexing capability in specific network transition scenarios. One
method for enabling multi-stage multiplexing is by introducing
dedicated boards in a few specific places in the network and
tunneling these new services through [G709-V1] or [G709-V2]
containers (ODU1, ODU2, ODU3), thus postponing the need to upgrade
every network element to [G709-V3] capabilities. In such case, one
ODUj connection can be nested into another ODUk connection, which
forms the LSP hierarchy in ODU layer. Here, [RFC4206], [RFC4206bis]
and [MLN-EXT] (including related modifications, if needed) are
relevant to connection set up.
5.2. Implications for GMPLS Signaling 5.2. Implications for GMPLS Signaling
The signaling function and Resource reSerVation Protocol-Traffic The signaling function and Resource reSerVation Protocol-Traffic
Engineering (RSVP-TE) extensions are described in [RFC3471] and [RFC Engineering (RSVP-TE) extensions are described in [RFC3471] and [RFC
3473]. For OTN-specific control, [RFC4328] defines signaling 3473]. For OTN-specific control, [RFC4328] defines signaling
extensions to support G.709 Optical Transport Networks Control as extensions to support G.709 Optical Transport Networks Control as
defined in [G709-V1]. defined in [G709-V1].
As described in Section 2, [G709-V3] introduced some new features As described in Section 2, [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.
5.2.1. Identifying OTN signals 5.2.1. Identifying OTN signals
[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 new signal Parameters are also defined in [RFC4328]. The following new signal
types have been added since [RFC4328] was published: types have been added since [RFC4328] was published:
(1) New signal types of sub-lambda layer (1) New signal types of sub-lambda layer
Optical Channel Data Unit (ODUj): Optical Channel Data Unit (ODUj):
- ODU0 - ODU0
- ODU2e - ODU2e
- ODU4 - ODU4
- ODUflex - ODUflex
(2) A new TS granularity (i.e., 1.25 Gbps) (2) A new TS granularity (i.e., 1.25 Gbps)
(3) Signal type with variable bandwidth: (3) Signal type with variable bandwidth:
ODUflex has a variable bandwidth/bit rate BR and a bit rate ODUflex has a variable bandwidth/bit rate BR and a bit rate
tolerance T. As described above the (node local) mapping process tolerance T. As described above the (node local) mapping process
must be aware of the bit rate and tolerance of the ODUj being must be aware of the bit rate and tolerance of the ODUj being
multiplexed in order to select the correct number of TS and the multiplexed in order to select the correct number of TS and the
fixed/variable stuffing bytes. Therefore, bit rate and bit rate fixed/variable stuffing bytes. Therefore, bit rate and bit rate
skipping to change at page 14, line 37 skipping to change at page 15, line 4
(4) Extended multiplexing hierarchy (For example, ODU0 into OTU2 (4) Extended multiplexing hierarchy (For example, ODU0 into OTU2
multiplexing (with 1,25Gbps TS granularity).) multiplexing (with 1,25Gbps TS granularity).)
So the encoding provided in [RFC4328] needs to be extended to support So the encoding provided in [RFC4328] needs to be extended to support
all the signal types and related mapping and multiplexing with all all the signal types and related mapping and multiplexing with all
kinds of TSs. Moreover, the extensions should consider the kinds of TSs. Moreover, the extensions should consider the
extensibility to match future evolvement of OTN. extensibility to match future evolvement of OTN.
For item (1) and (3), new traffic parameters may need to be extended For item (1) and (3), new traffic parameters may need to be extended
in signaling message; in signaling message;
For item (2) and (4), new label should be defined to carry the exact For item (2) and (4), new label should be defined to carry the exact
TS allocation information related to the extended multiplexing TS allocation information related to the extended multiplexing
hierarchy. hierarchy.
5.2.2. Tributary Port Number 5.2.2. Tributary Port Number
The tributary port number may be assigned locally by the node at the The tributary port number may be assigned locally by the node at the
(traffic) ingress end of the link and in this case as described above (traffic) ingress end of the link and in this case as described above
must be conveyed to the far end of the link as a "transparent" must be conveyed to the far end of the link as a "transparent"
parameter i.e. the control plane does not need to understand this parameter i.e. the control plane does not need to understand this
information. The TPN may also be assigned by the control plane as a information. The TPN may also be assigned by the control plane when
part of path computation. establishing LSP.
5.2.3. Support for constraint signaling
How an ODUk connection service is transported within an operator
network is governed by operator policy. For example, the ODUk
connection service might be transported over an ODUk path over an
OTUk section, with the path and section being at the same rate as
that of the connection service. In this case, an entire lambda of
capacity is consumed in transporting the ODUk connection service. On
the other hand, the operator might leverage sub-lambda multiplexing
capabilities in the network to improve infrastructure efficiencies
within any given networking domain. In this case, ODUk multiplexing
may be performed prior to transport over various rate ODU servers
over associated OTU sections.
The identification of constraints and associated encoding in the
signaling for differentiating full lambda LSP or sub lambda LSP is
for further study.
5.3. Implications for GMPLS Routing 5.3. Implications for GMPLS Routing
The path computation process should select a suitable route for a The path computation process should select a suitable route for a
ODUj connection request. In order to compute the lowest cost path it ODUj connection request. In order to compute the lowest cost path it
must evaluate the number (and availability) of TSs on each candidate must evaluate the number (and availability) of TSs on each candidate
link. The routing protocol should be extended to convey some link. The routing protocol should be extended to convey some
information to represent ODU TE topology. As described above the information to represent ODU TE topology. As described above the
number of TSs (on a link bundle), the bandwidth of the TS and the number of TSs (on a link bundle), the bandwidth of the TS and the
maximum number that are available to convey a single ODUj must be maximum number that are available to convey a single ODUj must be
skipping to change at page 17, line 7 skipping to change at page 17, line 38
- Support link bundling - Support link bundling
Link bundling can improve routing scalability by reducing the Link bundling can improve routing scalability by reducing the
amount of TE links that has to be handled by routing protocol. amount of TE links that has to be handled by routing protocol.
The routing protocol must be capable of supporting bundling The routing protocol must be capable of supporting bundling
multiple OTU links, at the same or different line rates, between multiple OTU links, at the same or different line rates, between
a pair of nodes as a TE link. Note that link bundling is optional a pair of nodes as a TE link. Note that link bundling is optional
and is implementation dependent. and is implementation dependent.
As mentioned in Section 5.1, one method of enabling multi-stage
multiplexing is via usage of dedicated boards to allow tunneling of
new services through legacy ODU1, ODU2, ODU3 containers. Such
dedicated boards may have some constraints with respect to switching
matrix access; detection and representation of such constraints is
for further study.
5.4. Implications for Link Management Protocol (LMP) 5.4. Implications for Link Management Protocol (LMP)
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 The Link Management Protocol (LMP) [RFC4204] provides a control plane
protocol for exchanging and correlating link capabilities. protocol for exchanging and correlating link capabilities.
skipping to change at page 17, line 28 skipping to change at page 18, line 19
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. UNI case)
we need to extend link management protocol capabilities to cover this we need to extend link management protocol capabilities to cover this
aspect. In case of routing presence, the discovering procedure by LMP aspect. In case of routing presence, the discovering procedure by LMP
could also be optional. could also be optional.
5.4.1. Correlating the Granularity of the TS 5.4.1. 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 node different TS granularity. In order to allow interconnection the node
with 1.25Gb/s granularity must fall back to 2.5Gb/s granularity. with 1.25Gb/s granularity must fall back to 2.5Gb/s granularity.
Therefore, it is necessary for the two ends of a link to correlate Therefore, it is necessary for the two ends of a link to correlate
the granularity of the TS. This ensures that both ends of the link the granularity of the TS. This ensures that both ends of the link
advertise consistent capabilities (for routing) and ensures that advertise consistent capabilities (for routing) and ensures that
viable connections are established. viable connections are established.
5.4.2. Correlating the Supported LO ODU Signal Types 5.4.2. Correlating the Supported LO ODU Signal Types
Many new ODU signal types have been introduced [G709-V3], such as Many new ODU signal types have been introduced [G709-V3], such as
ODU0, ODU4, ODU2e and ODUflex. It is possible that equipment does not ODU0, ODU4, ODU2e and ODUflex. It is possible that equipment does not
support all the LO ODU signal types introduced by those new standards support all the LO ODU signal types introduced by those new standards
or drafts. If one end of a link can not support a certain LO ODU or drafts. If one end of a link can not support a certain LO ODU
signal type, the link cannot be selected to carry such type of LO ODU signal type, the link cannot be selected to carry such type of LO ODU
connection. connection.
Therefore, it is necessary for the two ends of an HO ODU link to Therefore, it is necessary for the two ends of an HO ODU link to
correlate which types of LO ODU can be supported by the link. After correlate which types of LO ODU can be supported by the link. After
skipping to change at page 19, line 45 skipping to change at page 20, line 33
Generalized Multi-Protocol Label Switching (GMPLS)", RFC Generalized Multi-Protocol Label Switching (GMPLS)", RFC
4205, October 2005. 4205, October 2005.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
October 2005. October 2005.
[RFC4206] K. Kompella, Y. Rekhter, Ed., " Label Switched Paths (LSP) [RFC4206] K. Kompella, Y. Rekhter, Ed., " Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206bis] K. Shiomoto, A. Farrel, "Procedures for Dynamically
Signaled Hierarchical Label Switched Paths", draft-ietf-
ccamp-lsp-hierarchy-bis-08.txt, February 2010.
[MLN-EXT] Dimitri Papadimitriou et al, "Generalized Multi-Protocol
Label Switching (GMPLS) Protocol Extensions for Multi-
Layer and Multi-Region Networks (MLN/MRN)", draft-ietf-
ccamp-gmpls-mln-extensions-12.txt, February 21, 2010.
[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.
[G709-V3] ITU-T, "Interfaces for the Optical Transport Network [G709-V3] ITU-T, "Interfaces for the Optical Transport Network
(OTN)", G.709 Recommendation, December 2009. (OTN)", G.709 Recommendation, December 2009.
9.2. Informative References 9.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
2001.
[G709-V2] ITU-T, "Interface for the Optical Transport Network
(OTN)," G.709 Recommendation, March 2003. (OTN)," G.709 Recommendation, March 2003.
[G872-2001] ITU-T, "Architecture of optical transport networks", [G872-2001] ITU-T, "Architecture of optical transport networks",
November 2001 (11 2001). November 2001 (11 2001).
[G872-Am2] Draft Amendment 2, ITU-T, "Architecture of optical [G872-Am2] Draft Amendment 2, ITU-T, "Architecture of optical
transport networks". transport networks".
[HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing [HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing
and wavelength assignment approaches for wavelength- and wavelength assignment approaches for wavelength-
skipping to change at page 22, line 4 skipping to change at page 23, line 9
Email: malcolm.betts@huawei.com Email: malcolm.betts@huawei.com
Pietro Grandi Pietro Grandi
Alcatel-Lucent Alcatel-Lucent
Optics CTO Optics CTO
Via Trento 30 20059 Vimercate (Milano) Italy Via Trento 30 20059 Vimercate (Milano) Italy
+39 039 6864930 +39 039 6864930
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. APPENDIX A: ODU connection examples
This appendix provides a description of LO ODU terminology and ODU This appendix provides a description of ODU terminology and
connection examples. This section is not normative which is just a connection examples. This section is not normative, and is just
reference in order to facilitate quicker understanding of text. intended to facilitate understanding.
In order to transmit client signal, the LO ODU connection must be In order to transmit a client signal, an ODU connection must first be
created first. From the perspective of [G709-V3], there are two types created. From the perspective of [G709-V3] and [G872-Am2], some types
of LO ODU: 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) A LO ODUj mapped into an OTUk. In this case, the server layer of (1) An ODUj client that is mapped into an OTUk server. For example,
this LO ODU is an OTUk. For example, if a STM-16 signal is if a STM-16 signal is encapsulated into ODU1, and then the ODU1 is
encapsulated into ODU1, and then ODU1 is mapped into OTU1, the ODU1 mapped into OTU1, the ODU1 is a LO ODU (from a multiplexing
is a LO ODU. perspective).
(2) A LO ODUj multiplexed into a HO ODUk (j < k) occupying several (2) An ODUj client that is mapped into an ODUk (j < k) server
TSs. In this case, the server layer of this LO ODU is a HO ODUk. For occupying several TSs. For example, if ODU1 is multiplexed into ODU2,
example, if ODU1 is multiplexed into ODU2, and ODU2 is mapped into and ODU2 is mapped into OTU2, the ODU1 is a LO ODU and the ODU2 is a
OTU2, the ODU1 is LO ODU and ODU2 is HO ODU. HO ODU (from a multiplexing perspective).
The LO ODUj represents the container transporting a client of the OTN Thus, a LO ODUj represents the container transporting a client of the
that is either directly mapped into an OTUk (k = j) or multiplexed OTN that is either directly mapped into an OTUk (k = j) or
into a server HO ODUk (k > j)container. Consequently, the HO ODUk multiplexed into a server HO ODUk (k > j) container. Consequently,
represents the entity transporting a multiplex of LO ODUj tributary the HO ODUk represents the entity transporting a multiplex of LO ODUj
signals in its OPUk area. tributary signals in its OPUk area.
In the case of LO ODUj mapped into an OTUk (k = j) directly, Figure 5 In the case of LO ODUj mapped into an OTUk (k = j) directly, Figure 5
give an example of this kind of LO ODU connection. give an example of this kind of LO ODU connection.
In Figure 5, The LO ODUj is switched at the intermediate ODXC node. In Figure 5, The LO ODUj is switched at the intermediate ODXC node.
OCh and OTUk are associated with each other. From the viewpoint of OCh and OTUk are associated with each other. From the viewpoint of
connection management, the management of OTUk is similar with OCh. LO connection management, the management of OTUk is similar with OCh. LO
ODUj and OCh/OTUk have client/server relationships. ODUj and OCh/OTUk have client/server relationships.
For example, one LO ODU1 connection can be setup between Node A and For example, one LO ODU1 connection can be setup between Node A and
skipping to change at page 23, line 24 skipping to change at page 24, line 29
| | OCh/OTUk | | OCh/OTUk | | | | OCh/OTUk | | OCh/OTUk | |
| +--------(a)---------+ +--------(a)---------+ | | +--------(a)---------+ +--------(a)---------+ |
| | | | | | | | | | | |
+------++-+ +--+---+--+ +-++------+ +------++-+ +--+---+--+ +-++------+
| |EO| |OE| |EO| |OE| | | |EO| |OE| |EO| |OE| |
| +--+----------------+--+ +--+----------------+--+ | | +--+----------------+--+ +--+----------------+--+ |
| ODXC | | ODXC | | ODXC | | ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
Node A Node B Node C Node A Node B Node C
Figure 5 Connection of LO ODUj (1) Figure 5 - Connection of LO ODUj (1)
In the case of LO ODUj multiplexing into HO ODUk, Figure 6 gives an In the case of LO ODUj multiplexing into HO ODUk, Figure 6 gives an
example of this kind of LO ODU connection. example of this kind of LO ODU connection.
In Figure 6, OCh, OTUk, HO ODUk are associated with each other. The In Figure 6, OCh, OTUk, HO ODUk are associated with each other. The
LO ODUj is multiplexed/de-multiplexed into/from the HO ODU at each 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, 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 line card to line port, line port to trib port). From the viewpoint
of connection management, the management of these HO ODUk and OTUk 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 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 relationships. When a LO ODU connection is setup, it will be using
the existing HO ODUk (/OTUk/OCh) connections which have been set up. 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 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 manager requests a link connection to support the LO ODU
connection. connection.
For example, one HO ODU2 (/OTU2/OCh) connection can be setup between 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 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, 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 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 at Node A, demultiplexed from the HO ODU2 at Node B, switched at Node
skipping to change at page 24, line 17 skipping to change at page 25, line 20
| | OCh/OTUk/HO ODUk | | OCh/OTUk/HO ODUk | | | | OCh/OTUk/HO ODUk | | OCh/OTUk/HO ODUk | |
| +--------(c)---------+ +---------(c)--------+ | | +--------(c)---------+ +---------(c)--------+ |
| | | | | | | | | | | |
+------++-+ +--+---+--+ +-++------+ +------++-+ +--+---+--+ +-++------+
| |EO| |OE| |EO| |OE| | | |EO| |OE| |EO| |OE| |
| +--+----------------+--+ +--+----------------+--+ | | +--+----------------+--+ +--+----------------+--+ |
| ODXC | | ODXC | | ODXC | | ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
Node A Node B Node C Node A Node B Node C
Figure 6 Connection of LO ODUj (2) Figure 6 - 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. 57 change blocks. 
129 lines changed or deleted 189 lines changed or added

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