draft-ietf-ccamp-gmpls-g709-framework-00.txt   draft-ietf-ccamp-gmpls-g709-framework-01.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: October 22, 2010 April 22, 2010 Expires: November 18, 2010 May 18, 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-00.txt draft-ietf-ccamp-gmpls-g709-framework-01.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 October 22, 2010. This Internet-Draft will expire on November 18, 2010.
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
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............................13
5.2.2. Tributary Port Number.............................14 5.2.2. Tributary Port Number..............................14
5.3. Implications for GMPLS Routing.........................15 5.3. Implications for GMPLS Routing..........................15
5.3.1. Requirement for conveying Interface Switching 5.4. Implications for Link Management Protocol (LMP).........17
Capability specific information...................15 5.4.1. Correlating the Granularity of the TS..............17
5.4. Implications for Link Management Protocol (LMP)........16 5.4.2. Correlating the Supported LO ODU Signal Types......17
5.4.1. Correlating the Granularity of the TS.............16 5.5. Implications for Path Computation Elements..............18
5.4.2. Correlating the Supported LO ODU Signal Types.....16 6. Security Considerations......................................18
5.5. Implications for Path Computation Elements.............17 7. IANA Considerations..........................................18
6. Security Considerations.....................................17 8. Acknowledgments..............................................18
7. IANA Considerations.........................................17 9. References...................................................19
8. Acknowledgments.............................................17 9.1. Normative References....................................19
9. References..................................................18 9.2. Informative References..................................20
9.1. Normative References...................................18 10. Authors' Addresses..........................................20
9.2. Informative References.................................19 11. Contributors................................................21
10. Authors' Addresses.........................................19 APPENDIX A: ODU connection examples.............................22
11. Contributors...............................................20
APPENDIX A: Description of LO ODU terminology and ODU connection
examples.......................................................21
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)
skipping to change at page 3, line 4 skipping to change at page 2, line 47
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 2003
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 [G709-V3] have included some new features; for
example, various multiplexing structures, two types of Tributary example, various multiplexing structures, two types of TSs (i.e.,
Slots (i.e., 1.25Gbps and 2.5Gbps), and extension of the Optical Data 1.25Gbps and 2.5Gbps), and extension of the Optical Data Unit (ODU)
Unit (ODU) ODUj definition to include the ODUflex function. ODUj definition to include the ODUflex function.
This document reviews relevant aspects of OTN technology evolution This document reviews relevant aspects of OTN technology evolution
that affect the GMPLS control plane protocols and examines why and that affect the GMPLS control plane protocols and examines why and
how to update the mechanisms described in [RFC4328]. This document how to update the mechanisms described in [RFC4328]. This document
additionally provides a framework for the GMPLS control of OTN additionally provides a framework for the GMPLS control of OTN
networks and includes a discussion of the implication for the use of networks and includes a discussion of the implication for the use of
the Path Computation Element (PCE) [RFC4655]. the Path Computation Element (PCE) [RFC4655]. No additional Switching
Type and LSP Encoding Type are required to support the control of the
evolved OTN, because the Switching Type and LSP Encoding Type defined
in [RFC4328] are still applicable.
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 sub-wavelength (ODU) and wavelength (OCh) layers. being comprised of ODU and wavelength (OCh) layers. This document
This document focuses on the control of the sub-wavelength layer, focuses on the control of the ODU layer, with control of the
with control of the wavelength layer considered out of the scope. wavelength layer considered out of the scope. Please refer to [WSON-
Please refer to [WSON-Frame] for further information about the Frame] for further information about the wavelength layer.
wavelength layer.
[Note: It is intended to align this draft with G.709 (consented in
10/2009), G.872 and G.8080 (planned for consent in 6/2010)]
2. Terminology 2. Terminology
OTN: Optical Transport Network OTN: Optical Transport Network
ODU: Optical Channel Data Unit ODU: Optical Channel Data Unit
OTU: Optical channel transport unit OTU: Optical channel transport unit
OMS: Optical multiplex section OMS: Optical multiplex section
MSI: Multiplex Structure Identifier MSI: Multiplex Structure Identifier
TPN: Tributary Port Number TPN: Tributary Port Number
LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4, LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4,
Flex.) represents the container transporting a client of the OTN that flex.) represents the container transporting a client of the OTN that
is either directly mapped into an OTUk (k = j) or multiplexed into a is either directly mapped into an OTUk (k = j) or multiplexed into a
server HO ODUk (k > j)container. server HO ODUk (k > j) container.
HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, 4.) HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, 4.)
represents the entity transporting a multiplex of LO ODUj tributary represents the entity transporting a multiplex of LO ODUj tributary
signals in its OPUk area. signals in its OPUk area.
ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a
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, [ITU-T-G.872] describes the functional architecture of Specifically, [G872-2001] describes the functional architecture of
optical transport networks providing optical signal transmission, optical transport networks providing optical signal transmission,
multiplexing, routing, supervision, performance assessment, and multiplexing, routing, supervision, performance assessment, and
network survivability. [G709-V1] defines the interfaces of the network survivability. [G709-V1] defines the interfaces of the
optical transport network to be used within and between subnetworks optical transport network to be used within and between subnetworks
of the optical network. With the evolution and deployment of OTN of the optical network. With the evolution and deployment of OTN
technology many new features have been specified in ITU-T technology many new features have been specified in ITU-T
recommendations, including for example, new ODU0, ODU2e, ODU4 and recommendations, including for example, new ODU0, ODU2e, ODU4 and
ODUflex containers as described in [G709-V3]. ODUflex containers as described in [G709-V3].
3.1. OTN Layer Network 3.1. OTN Layer Network
skipping to change at page 6, line 28 skipping to change at page 6, line 28
| | | | | |
| 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 are 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 Tributary Slot (TS) rate, the tolerance should be +/- Unit (OPU) OPUk TS rate, the tolerance should be +/- 20ppm, and
20ppm, and the bit rate should be determined by the node that the bit rate should be determined by the node that performs the
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 Tributary Slots (TS) of the OTUk. Note that in the mapped into the TS of the OTUk. Note that in the case where j=k the
case where j=k the ODUj is mapped into the OTU/OCh without ODUj is mapped into the OTU/OCh without multiplexing.
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. Amendment 3 [G709-V3], approved in
2009, added an additional TS granularity, nominally 1.25Gb/s. The 2009, added an additional TS granularity, nominally 1.25Gb/s. The
number and type of TSs provided by each of the currently identified number and type of TSs provided by each of the currently identified
OTUk is provided below: OTUk is provided 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
only 8 in an OTU4. Examples of the number of TS used for various only 8 in an OTU4. Examples of the number of TS used for various
cases are provided below: cases are provided below:
- 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 or o ODU0 occupies 1 of the 2, 8, 32 or 80 TS for ODU1, ODU2, ODU3
ODU4 or ODU4
- ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS - ODU1 into ODU2, ODU3 or ODU4 multiplexing with 1,25Gbps TS
granularity granularity
o ODU1 occupies 2 of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4 o ODU1 occupies 2 of the 8, 32 or 80 TS for ODU2, ODU3 or ODU4
- ODU1 into ODU2, ODU3 multiplexing with 2.5Gbps TS granularity - ODU1 into ODU2, ODU3 multiplexing with 2.5Gbps TS granularity
o ODU1 occupies 1 of the 4 or 16 TS for ODU2 or ODU3 o ODU1 occupies 1 of the 4 or 16 TS for ODU2 or ODU3
- ODU2 into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity - ODU2 into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity
o ODU2 occupies 8 of the 32 or 80 TS for ODU3 or ODU4 o ODU2 occupies 8 of the 32 or 80 TS for ODU3 or ODU4
- 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 TS 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 TS 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 TS for ODU2, ODU3 or ODU4
(n <= Total TS numbers of ODUk) (n <= Total TS numbers of ODUk)
- ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity - ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity
o ODU2e occupies 9 of the 32 TS for ODU3 or 8 of the 80 TS for o ODU2e occupies 9 of the 32 TS for ODU3 or 8 of the 80 TS for
ODU4 ODU4
In general the mapping of an ODUj (including ODUflex) into the OTUk In general the mapping of an ODUj (including ODUflex) into 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
skipping to change at page 9, line 12 skipping to change at page 9, line 12
advertisement must also provide the largest number of TSes available advertisement must also provide the largest number of TSes available
on any one component OTU. on any one component OTU.
In order to compute the lowest cost path for a ODUj connection In order to compute the lowest cost path for a ODUj connection
request the critical parameters that need to be provided (for the request the critical parameters that need to be provided (for the
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
tributary slot. 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 transported Tributary Port Number (TPN): the port number of the ODUj
by the HO ODUk. The TPN is the same for all the tributary slots 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 Tributary Slot (TS) size is 2.5 Gbit/s, in the OPU3 overhead when the TS size is 2.5 Gbit/s, and by 8 entries
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 behavior requires that the multiplexing structure of the HO default behavior requires that the multiplexing structure of the HO
ODUk be provided by means of pre-provisioned MSI information, termed ODUk be 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 of the MSI information (including the TPN) that was received content of the MSI information (including the TPN) that was received
in-band, termed acceptedMSI, against the expectedMSI. If the in-band, termed acceptedMSI, against the expectedMSI. If the
acceptedMSI is different from the expectedMSI, then the traffic is acceptedMSI is different from the expectedMSI, then the traffic is
dropped and a payload mismatch alarm is generated. dropped and a 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
As [ITU-T-G.872] described, OTN-based transport network equipment is OTN-based connection management is concerned with controlling the
concerned with control of connectivity of ODU paths and optical connectivity of ODU paths and optical channels (OCh). This document
channels and not with control of connectivity of the client layer. focuses on the connection management of ODU paths. The management of
This document focuses on the connection management of ODU paths. The OCh paths is described in [WSON-FRAME].
management of OCh paths is described in [WSON-FRAME].
Current [ITU-T-G.872] considers the ODU as a set of layers in the
same way as SDH has been modeled. However, recent progress within
the ITU-T on OTN architecture includes an agreement to update this
Recommendation to model the ODU as a single layer network with the
bit rate as a parameter of links and connections. This will allow the
links and nodes to be viewed in a single topology as a common set of
resources that are available to provide ODUj connections independent
of the value of j. Note that when the bit rate of ODUj is less than
the server bit rate, ODUj connections are supported by HO-ODU (which
has a one-to-one relationship with the OTU).
From an ITU-T perspective, the service layer is represented by the LO While [G872-2001] considered the ODU as a set of layers in the same
ODU and the connection topology is represented by that of the server way as SDH has been modeled, recent ITU-T OTN architecture progress
layer; i.e., the OTU [corresponding to HO-ODU in case of multiplexing [G872-Am2] includes an agreement to model the ODU as a single layer
or to LO-ODU in case of direct mapping] which has the same topology network with the bit rate as a parameter of links and connections.
as that of the OCh layer. The server layer topology is based on that This allows the links and nodes to be viewed in a single topology as
of the OTU, and could be provided by a point-to-point optical a common set of resources that are available to provide ODUj
connection, flexible optical connection that is fully in the optical connections independent of the value of j. Note that when the bit
domain, flexible optical connection involving hybrid sub- rate of ODUj is less than the server bit rate, ODUj connections are
lambda/lambda nodes involving 3R, etc. supported by HO-ODU (which has a one-to-one relationship with the
OTU).
The HO-ODU/OTU and OCh layers should be visible in a single From an ITU-T perspective, the ODU connection topology is represented
by that of the OTU link layer, which has the same topology as that of
the OCh layer (independent of whether the OTU supports HO-ODU, where
multiplexing is utilized, or LO-ODU in the case of direct mapping).
Thus, the OTU and OCh layers should be visible in a single
topological representation of the network, and from a logical topological representation of the network, and from a logical
perspective, the HO ODU/OTU and OCh may be considered as the same perspective, the OTU and OCh may be considered as the same logical,
logical, switchable entity. switchable entity.
The remainder of this document assumes that the revision of G.872 Note that the OTU link layer topology may be provided via various
will be made. The document will be updated to keep it in line with infrastructure alternatives, including point-to-point optical
the new revision of G.872 when it is consented for publication. connections, flexible optical connections fully in the optical domain,
flexible optical connections involving hybrid sub-lambda/lambda nodes
involving 3R, etc.
The document will be updated to maintain consistency with G.872
progress when it is consented for publication.
4.1. Connection management of the ODU 4.1. Connection management of the ODU
LO ODUj can be either mapped into the OTUk signal (j = k), or LO ODUj can be either mapped into the OTUk signal (j = k), or
multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is
mapped into an OCh. See Appendix A for more information. mapped into an OCh. See Appendix A for more information.
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 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 connection 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 | |
| +--------+ | | +--------+ + | +--------+ | | +--------+ +
skipping to change at page 12, line 36 skipping to change at page 12, line 36
| 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
skipping to change at page 13, line 48 skipping to change at page 14, line 7
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
- ODU2e
- ODU4
- ODUflex
ODU0 (2) A new TS granularity (i.e., 1.25 Gbps)
ODU2e
ODU4
ODUflex
(2)A new Tributary Slot (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
tolerance should be carried in the Traffic Parameter in the tolerance should be carried in the Traffic Parameter in the
signaling of connection setup request. signaling of connection setup request.
(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 tributary slots. Moreover, the extensions should consider kinds of TSs. Moreover, the extensions should consider the
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
skipping to change at page 15, line 9 skipping to change at page 15, line 9
(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 as a
part of path computation. part of path computation.
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 tributary slots on must evaluate the number (and availability) of TSs on each candidate
each candidate link. The routing protocol should be extended to link. The routing protocol should be extended to convey some
convey some information to represent ODU TE topology. As described information to represent ODU TE topology. As described above the
above the number of tributary slots (on a link bundle), the bandwidth number of TSs (on a link bundle), the bandwidth of the TS and the
of the TS and the maximum number that are available to convey a maximum number that are available to convey a single ODUj must be
single ODUj must be provided. provided.
GMPLS Routing [RFC4202] defines Interface Switching Capability GMPLS Routing [RFC4202] defines Interface Switching Capability
Descriptor of TDM which can be used for ODU. However, some other Descriptor of TDM which can be used for ODU. However, some other
issues should also be considered which are discussed below. issues should also be considered which are discussed below.
5.3.1. Requirement for conveying Interface Switching Capability specific
information
Interface Switching Capability Descriptors present a new constraint Interface Switching Capability Descriptors present a new constraint
for LSP path computation. [RFC4203] defines the switching capability for LSP path computation. [RFC4203] defines the switching capability
and related Maximum LSP Bandwidth and the Switching Capability and related Maximum LSP Bandwidth and the Switching Capability
specific information. When the Switching Capability field is TDM the specific information. When the Switching Capability field is TDM the
Switching Capability specific information field includes Minimum LSP Switching Capability specific information field includes Minimum LSP
Bandwidth, an indication whether the interface supports Standard or Bandwidth, an indication whether the interface supports Standard or
Arbitrary SONET/SDH, and padding. So routing protocol should be Arbitrary SONET/SDH, and padding. So routing protocol should be
extended when TDM is ODU type to support representation of ODU extended when TDM is ODU type to support representation of ODU
switching information. switching information, especially the following requirements should
be considered:
As discussed in section 3.1.2, many different types of ODUj can be - Support for carrying the link multiplexing capability
multiplexed into the same OTUk. For example, both ODU0 and ODU1 may
be multiplexed into ODU2. An OTU link may support one or more types
of ODUj signals. The routing protocol should be extended to carry
this multiplexing capability. Furthermore, one type of ODUj can be
multiplexed to an OTUk using different tributary slot granularity.
For example, ODU1 can be multiplexed into ODU2 with either 2.5Gbps TS
granularity or 1.25G TS granularity. The routing protocol should be
extended to carry which TS granularity supported by the ODU interface.
Moreover, the bit rate (i.e., bandwidth) of TS can be determined by As discussed in section 3.1.2, many different types of ODUj can
the TS granularity and link type of the TE link. For example, the be multiplexed into the same OTUk. For example, both ODU0 and
bandwidth of a 1.25G TS without NJO (Negative Justification ODU1 may be multiplexed into ODU2. An OTU link may support one or
Opportunity) in an OTU2 is about 1.249409620 Gbps, while the more types of ODUj signals. The routing protocol should be
bandwidth of a 1.25G TS without NJO in an OTU3 is about 1.254703729 capable of carrying this multiplexing capability.
Gbps. So The routing protocol should be extended to carry the TE link
type (OTUk/HO ODUk).
In OTN networks, it is simpler to use the number of Tributary Slots - Support for carrying the TS granularity that the interface can
for the bandwidth accounting. For example, Total bandwidth of the TE support
link, Unreserved Bandwidth of the TE link and the Maximum LSP
Bandwidth can be accounted through the number of Tributary Slots One type of ODUj can be multiplexed to an OTUk using different TS
(e.g., the total number of the Tributary Slots of the TE link, the granularity. For example, ODU1 can be multiplexed into ODU2 with
unreserved Tributary Slots of the TE link, Maximum Tributary Slots either 2.5Gbps TS granularity or 1.25G TS granularity. The
for an LSP). Thus, the routing protocol should be extended to carry routing protocol should be capable of carrying the TS granularity
the Tributary Slots information related to bandwidth of the TE link. supported by the ODU interface.
- Support any ODU and ODUflex
The bit rate (i.e., bandwidth) of TS is dependent on the TS
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,
while the bandwidth of a 1.25G TS in an OTU3 is about 1.254703729
Gbps.
One LO ODU may need different number of TSs when multiplexed into
different HO ODUs. For example, for ODU2e, 9 TSs are needed when
multiplexed into an ODU3, while only 8 TSs are needed when
multiplexed into an ODU4. For ODUflex, the total number of TSs to
be reserved in a HO ODU equals the maximum of [bandwidth of
ODUflex / bandwidth of TS of the HO ODU].
Therefore, the routing protocol must be capable of carrying the
necessary and sufficient link bandwidth information for
performing accurate route computation for any of the fixed rate
ODUs as well as ODUflex.
- Support for differentiating between link multiplexing capacity and
link rate capacity
When a network operator receives a request for a particular ODU
connection service, the operator governs the manner in which the
request is fulfilled in their network. Considerations include
deployed network infrastructure capabilities, associated policies
(e.g., at what link fill threshold should a particular higher-
rate ODUk be utilized), etc. Thus, for example, an ODU2
connection service request could be supported by: OTU2 links
(here the connection service rate is the same as the link rate),
a combination of OTU2 and OTU3 links, OTU3 links, etc.
Therefore, to allow the required flexibility, the routing
protocol should be capable of differentiating between these two
types of link capacity.
- Support different priorities for resource reservation
How many priorities levels should be supported depends on the
operator's policy. Therefore, the routing protocol should be
capable of supporting either no priorities or up to 8 priority
levels as defined in [RFC4202].
- Support link bundling
Link bundling can improve routing scalability by reducing the
amount of TE links that has to be handled by routing protocol.
The routing protocol must be capable of supporting bundling
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
and is implementation dependent.
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 18, line 9 skipping to change at page 19, line 9
8. Acknowledgments 8. Acknowledgments
We would like to thank Maarten Vissers for his review and useful We would like to thank Maarten Vissers for his review and useful
comments. comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol Label [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol
Switching (GMPLS) Signaling Extensions for G.709 Optical LabelSwitching (GMPLS) Signaling Extensions for G.709
Transport Networks Control", RFC 4328, Jan 2006. Optical Transport Networks Control", RFC 4328, Jan 2006.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Functional Description", Switching (GMPLS) Signaling Functional Description", RFC
RFC 3471, January 2003. 3471, January 2003.
[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label
Switching (GMPLS) Signaling Resource ReserVation Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC
3473, January 2003. 3473, January 2003.
[RFC4202] K. Kompella, Y. Rekhter, Ed., "Routing Extensions in [RFC4201] K. Kompella, Y. Rekhter, Ed., "Link Bundling in MPLS
Traffic Engineering (TE)", RFC 4201, October 2005.
[RFC4202] K. Kompella, Y. Rekhter, Ed., "Routing Extensions in
Support of Generalized Multi-Protocol Label Switching Support of Generalized Multi-Protocol Label Switching
(GMPLS)", RFC 4202, October 2005. (GMPLS)", RFC 4202, October 2005.
[RFC4203] K. Kompella, Y. Rekhter, Ed., "OSPF Extensions in Support [RFC4203] K. Kompella, Y. Rekhter, Ed., "OSPF Extensions in Support
of Generalized Multi-Protocol Label Switching (GMPLS)", of Generalized Multi-Protocol Label Switching (GMPLS)",
RFC 4203, October 2005. RFC 4203, October 2005.
[RFC4205] K. Kompella, Y. Rekhter, Ed., "Intermediate System to [RFC4205] K. Kompella, Y. Rekhter, Ed., "Intermediate System to
Intermediate System (IS-IS) Extensions in Support of Intermediate System (IS-IS) Extensions in Support of
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 [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
4204, October 2005.
[RFC4206] K. Kompella, Y. Rekhter, Ed., " Label Switched Paths
(LSP) Hierarchy with Generalized Multi-Protocol Label
Switching (GMPLS) Traffic Engineering (TE)", RFC 4206,
October 2005. October 2005.
[RFC4206] K. Kompella, Y. Rekhter, Ed., " Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[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, March 2003. (OTN)," G.709 Recommendation, March 2003.
[ITU-T-G.872] ITU-T, "Architecture of optical transport networks", [G872-2001] ITU-T, "Architecture of optical transport networks",
November 2001 (11 2001). November 2001 (11 2001).
[HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing [G872-Am2] Draft Amendment 2, ITU-T, "Architecture of optical
transport networks".
[HZang00] H. Zang, J. Jue and B. Mukherjeee, "A review of routing
and wavelength assignment approaches for wavelength- and wavelength assignment approaches for wavelength-
routed optical WDM networks", Optical Networks Magazine, routed optical WDM networks", Optical Networks Magazine,
January 2000. January 2000.
[WSON-FRAME] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS [WSON-FRAME] 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)", draft-ietf-ccamp-rwa-wson-framework, work in (WSON)", draft-ietf-ccamp-rwa-wson-framework, work in
progress. progress.
[PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai [PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai
Zhang, "Requirements for GMPLS applications of PCE", Zhang, "Requirements for GMPLS applications of PCE",
draft-ietf-pce-gmpls-aps-req-01.txt, July 2009. draft-ietf-pce-gmpls-aps-req-01.txt, July 2009.
[GMPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS [GMPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, October 2009. Networks", Work in Progress, October 2009.
10. Authors' Addresses 10. Authors' Addresses
Fatai Zhang Fatai Zhang
Huawei Technologies Huawei Technologies
skipping to change at page 20, line 43 skipping to change at page 22, line 4
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: Description of LO ODU terminology and ODU connection APPENDIX A: ODU connection examples.
examples.
This appendix provides a description of LO ODU terminology and ODU This appendix provides a description of LO ODU terminology and ODU
connection examples. This section is not normative which is just a connection examples. This section is not normative which is just a
reference in order to facilitate quicker understanding of text. reference in order to facilitate quicker understanding of text.
In order to transmit client signal, the LO ODU connection must be In order to transmit client signal, the LO ODU connection must be
created first. From the perspective of [G709-V3], there are two types created first. From the perspective of [G709-V3], there are two types
of LO ODU: of LO ODU:
(1) A LO ODUj mapped into an OTUk. In this case, the server layer of (1) A LO ODUj mapped into an OTUk. In this case, the server layer of
skipping to change at page 24, line 35 skipping to change at page 25, line 35
FOR A PARTICULAR PURPOSE. FOR A PARTICULAR PURPOSE.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
 End of changes. 67 change blocks. 
196 lines changed or deleted 228 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/