draft-ietf-ccamp-gmpls-g709-framework-06.txt   draft-ietf-ccamp-gmpls-g709-framework-07.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: September 8, 2012 March 8, 2012 Expires: November 30, 2012 May 31, 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-06.txt draft-ietf-ccamp-gmpls-g709-framework-07.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 September 8, 2012. This Internet-Draft will expire on November 30, 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.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
Table of Contents Table of Contents
1. Introduction .................................................. 2 1. Introduction .................................................. 3
2. Terminology ................................................... 3 2. Terminology ................................................... 3
3. G.709 Optical Transport Network (OTN) ......................... 4 3. G.709 Optical Transport Network (OTN) ......................... 4
3.1. OTN Layer Network ........................................ 4 3.1. OTN Layer Network ........................................ 4
3.1.1. Client signal mapping ............................... 5 3.1.1. 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 Control Plane Backward Compatibility ... 19 5.5. Implications for Control Plane Backward Compatibility ... 19
5.6. Implications for Path Computation Elements .............. 20 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 ...................................... 21 7. Security Considerations ...................................... 21
8. IANA Considerations .......................................... 21 8. IANA Considerations .......................................... 21
9. Acknowledgments .............................................. 21 9. Acknowledgments .............................................. 22
10. References .................................................. 21 10. References .................................................. 22
10.1. Normative References ................................... 21 10.1. Normative References ................................... 22
10.2. Informative References ................................. 23 10.2. Informative References ................................. 23
11. Authors' Addresses .......................................... 24 11. Authors' Addresses .......................................... 24
12. Contributors ................................................ 25 12. Contributors ................................................ 25
APPENDIX A: ODU connection examples ............................. 25 APPENDIX A: ODU connection examples ............................. 26
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 11, line 6 skipping to change at page 11, line 6
+-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++ +-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++
| |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 LO ODU connection management Figure 2 - Example Topology for LO ODU connection management
If an ODUj connection is requested between Node C and Node E If an ODUj connection is requested between Node C and Node E
routing/path computation must select a path that has the required routing/path computation MUST select a path that has the required
number of TS available and that offers the lowest cost. Signaling is number of TS available and that offers the lowest cost. Signaling is
then invoked to set up the path and to provide the information (e.g., then invoked to set up the path and to provide the information (e.g.,
selected TS) required by each transit node to allow the configuration selected TS) required by each transit node to allow the configuration
of the ODUj to OTUk mapping (j = k) or multiplexing (j < k), and of the ODUj to OTUk mapping (j = k) or multiplexing (j < k), and
demapping (j = k) or demultiplexing (j < k). demapping (j = k) or demultiplexing (j < k).
(2) ODU layer with OCh switching capability (2) ODU layer with OCh switching capability
In this case, the OTN nodes interconnect with wavelength switched In this case, the OTN nodes interconnect with wavelength switched
node (e.g., ROADM, OXC) that are capable of OCh switching, which is node (e.g., ROADM, OXC) that are capable of OCh switching, which is
skipping to change at page 14, line 4 skipping to change at page 14, line 4
As described in Section 3, [G709-V3] introduced some new features As described in Section 3, [G709-V3] introduced some new features
that include the ODU0, ODU2e, ODU4 and ODUflex containers. The that include the ODU0, ODU2e, ODU4 and ODUflex containers. The
mechanisms defined in [RFC4328] do not support such new OTN features, mechanisms defined in [RFC4328] do not support such new OTN features,
and protocol extensions will be necessary to allow them to be and protocol extensions will be necessary to allow them to be
controlled by a GMPLS control plane. controlled by a GMPLS control plane.
[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 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
For ODUflex, since it has a variable bandwidth/bit rate BR and a For ODUflex, since it has a variable bandwidth/bit rate BR and a
bit rate tolerance T, the (node local) mapping process must be bit rate tolerance T, the (node local) mapping process SHOULD 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) (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 MUST 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 ODU layer multiplexing hierarchy signaling - Support for ODU layer multiplexing hierarchy signaling
ODU layer multiplexing hierarchy has been supported by [G709-V3], ODU layer multiplexing hierarchy has been supported by [G709-V3],
i.e., a client ODUj connection can be nested into server layer i.e., a client ODUj connection can be nested into server layer
ODUk (j<k) connection. Control plane should provide mechanisms to ODUk (j<k) connection. Control plane SHOULD provide mechanisms to
support creation of such ODU hierarchy. support creation of such ODU hierarchy.
When creating server layer ODU LSP for carrying one specific When creating server layer ODU LSP for carrying one specific
client LSP, the first and last hop of the server LSP should be 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 capable of selecting the correct link to make sure that both ends
of the server LSP can support multiplexing/demultiplexing client of the server LSP can support multiplexing/demultiplexing client
signal into / from server LSP. signal into / from server LSP.
Therefore, the adaption information (e.g., hierarchical Therefore, the adaption information (e.g., hierarchical
information and TSG) should be carried in the signaling to make information and TSG) SHOULD be carried in the signaling to make
the penultimate node of the FA-LSP to select the correct link for the penultimate node of the FA-LSP to select the correct link for
carrying the specific client signal. 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.
skipping to change at page 16, line 5 skipping to change at page 16, line 5
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.
From the perspective of control plane, the control of ODUflex From the perspective of control plane, the control of ODUflex
resizing is similar to control of bandwidth increasing and resizing is similar to control of bandwidth increasing and
decreasing described in [RFC3209]. Therefore, the SE style can be decreasing described in [RFC3209]. Therefore, the SE style can be
used for control of HAO. 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 needs to 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 needs to evaluate the available bandwidth on each candidate link.
routing protocol should be extended to convey some information to The routing protocol SHOULD be extended to convey some information to
represent ODU TE topology. represent ODU TE topology.
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 issues Descriptor of TDM which can be used for ODU. However, some issues
discussed below, should also be considered. discussed below, SHOULD also be considered.
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. Hence a new Switching Capability Arbitrary SONET/SDH, and padding. Hence a new Switching Capability
value needs to be defined for [G709-V3] ODU switching in order to value needs to be defined for [G709-V3] ODU switching in order to
allow the definition of a new Switching Capability Specific allow the definition of a new Switching Capability Specific
Information field definition. The following requirements should be Information field definition. The following requirements SHOULD be
considered: considered:
- Support for carrying the link multiplexing capability - Support for carrying the link multiplexing capability
As discussed in section 3.1.2, many different types of ODUj can As discussed in section 3.1.2, many different types of ODUj can
be multiplexed into the same OTUk. For example, both ODU0 and be multiplexed into the same OTUk. For example, both ODU0 and
ODU1 may be multiplexed into ODU2. An OTU link may support one or ODU1 may be multiplexed into ODU2. An OTU link may support one or
more types of ODUj signals. The routing protocol should be more types of ODUj signals. The routing protocol SHOULD be
capable of carrying this multiplexing capability. capable of carrying this multiplexing capability.
- Support any ODU and ODUflex - Support any ODU and ODUflex
The bit rate (i.e., bandwidth) of TS is dependent on the TS The bit rate (i.e., bandwidth) of TS is dependent on the TS
granularity and the signal type of the link. For example, the granularity and the signal type of the link. For example, the
bandwidth of a 1.25G TS in an OTU2 is about 1.249409620 Gbps, bandwidth of a 1.25G TS in an OTU2 is about 1.249409620 Gbps,
while the bandwidth of a 1.25G TS in an OTU3 is about 1.254703729 while the bandwidth of a 1.25G TS in an OTU3 is about 1.254703729
Gbps. Gbps.
One LO ODU may need different number of TSs when multiplexed into One LO ODU may need different number of TSs when multiplexed into
different HO ODUs. For example, for ODU2e, 9 TSs are needed when different HO ODUs. For example, for ODU2e, 9 TSs are needed when
multiplexed into an ODU3, while only 8 TSs are needed when multiplexed into an ODU3, while only 8 TSs are needed when
multiplexed into an ODU4. For ODUflex, the total number of TSs to multiplexed into an ODU4. For ODUflex, the total number of TSs to
be reserved in a HO ODU equals the maximum of [bandwidth of be reserved in a HO ODU equals the maximum of [bandwidth of
ODUflex / bandwidth of TS of the HO ODU]. ODUflex / bandwidth of TS of the HO ODU].
Therefore, the routing protocol must be capable of carrying the Therefore, the routing protocol SHOULD be capable of carrying the
necessary and sufficient link bandwidth information for necessary and sufficient link bandwidth information for
performing accurate route computation for any of the fixed rate performing accurate route computation for any of the fixed rate
ODUs as well as ODUflex. ODUs as well as ODUflex.
- Support for differentiating between terminating and switching - Support for differentiating between terminating and switching
capability capability
Due to internal constraints and/or limitations, the type of Due to internal constraints and/or limitations, the type of
signal being advertised by an interface could be just switched signal being advertised by an interface could be just switched
(i.e. forwarded to switching matrix without (i.e. forwarded to switching matrix without
multiplexing/demultiplexing actions), just terminated (demuxed) multiplexing/demultiplexing actions), just terminated (demuxed)
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 [G709-V3] defines two types of TS but each link can only support
a 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. amount of TE links that has to be handled by routing protocol.
The routing protocol must be capable of supporting bundling The routing protocol SHOULD be capable of supporting bundling
multiple OTU links, at the same line rate and muxing hierarchy, multiple OTU links, at the same line rate and muxing hierarchy,
between a pair of nodes as a TE link. Note that link bundling is between a pair of nodes as a TE link. Note that link bundling is
optional 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)
The control plane should support hitless adjustment of ODUflex, The control plane SHOULD support hitless adjustment of ODUflex,
so the routing protocol should be capable of differentiating so the routing protocol SHOULD be capable of differentiating
whether an ODU link can support hitless adjustment of ODUflex whether an ODU link can support hitless adjustment of ODUflex
(GFP) or not, and how much resource can be used for resizing. (GFP) or not, and how much resource can be used for resizing.
This can be achieved by introducing a new signal type This can be achieved by introducing a new signal type
"ODUflex(GFP-F), resizable" that implies the support for hitless "ODUflex(GFP-F), resizable" that implies the support for hitless
adjustment of ODUflex (GFP) by that link. 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)
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.
It is not necessary to use LMP to correlate link-end capabilities if It is not necessary to use LMP to correlate link-end capabilities if
the information is available from another source such as management the information is available from another source such as management
configuration or automatic discovery/negotiation within the data configuration or automatic discovery/negotiation within the data
plane. plane.
Note that LO ODU type information can be, in principle, discovered by Note that LO ODU type information can be, in principle, discovered by
routing. Since in certain case, routing is not present (e.g. UNI case) routing. Since in certain case, routing is not present (e.g. UNI case)
we need to extend link management protocol capabilities to cover this we need to extend link management protocol capabilities to cover this
aspect. In case of routing presence, the discovering procedure by LMP aspect. In case of routing presence, the discovering procedure by LMP
could also be optional. could also be optional.
- Correlating the granularity of the TS - Correlating the granularity of the TS
As discussed in section 3.1.2, the two ends of a link may support As discussed in section 3.1.2, the two ends of a link may support
different TS granularity. In order to allow interconnection the different TS granularity. In order to allow interconnection the
node with 1.25Gb/s granularity must fall back to 2.5Gb/s node with 1.25Gb/s granularity SHOULD fall back to 2.5Gb/s
granularity. granularity.
Therefore, it is necessary for the two ends of a link to Therefore, it is necessary for the two ends of a link to
correlate the granularity of the TS. This ensures the correct use correlate the granularity of the TS. This ensures the correct use
and of the TE link. and of the TE link.
- Correlating the supported LO ODU signal types and multiplexing - Correlating the supported LO ODU signal types and multiplexing
hierarchy capability hierarchy capability
Many new ODU signal types have been introduced in [G709-V3], such Many new ODU signal types have been introduced in [G709-V3], such
skipping to change at page 19, line 30 skipping to change at page 19, line 30
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 Control Plane Backward Compatibility 5.5. Implications for Control Plane Backward Compatibility
Assume [RFC4328] has been deployed to control the OTN networks With the introduction of G709-v3, there may be OTN networks composed
supporting [G709-V1], control plane backward compatibility needs to of a mixture of nodes, some of which support [G709-V1] and run
be taken into consideration. Scenarios for backward compatibility are control plane protocols defined in [RFC4328] (referred to as legacy
described as follows: nodes), while others support [G709-V3] and new OTN control plane
characterized in this document (referred to as new nodes). In such
o Legacy OTN devices supporting [G709-V1] may run control plane case, control plane backward compatibility needs to be taken into
protocol defined in [RFC4328]; consideration (Note that a third case, for the sake of completeness,
consists on G709-V1 nodes with a new OTN control plane, but such
o Legacy OTN devices supporting [G709-V1] may also support new OTN nodes can be considered as new nodes with limited capabilities).
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 In order to provide backward compatibility, a new Switching
interworking scenarios. Capability type is required for the control of [G709-V3] both in
routing and signaling.
Based on these scenarios, control plane backward compatibility SHOULD From a routing perspective, the advertisement of LSAs carrying new
be taken into account when interworking between the new control plane Switching Capability type implies the support of new OTN control
characterized in this document and the legacy control plane defined plane protocols. A new node MUST support both legacy routing (i.e.,
in [RFC4328]. the procedures defined in [RFC4203] with the switching capabilities
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.
A new Switching Capability type is required for control of [G709-V3] On the other hand, from a signaling perspective, a new node MUST
in the routing and signaling to enable the backward procedure. support both the legacy signaling procedures defined in [RFC4328] and
the new procedures for control of [G709-V3]. Based on the routing
information, a new node can determine whether its neighbor node is a
legacy one or new one, so that it can determine which signaling
procedure (new or legacy signaling procedure) needs to be performed.
In case the new node has not enough information to know which
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
message indicating an unsupported Switching Capability type, the new
node can perform the signaling again with a procedure [RFC4328]
compliant.
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 21, line 22 skipping to change at page 21, line 43
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
documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], documents that define the protocols ([RFC3473], [RFC4203], [RFC4205],
[RFC4204], and [RFC5440]). [GMPLS-SEC] provides an overview of [RFC4204], and [RFC5440]). [RFC5920] provides an overview of security
security vulnerabilities and protection mechanisms for the GMPLS vulnerabilities and protection mechanisms for the GMPLS control plane.
control plane.
8. IANA Considerations 8. IANA Considerations
This document makes not requests for IANA action. This document makes not requests for IANA action.
9. Acknowledgments 9. 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.
skipping to change at page 23, line 11 skipping to change at page 23, line 28
[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.
[RFC6344] G. Bernstein et al, "Operating Virtual Concatenation [RFC6344] G. Bernstein et al, "Operating Virtual Concatenation
(VCAT) and the Link Capacity Adjustment Scheme (LCAS) (VCAT) and the Link Capacity Adjustment Scheme (LCAS)
with Generalized Multi-Protocol Label Switching (GMPLS)", with Generalized Multi-Protocol Label Switching (GMPLS)",
RFC6344, August, 2011. RFC6344, August, 2011.
[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 and Amendment2, April 2011.
10.2. Informative References 10.2. Informative References
[G709-V1] ITU-T, "Interface for the Optical Transport Network [G709-V1] ITU-T, "Interface for the Optical Transport Network
(OTN)," G.709 Recommendation and Amendment1, November (OTN)," G.709 Recommendation and Amendment1, November
2001. 2001.
[G709-V2] ITU-T, "Interface for the Optical Transport Network [G709-V2] ITU-T, "Interface for the Optical Transport Network
(OTN)," G.709 Recommendation, March 2003. (OTN)," G.709 Recommendation, March 2003.
[G7042] ITU-T G.7042/Y.1305, "Link capacity adjustment scheme [G7042] ITU-T, "Link capacity adjustment scheme (LCAS) for
(LCAS) for virtual concatenated signals", March 2006. virtual concatenated signals", G.7042/Y.1305, March 2006.
[G872-2001] ITU-T, "Architecture of optical transport networks", [G872-2001] ITU-T, "Architecture of optical transport networks",
November 2001 (11 2001). G.872 Recommendation, November 2001.
[G872-Am2] Draft Amendment 2, ITU-T, "Architecture of optical [G872-Am2] ITU-T, "Architecture of optical transport networks",
transport networks". G.872 Recommendation and Amendment 2, July 2010.
[G.7044] ITU-T, "Hitless adjustment of ODUflex", G.7044 (and [G.7044] ITU-T, "Hitless adjustment of ODUflex", G.7044 (and
Amendment 1), February 2012. Amendment 1), February 2012.
[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.
[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-04.txt, May 30,2011. draft-ietf-pce-gmpls-aps-req, Work in Progress.
[GMPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, October 2009. Networks", 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
skipping to change at page 25, line 43 skipping to change at page 26, line 18
Murray Hill, NJ 07974-0636 Murray Hill, NJ 07974-0636
USA USA
Email: eve.varma@alcatel-lucent.com Email: eve.varma@alcatel-lucent.com
APPENDIX A: ODU connection examples APPENDIX A: ODU connection examples
This appendix provides a description of ODU terminology and This appendix provides a description of ODU terminology and
connection examples. This section is not normative, and is just connection examples. This section is not normative, and is just
intended to facilitate understanding. intended to facilitate understanding.
In order to transmit a client signal, an ODU connection must first be In order to transmit a client signal, an ODU connection needs to be
created. From the perspective of [G709-V3] and [G872-Am2], some types created first. From the perspective of [G709-V3] and [G872-Am2], some
of ODUs (i.e., ODU1, ODU2, ODU3, ODU4) may assume either a client or types of ODUs (i.e., ODU1, ODU2, ODU3, ODU4) may assume either a
server role within the context of a particular networking domain: client or server role within the context of a particular networking
domain:
(1) An ODUj client that is mapped into an OTUk server. For example, (1) An ODUj client that is mapped into an OTUk server. For example,
if a STM-16 signal is encapsulated into ODU1, and then the ODU1 is if a STM-16 signal is encapsulated into ODU1, and then the ODU1 is
mapped into OTU1, the ODU1 is a LO ODU (from a multiplexing mapped into OTU1, the ODU1 is a LO ODU (from a multiplexing
perspective). perspective).
(2) An ODUj client that is mapped into an ODUk (j < k) server (2) An ODUj client that is mapped into an ODUk (j < k) server
occupying several TSs. For example, if ODU1 is multiplexed into ODU2, occupying several TSs. For example, if ODU1 is multiplexed into ODU2,
and ODU2 is mapped into OTU2, the ODU1 is a LO ODU and the ODU2 is a and ODU2 is mapped into OTU2, the ODU1 is a LO ODU and the ODU2 is a
HO ODU (from a multiplexing perspective). HO ODU (from a multiplexing perspective).
 End of changes. 43 change blocks. 
75 lines changed or deleted 95 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/