draft-ietf-ccamp-gmpls-g709-framework-08.txt   draft-ietf-ccamp-gmpls-g709-framework-09.txt 
Network Working Group Fatai Zhang, Ed. Network Working Group Fatai Zhang, Ed.
Internet Draft Dan Li Internet Draft Dan Li
Category: Informational Huawei Category: Informational Huawei
Han Li Han Li
CMCC CMCC
S.Belotti S.Belotti
Alcatel-Lucent Alcatel-Lucent
D. Ceccarelli D. Ceccarelli
Ericsson Ericsson
Expires: December 19, 2012 June 19, 2012 Expires: February 25, 2013 August 25, 2012
Framework for GMPLS and PCE Control of Framework for GMPLS and PCE Control of
G.709 Optical Transport Networks G.709 Optical Transport Networks
draft-ietf-ccamp-gmpls-g709-framework-08.txt draft-ietf-ccamp-gmpls-g709-framework-09.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 19, 2012. This Internet-Draft will expire on February 25, 2013.
Abstract Abstract
This document provides a framework to allow the development of This document provides a framework to allow the development of
protocol extensions to support Generalized Multi-Protocol Label protocol extensions to support Generalized Multi-Protocol Label
Switching (GMPLS) and Path Computation Element (PCE) control of Switching (GMPLS) and Path Computation Element (PCE) control of
Optical Transport Networks (OTN) as specified in ITU-T Recommendation Optical Transport Networks (OTN) as specified in ITU-T Recommendation
G.709 as consented in October 2009. G.709 as consented in October 2009.
Table of Contents Table of Contents
skipping to change at page 2, line 22 skipping to change at page 2, line 22
3.1. OTN Layer Network ........................................ 4 3.1. OTN Layer Network ........................................ 4
3.1.1. Client signal mapping ............................... 5 3.1.1. Client signal mapping ............................... 5
3.1.2. Multiplexing ODUj onto Links ........................ 6 3.1.2. Multiplexing ODUj onto Links ........................ 6
3.1.2.1. Structure of MSI information ................... 8 3.1.2.1. Structure of MSI information ................... 8
4. Connection management in OTN .................................. 9 4. Connection management in OTN .................................. 9
4.1. Connection management of the ODU ........................ 10 4.1. Connection management of the ODU ........................ 10
5. GMPLS/PCE Implications ....................................... 12 5. GMPLS/PCE Implications ....................................... 12
5.1. Implications for LSP Hierarchy with GMPLS TE ............ 12 5.1. Implications for LSP Hierarchy with GMPLS TE ............ 12
5.2. Implications for GMPLS Signaling ........................ 13 5.2. Implications for GMPLS Signaling ........................ 13
5.3. Implications for GMPLS Routing .......................... 15 5.3. Implications for GMPLS Routing .......................... 15
5.4. Implications for Link Management Protocol (LMP) ......... 18 5.4. Implications for Link Management Protocol (LMP) ......... 17
5.5. Implications for Control Plane Backward Compatibility ... 19 5.5. Implications for Control Plane Backward Compatibility ... 18
5.6. Implications for Path Computation Elements .............. 20 5.6. Implications for Path Computation Elements .............. 19
6. Data Plane Backward Compatibility Considerations ............. 20 6. Data Plane Backward Compatibility Considerations ............. 20
7. Security Considerations ...................................... 21 7. Security Considerations ...................................... 20
8. IANA Considerations .......................................... 21 8. IANA Considerations .......................................... 21
9. Acknowledgments .............................................. 21 9. Acknowledgments .............................................. 21
10. References .................................................. 22 10. References .................................................. 21
10.1. Normative References ................................... 22 10.1. Normative References ................................... 21
10.2. Informative References ................................. 23 10.2. Informative References ................................. 22
11. Authors' Addresses .......................................... 24 11. Authors' Addresses .......................................... 23
12. Contributors ................................................ 25 12. Contributors ................................................ 24
APPENDIX A: ODU connection examples ............................. 26 APPENDIX A: ODU connection examples ............................. 25
1. Introduction 1. Introduction
OTN has become a mainstream layer 1 technology for the transport OTN has become a mainstream layer 1 technology for the transport
network. Operators want to introduce control plane capabilities based network. Operators want to introduce control plane capabilities based
on Generalized Multi-Protocol Label Switching (GMPLS) to OTN networks, on 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 8, line 28 skipping to change at page 8, line 28
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 local to each link. In case of bidirectional paths the association is local to each link. In case of bidirectional paths the association
between TPN and TS must be the same in both directions. between TPN and TS must be the same in both directions.
The MSI information is organized as a set of entries, with one entry The MSI information is organized as a set of entries, with one entry
for each HO ODUj TS. The information carried by each entry is: for each HO ODUj TS. The information carried by each entry is:
- Payload Type: the type of the transported payload. - Payload Type: the type of the transported payload.
- 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.
On each node and on every link, two MSI values have to be provisioned: On each node and on every link, two MSI values have to be provisioned:
- The TxMSI information inserted in OPU (e.g., OPU3) overhead by the - The TxMSI information inserted in OPU (e.g., OPU3) overhead by the
source of the HO ODUk trail. source of the HO ODUk trail.
- The expectedMSI information that is used to check the acceptedMSI
information. The acceptedMSI information is the MSI valued received - The expectedMSI information that is used to check the acceptedMSI
in-band, after a 3 frames integration. information. The acceptedMSI information is the MSI valued
received in-band, after a 3 frames integration.
The sink of the HO ODU trail checks the complete content of the The sink of the HO ODU trail checks the complete content of the
acceptedMSI information against the expectedMSI. acceptedMSI information against the expectedMSI.
If the acceptedMSI is different from the expectedMSI, then the If the acceptedMSI is different from the expectedMSI, then the
traffic is dropped and a payload mismatch alarm is generated. traffic is dropped and a payload mismatch alarm is generated.
Provisioning of TPN can be performed either by network management Provisioning of TPN can be performed either by network management
system or control plane. In the last case, control plane is also system or control plane. In the last case, control plane is also
responsible for negotiating the provisioned values on a link by link responsible for negotiating the provisioned values on a link by link
skipping to change at page 14, line 48 skipping to change at page 14, line 43
- Support for ODU Virtual Concatenation (VCAT) and Link Capacity - Support for ODU Virtual Concatenation (VCAT) and Link Capacity
Adjustment Scheme (LCAS) Adjustment Scheme (LCAS)
GMPLS signaling should support the creation of Virtual GMPLS signaling should support the creation of Virtual
Concatenation of ODUk signal with k=1, 2, 3. The signaling should Concatenation of ODUk signal with k=1, 2, 3. The signaling should
also support the control of dynamic capacity changing of a VCAT also support the control of dynamic capacity changing of a VCAT
container using LCAS ([G.7042]). [RFC6344] has a clear description container using LCAS ([G.7042]). [RFC6344] has a clear description
of VCAT and LCAS control in SONET/SDH and OTN networks. of VCAT and LCAS control in SONET/SDH and OTN networks.
- Support for ODU layer multiplexing hierarchy signaling
ODU layer multiplexing hierarchy has been supported by [G709-V3],
i.e., a client ODUj connection can be nested into server layer
ODUk (j<k) connection. Control plane should provide mechanisms to
support creation of such ODU hierarchy.
When creating server layer ODU LSP for carrying one specific
client LSP, the first and last hop of the server LSP should be
capable of selecting the correct link to make sure that both ends
of the server LSP can support multiplexing/demultiplexing client
signal into / from server LSP.
Therefore, the adaption information (e.g., hierarchical
information and TSG) should be carried in the signaling to make
the penultimate node of the FA-LSP to select the correct link for
carrying the specific client signal.
- Support for Control of Hitless Adjustment of ODUflex (GFP) - Support for Control of Hitless Adjustment of ODUflex (GFP)
[G.7044] has been created in ITU-T to specify hitless adjustment [G.7044] has been created in ITU-T to specify hitless adjustment
of ODUflex (GFP) (HAO) that is used to increase or decrease the of ODUflex (GFP) (HAO) that is used to increase or decrease the
bandwidth of an ODUflex (GFP) that is transported in an OTN bandwidth of an ODUflex (GFP) that is transported in an OTN
network. network.
The procedure of ODUflex (GFP) adjustment requires the The procedure of ODUflex (GFP) adjustment requires the
participation of every node along the path. Therefore, it is participation of every node along the path. Therefore, it is
recommended to use the control plane signaling to initiate the recommended to use the control plane signaling to initiate the
skipping to change at page 19, line 16 skipping to change at page 18, line 39
For the control and management consideration, it is necessary for For the control and management consideration, it is necessary for
the two ends of an HO ODU link to correlate which types of LO ODU the two ends of an HO ODU link to correlate which types of LO ODU
can be supported and what multiplexing hierarchy capabilities can can be supported and what multiplexing hierarchy capabilities can
be provided by the other end. be provided by the other end.
5.5. Implications for Control Plane Backward Compatibility 5.5. Implications for Control Plane Backward Compatibility
With the introduction of G709-v3, there may be OTN networks composed With the introduction of G709-v3, there may be OTN networks composed
of a mixture of nodes, some of which support [G709-V1] and run of a mixture of nodes, some of which support [G709-V1] and run
control plane protocols defined in [RFC4328] (referred to as legacy control plane protocols defined in [RFC4328], while others support
nodes), while others support [G709-V3] and new OTN control plane [G709-V3] and new OTN control plane characterized in this document.
characterized in this document (referred to as new nodes). In such Note that a third case, for the sake of completeness, consists on
case, control plane backward compatibility needs to be taken into G709-V1 nodes with a new OTN control plane, but such nodes can be
consideration (Note that a third case, for the sake of completeness, considered as new nodes with limited capabilities.
consists on G709-V1 nodes with a new OTN control plane, but such
nodes can be considered as new nodes with limited capabilities).
In order to provide backward compatibility, a new Switching This section discusses the compatibility of nodes implementing the
Capability type is required for the control of [G709-V3] both in control plane procedures defined [RFC4328], in support of [G709-V1],
routing and signaling. and the control plane procedures defined to support [G709-V3], as
outlined by this document.
From a routing perspective, the advertisement of LSAs carrying new Compatibility needs to be considered only when controlling ODU1 or
Switching Capability type implies the support of new OTN control ODU2 or ODU3 connection, because [G709-V1] only support these three
plane protocols. A new node must support both legacy routing (i.e., ODU signal types. In such cases, there are several possible options
the procedures defined in [RFC4203] with the switching capabilities including:
defined in [RFC4328]) and new routing (i.e., the procedures defined
for [G709-V3]), and should use new routing by default. When detecting
the presence of a legacy node in the administrative domain (i.e.,
receiving LSAs carrying legacy Switching Capability type), the new
node should advertise its links information by both the new and
legacy routing approach, so that the legacy node can obtain the link
resource information advertised by the new node.
On the other hand, from a signaling perspective, a new node must - A node supporting [G709-V3] could support only the [G709-V3]
support both the legacy signaling procedures defined in [RFC4328] and related control plane procedures, in which case both types of
the new procedures for control of [G709-V3]. Based on the routing nodes would be unable to jointly control an LSP for an ODU type
information, a new node can determine whether its neighbor node is a that both nodes support in the data plane. Note that this case is
legacy one or new one, so that it can determine which signaling supported by the procedures defined in [RFC3473] as a different
procedure (new or legacy signaling procedure) needs to be performed. Switching Capability/Type value is used for the different control
In case the new node has not enough information to know which plane versions.
signaling procedure its neighbor can support, it can use the new
signaling procedure with the new Switching Capability type by default.
Since a legacy node receiving such message will respond with an error - A node supporting [G709-V3] could support both the [G709-V3]
message indicating an unsupported Switching Capability type, the new related control plane and the control plane defined in [RFC4328].
node can perform the signaling again with a procedure [RFC4328]
compliant. o Such a node could identify which set of procedure to follow
when initiating an LSP based on the Switching Capability value
advertised in routing.
o Such a node could follow the set of procedures based on the
Switching Type received in signaling messages from an upstream
node.
o Such a node, when processing a transit LSP, could select which
signaling procedures to follow based on the Switching
Capability value advertised in routing by the next hop node.
5.6. Implications for Path Computation Elements 5.6. Implications for Path Computation Elements
[PCE-APS] describes the requirements for GMPLS applications of PCE in [PCE-APS] describes the requirements for GMPLS applications of PCE in
order to establish GMPLS LSP. PCE needs to consider the GMPLS TE order to establish GMPLS LSP. PCE needs to consider the GMPLS TE
attributes appropriately once a PCC or another PCE requests a path attributes appropriately once a PCC or another PCE requests a path
computation. The TE attributes which can be contained in the path computation. The TE attributes which can be contained in the path
calculation request message from the PCC or the PCE defined in calculation request message from the PCC or the PCE defined in
[RFC5440] includes switching capability, encoding type, signal type, [RFC5440] includes switching capability, encoding type, signal type,
etc. etc.
skipping to change at page 24, line 10 skipping to change at page 23, line 28
[RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS
and PCE Control of Wavelength Switched Optical Networks and PCE Control of Wavelength Switched Optical Networks
(WSON)", RFC6163, April 2011. (WSON)", RFC6163, April 2011.
[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, Work in Progress. draft-ietf-pce-gmpls-aps-req, Work in Progress.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", July 2010. Networks", RFC5920, July 2010.
11. Authors' Addresses 11. Authors' Addresses
Fatai Zhang (editor) Fatai Zhang (editor)
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Phone: +86-755-28972912 Phone: +86-755-28972912
 End of changes. 16 change blocks. 
75 lines changed or deleted 58 lines changed or added

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