draft-ietf-ccamp-gmpls-g709-framework-05.txt   draft-ietf-ccamp-gmpls-g709-framework-06.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: March 9, 2012 September 9, 2011 Expires: September 8, 2012 March 8, 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-05.txt draft-ietf-ccamp-gmpls-g709-framework-06.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 March 9, 2012. This Internet-Draft will expire on September 8, 2012.
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 23 skipping to change at page 2, line 23
3.1.1. Client signal mapping ............................... 5 3.1.1. Client signal mapping ............................... 5
3.1.2. Multiplexing ODUj onto Links ........................ 7 3.1.2. Multiplexing ODUj onto Links ........................ 7
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 .......................... 16 5.3. Implications for GMPLS Routing .......................... 16
5.4. Implications for Link Management Protocol (LMP) ......... 18 5.4. Implications for Link Management Protocol (LMP) ......... 18
5.5. Implications for Path Computation Elements .............. 19 5.5. Implications for Control Plane Backward Compatibility ... 19
5.6. Implications for Path Computation Elements .............. 20
6. Data Plane Backward Compatibility Considerations ............. 20 6. Data Plane Backward Compatibility Considerations ............. 20
7. Security Considerations ...................................... 20 7. Security Considerations ...................................... 21
8. IANA Considerations .......................................... 21 8. IANA Considerations .......................................... 21
9. Acknowledgments .............................................. 21 9. Acknowledgments .............................................. 21
10. References .................................................. 21 10. References .................................................. 21
10.1. Normative References ................................... 21 10.1. Normative References ................................... 21
10.2. Informative References ................................. 22 10.2. Informative References ................................. 23
11. Authors' Addresses .......................................... 23 11. Authors' Addresses .......................................... 24
12. Contributors ................................................ 24 12. Contributors ................................................ 25
APPENDIX A: ODU connection examples ............................. 25 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.).
skipping to change at page 11, line 16 skipping to change at page 11, line 16
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.
skipping to change at page 14, line 9 skipping to change at page 14, line 8
and protocol extensions will be necessary to allow them to be and protocol extensions will be necessary to allow them to be
controlled by a GMPLS control plane. controlled by a GMPLS control plane.
[RFC4328] defines the LSP Encoding Type, the Switching Type and the [RFC4328] defines the LSP Encoding Type, the Switching Type and the
Generalized Protocol Identifier (Generalized-PID) constituting the Generalized Protocol Identifier (Generalized-PID) constituting the
common part of the Generalized Label Request. The G.709 Traffic common part of the Generalized Label Request. The G.709 Traffic
Parameters are also defined in [RFC4328]. The following signaling Parameters are also defined in [RFC4328]. The following signaling
aspects should be considered additionally since [RFC4328] was aspects should be considered additionally since [RFC4328] was
published: published:
- Support for backward compatibility with [RFC4328]
A new Switching Capability type needs to be defined for control of
[G709-V3] in the routing, so the Switching Type used when
signalling of LSPs for [G709-V3] should be consistent with the
Switching Type in the routing information.
Assume [RFC4328] has been deployed to control the OTN networks
supporting [G709-V1], control plane backward compatibility needs
to be taken into consideration when interworking with legacy nodes
only supporting [RFC4328] and [G709-V1].
- Support for specifying the new signal types and the related - Support for specifying the new signal types and the related
traffic information traffic information
The traffic parameters should be extended in signaling message to The traffic parameters should be extended in signaling message to
support the new optical Channel Data Unit (ODUj) including: support the new optical Channel Data Unit (ODUj) including:
- ODU0 - ODU0
- ODU2e - ODU2e
- ODU4 - ODU4
- ODUflex - ODUflex
skipping to change at page 14, line 43 skipping to change at page 14, line 30
bit rate tolerance T, the (node local) mapping process must be bit rate tolerance T, the (node local) mapping process must be
aware of the bit rate and tolerance of the ODUj being multiplexed aware of the bit rate and tolerance of the ODUj being multiplexed
in order to select the correct number of TS and the fixed/variable in order to select the correct number of TS and the fixed/variable
stuffing bytes. Therefore, bit rate and bit rate tolerance should stuffing bytes. Therefore, bit rate and bit rate tolerance should
also be carried in the Traffic Parameter in the signaling of also be carried in the Traffic Parameter in the signaling of
connection setup request. connection setup request.
For other ODU signal types, the bit rates and tolerances of them For other ODU signal types, the bit rates and tolerances of them
are fixed and can be deduced from the signal types. are fixed and can be deduced from the signal types.
- Support for LSP setup using different Tributary Slot granularity - Support for LSP setup using different Tributary Slot Granularity
(TSG)
The signaling protocol should be able to identify the type of TS The signaling protocol should be able to identify the type of TS
(i.e., the 2.5 Gbps TS granularity and the new 1.25 Gbps TS (i.e., the 2.5 Gbps TS granularity and the new 1.25 Gbps TS
granularity) to be used for establishing an H-LSP which will be granularity) to be used for establishing an H-LSP which will be
used to carry service LSP(s) requiring specific TS type. used to carry service LSP(s) requiring specific TS type.
- Support for LSP setup of new ODUk/ODUflex containers with related - Support for LSP setup of new ODUk/ODUflex containers with related
mapping and multiplexing capabilities mapping and multiplexing capabilities
New label should be defined to carry the exact TS allocation New label should be defined to carry the exact TS allocation
information related to the extended mapping and multiplexing information related to the extended mapping and multiplexing
hierarchy (For example, ODU0 into ODU2 multiplexing (with 1,25Gbps hierarchy (For example, ODU0 into ODU2 multiplexing (with 1.25Gbps
TS granularity)), in order to setting up the ODU connection. TS granularity)), in order to setting up the ODU connection.
- Support for Tributary Port Number allocation and negotiation - Support for Tributary Port Number allocation and negotiation
Tributary Port Number needs to be configured as part of the MSI Tributary Port Number needs to be configured as part of the MSI
information (See more information in Section 3.1.2.1). A new information (See more information in Section 3.1.2.1). A new
extension object has to be defined to carry TPN information if extension object has to be defined to carry TPN information if
control plane is used to configure MSI information. control plane is used to configure MSI information.
- Support for ODU Virtual Concatenation (VCAT) and Link Capacity - Support for ODU Virtual Concatenation (VCAT) and Link Capacity
Adjustment Scheme (LCAS) Adjustment Scheme (LCAS)
GMPLS signaling should support the creation of Virtual GMPLS signaling should support the creation of Virtual
Concatenation of ODUk signal with k=1, 2, 3. The signaling should Concatenation of ODUk signal with k=1, 2, 3. The signaling should
also support the control of dynamic capacity changing of a VCAT also support the control of dynamic capacity changing of a VCAT
container using LCAS ([G.7042]). [RFC6344] has a clear description container using LCAS ([G.7042]). [RFC6344] has a clear description
of VCAT and LCAS control in SONET/SDH and OTN networks. of VCAT and LCAS control in SONET/SDH and OTN networks.
- Support for constraint signaling - Support for ODU layer multiplexing hierarchy signaling
How an ODUk connection service is transported within an operator ODU layer multiplexing hierarchy has been supported by [G709-V3],
network is governed by operator policy. For example, the ODUk i.e., a client ODUj connection can be nested into server layer
connection service might be transported over an ODUk path over an ODUk (j<k) connection. Control plane should provide mechanisms to
OTUk section, with the path and section being at the same rate as support creation of such ODU hierarchy.
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 When creating server layer ODU LSP for carrying one specific
signaling for differentiating full lambda LSP or sub lambda LSP is client LSP, the first and last hop of the server LSP should be
for further study. 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
adjustment procedure in order to avoid the manual configuration at adjustment procedure in order to avoid the manual configuration at
each node along the path. each node along the path.
Since the [G.7044] is being developed currently, the control of From the perspective of control plane, the control of ODUflex
HAO is for further study. resizing is similar to control of bandwidth increasing and
decreasing described in [RFC3209]. Therefore, the SE style can be
used for control of HAO.
All the extensions above should consider the extensibility to match All the extensions above should consider the extensibility to match
future evolvement of OTN. future evolvement of OTN.
5.3. Implications for GMPLS Routing 5.3. Implications for GMPLS Routing
The path computation process should select a suitable route for an The path computation process should select a suitable route for an
ODUj connection request. In order to perform the path computation, it ODUj connection request. In order to perform the path computation, it
must evaluate the available bandwidth on each candidate link. The must evaluate the available bandwidth on each candidate link. The
routing protocol should be extended to convey some information to routing protocol should be extended to convey some information to
skipping to change at page 17, line 44 skipping to change at page 17, line 29
or both of them. The capability advertised by an interface needs or both of them. The capability advertised by an interface needs
further distinction in order to separate termination and further distinction in order to separate termination and
switching capabilities. switching capabilities.
Therefore, to allow the required flexibility, the routing Therefore, to allow the required flexibility, the routing
protocol should clearly distinguish the terminating and switching protocol should clearly distinguish the terminating and switching
capability. capability.
- Support for Tributary Slot Granularity advertisement - Support for Tributary Slot Granularity advertisement
[G709-V3] defines two types of TS but each link can only support a [G709-V3] defines two types of TS but each link can only support
single type at a given time. In order to perform a correct path a single type at a given time. In order to perform a correct path
computation (i.e. the LSP end points have matching Tributary Slot computation (i.e. the LSP end points have matching Tributary Slot
Granularity values) the Tributary Slot Granularity needs to be Granularity values) the Tributary Slot Granularity needs to be
advertised. advertised.
- Support different priorities for resource reservation - Support different priorities for resource reservation
How many priorities levels should be supported depends on the How many priorities levels should be supported depends on the
operator's policy. Therefore, the routing protocol should be operator's policy. Therefore, the routing protocol should be
capable of supporting either no priorities or up to 8 priority capable of supporting either no priorities or up to 8 priority
levels as defined in [RFC4202]. levels as defined in [RFC4202].
- Support link bundling - Support link bundling
Link bundling can improve routing scalability by reducing the Link bundling can improve routing scalability by reducing the
amount of TE links that has to be handled by routing protocol. The amount of TE links that has to be handled by routing protocol.
routing protocol must be capable of supporting bundling multiple The routing protocol must be capable of supporting bundling
OTU links, at the same line rate and muxing hierarchy, between a multiple OTU links, at the same line rate and muxing hierarchy,
pair of nodes as a TE link. Note that link bundling is optional between a pair of nodes as a TE link. Note that link bundling is
and is implementation dependent. optional and is implementation dependent.
- Support for Control of Hitless Adjustment of ODUflex (GFP) - Support for Control of Hitless Adjustment of ODUflex (GFP)
As described in Section 5.2, the routing requirements for The control plane should support hitless adjustment of ODUflex,
supporting hitless adjustment of ODUflex (GFP) (G.7044) are for so the routing protocol should be capable of differentiating
further study. whether an ODU link can support hitless adjustment of ODUflex
(GFP) or not, and how much resource can be used for resizing.
This can be achieved by introducing a new signal type
"ODUflex(GFP-F), resizable" that implies the support for hitless
adjustment of ODUflex (GFP) by that link.
As mentioned in Section 5.1, one method of enabling multiplexing As mentioned in Section 5.1, one method of enabling multiplexing
hierarchy is via usage of dedicated boards to allow tunneling of new hierarchy is via usage of dedicated boards to allow tunneling of new
services through legacy ODU1, ODU2, ODU3 containers. Such dedicated services through legacy ODU1, ODU2, ODU3 containers. Such dedicated
boards may have some constraints with respect to switching matrix boards may have some constraints with respect to switching matrix
access; detection and representation of such constraints is for access; detection and representation of such constraints is for
further study. further study.
5.4. Implications for Link Management Protocol (LMP) 5.4. Implications for Link Management Protocol (LMP)
skipping to change at page 19, line 35 skipping to change at page 19, line 28
capability, or the two ends of the link support different capability, or the two ends of the link support different
multiplexing hierarchy capabilities (e.g., one end of the link multiplexing hierarchy capabilities (e.g., one end of the link
supports ODU0 into ODU1 into ODU3 multiplexing while the other supports ODU0 into ODU1 into ODU3 multiplexing while the other
end supports ODU0 into ODU2 into ODU3 multiplexing). end supports ODU0 into ODU2 into ODU3 multiplexing).
For the control and management consideration, it is necessary for For the control and management consideration, it is necessary for
the two ends of an HO ODU link to correlate which types of LO ODU the two ends of an HO ODU link to correlate which types of LO ODU
can be supported and what multiplexing hierarchy capabilities can can be supported and what multiplexing hierarchy capabilities can
be provided by the other end. be provided by the other end.
5.5. Implications for Path Computation Elements 5.5. Implications for Control Plane Backward Compatibility
Assume [RFC4328] has been deployed to control the OTN networks
supporting [G709-V1], control plane backward compatibility needs to
be taken into consideration. Scenarios for backward compatibility are
described as follows:
o Legacy OTN devices supporting [G709-V1] may run control plane
protocol defined in [RFC4328];
o Legacy OTN devices supporting [G709-V1] may also support new OTN
control plane characterized in this document after control plane
updating;
o New OTN devices supporting [G709-V3] always support new OTN
control plane characterized in this document;
o New OTN devices SHOULD support falling back to [RFC4328] for
interworking scenarios.
Based on these scenarios, control plane backward compatibility SHOULD
be taken into account when interworking between the new control plane
characterized in this document and the legacy control plane defined
in [RFC4328].
A new Switching Capability type is required for control of [G709-V3]
in the routing and signaling to enable the backward procedure.
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.
As described in section 5.2.1, new signal types and new signals with As described in section 5.2.1, new signal types and new signals with
variable bandwidth information need to be carried in the extended variable bandwidth information need to be carried in the extended
signaling message of path setup. For the same consideration, PCECP signaling message of path setup. For the same consideration, PCECP
also has a desire to be extended to carry the new signal type and also has a desire to be extended to carry the new signal type and
related variable bandwidth information when a PCC requests a path related variable bandwidth information when a PCC requests a path
computation. computation.
6. Data Plane Backward Compatibility Considerations 6. Data Plane Backward Compatibility Considerations
The node supporting 1.25Gbps TS can interwork with the other nodes If TS auto-negotiation is supported, a node supporting 1.25Gbps TS
that supporting 2.5Gbps TS by combining Specific TSs together in data can interwork with the other nodes that supporting 2.5Gbps TS by
plane. The control plane MUST support this TS combination. combining Specific TSs together in data plane. The control plane MUST
support this TS combination.
Take Figure 5 as an example. Assume that there is an ODU2 link
between node A and B, where node A only supports the 2.5Gbps TS while
node B supports the 1.25Gbps TS. In this case, the TS#i and TS#i+4
(where i<=4) of node B are combined together. When creating an ODU1
service in this ODU2 link, node B reserves the TS#i and TS#i+4 with
the granularity of 1.25Gbps. But in the label sent from B to A, it is
indicated that the TS#i with the granularity of 2.5Gbps is reserved.
Path Path
+----------+ ------------> +----------+ +----------+ ------------> +----------+
| TS1==|===========\--------+--TS1 | | TS1==|===========\--------+--TS1 |
| TS2==|=========\--\-------+--TS2 | | TS2==|=========\--\-------+--TS2 |
| TS3==|=======\--\--\------+--TS3 | | TS3==|=======\--\--\------+--TS3 |
| TS4==|=====\--\--\--\-----+--TS4 | | TS4==|=====\--\--\--\-----+--TS4 |
| | \ \ \ \----+--TS5 | | | \ \ \ \----+--TS5 |
| | \ \ \------+--TS6 | | | \ \ \------+--TS6 |
| | \ \--------+--TS7 | | | \ \--------+--TS7 |
| | \----------+--TS8 | | | \----------+--TS8 |
+----------+ <------------ +----------+ +----------+ <------------ +----------+
node A Resv node B node A Resv node B
Figure 5 - Interworking between 1.25Gbps TS and 2.5Gbps TS Figure 5 - Interworking between 1.25Gbps TS and 2.5Gbps TS
Take Figure 5 as an example. Assume that there is an ODU2 link
between node A and B, where node A only supports the 2.5Gbps TS while
node B supports the 1.25Gbps TS. In this case, the TS#i and TS#i+4
(where i<=4) of node B are combined together. When creating an ODU1
service in this ODU2 link, node B reserves the TS#i and TS#i+4 with
the granularity of 1.25Gbps. But in the label sent from B to A, it is
indicated that the TS#i with the granularity of 2.5Gbps is reserved.
In the contrary direction, when receiving a label from node A In the contrary direction, when receiving a label from node A
indicating that the TS#i with the granularity of 2.5Gbps is reserved, indicating that the TS#i with the granularity of 2.5Gbps is reserved,
node B will reserved the TS#i and TS#i+4 with the granularity of node B will reserved the TS#i and TS#i+4 with the granularity of
1.25Gbps in its control plane. 1.25Gbps in its data plane.
7. Security Considerations 7. Security Considerations
The use of control plane protocols for signaling, routing, and path The use of control plane protocols for signaling, routing, and path
computation opens an OTN to security threats through attacks on those computation opens an OTN to security threats through attacks on those
protocols. The data plane technology for an OTN does not introduce protocols. The data plane technology for an OTN does not introduce
any specific vulnerabilities, and so the control plane may be secured any specific vulnerabilities, and so the control plane may be secured
using the mechanisms defined for the protocols discussed. using the mechanisms defined for the protocols discussed.
For further details of the specific security measures refer to the For further details of the specific security measures refer to the
skipping to change at page 23, line 5 skipping to change at page 23, line 31
[G7042] ITU-T G.7042/Y.1305, "Link capacity adjustment scheme [G7042] ITU-T G.7042/Y.1305, "Link capacity adjustment scheme
(LCAS) for virtual concatenated signals", March 2006. (LCAS) for virtual concatenated signals", March 2006.
[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".
[G.7044] TD 382 (WP3/15), 31 May - 11 June 2010, Q15 Plenary [G.7044] ITU-T, "Hitless adjustment of ODUflex", G.7044 (and
Meeting in Geneva, Initial draft G.7044 "Hitless Amendment 1), February 2012.
Adjustment of ODUflex (HAO)".
[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-
routed optical WDM networks", Optical Networks Magazine, routed optical WDM networks", Optical Networks Magazine,
January 2000. January 2000.
[RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS [RFC6163] Y. Lee, G. Bernstein, W. Imajuku, "Framework for GMPLS
and PCE Control of Wavelength Switched Optical Networks and PCE Control of Wavelength Switched Optical Networks
(WSON)", RFC6163, April 2011. (WSON)", RFC6163, April 2011.
 End of changes. 23 change blocks. 
66 lines changed or deleted 91 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/