draft-ietf-ccamp-gmpls-g709-framework-04.txt   draft-ietf-ccamp-gmpls-g709-framework-05.txt 
Network Working Group Fatai Zhang 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 11, 2011 March 11, 2011 Expires: March 9, 2012 September 9, 2011
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-04.txt draft-ietf-ccamp-gmpls-g709-framework-05.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 11, 2011. This Internet-Draft will expire on March 9, 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 24 skipping to change at page 2, line 24
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 Path Computation Elements .............. 19
6. Data Plane Backward Compatibility Considerations ............. 19 6. Data Plane Backward Compatibility Considerations ............. 20
7. Security Considerations ..................................... 20 7. Security Considerations ...................................... 20
8. IANA Considerations .......................................... 20 8. IANA Considerations .......................................... 21
9. Acknowledgments .............................................. 20 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 ................................. 22
11. Authors' Addresses .......................................... 23 11. Authors' Addresses .......................................... 23
12. Contributors ................................................ 24 12. Contributors ................................................ 24
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
skipping to change at page 3, line 22 skipping to change at page 3, line 22
G.709 specification, including [G709-V3], have included some new G.709 specification, including [G709-V3], have included some new
features; for example, various multiplexing structures, two types of features; for example, various multiplexing structures, two types of
TSs (i.e., 1.25Gbps and 2.5Gbps), and extension of the Optical Data TSs (i.e., 1.25Gbps and 2.5Gbps), and extension of the Optical Data
Unit (ODU) ODUj definition to include the ODUflex function. Unit (ODU) ODUj definition to include the ODUflex function.
This document reviews relevant aspects of OTN technology evolution This document reviews relevant aspects of OTN technology evolution
that affect the GMPLS control plane protocols and examines why and that affect the GMPLS control plane protocols and examines why and
how to update the mechanisms described in [RFC4328]. This document how to update the mechanisms described in [RFC4328]. This document
additionally provides a framework for the GMPLS control of OTN additionally provides a framework for the GMPLS control of OTN
networks and includes a discussion of the implication for the use of networks and includes a discussion of the implication for the use of
the Path Computation Element (PCE) [RFC4655]. No additional Switching the Path Computation Element (PCE) [RFC4655].
Type and LSP Encoding Type are required to support the control of the
evolved OTN, because the Switching Type and LSP Encoding Type defined
in [RFC4328] are still applicable.
For the purposes of the control plane the OTN can be considered as For the purposes of the control plane the OTN can be considered as
being comprised of ODU and wavelength (OCh) layers. This document being comprised of ODU and wavelength (OCh) layers. This document
focuses on the control of the ODU layer, with control of the focuses on the control of the ODU layer, with control of the
wavelength layer considered out of the scope. Please refer to [WSON- wavelength layer considered out of the scope. Please refer to
Frame] for further information about the wavelength layer. [RFC6163] for further information about the wavelength layer.
2. Terminology 2. Terminology
OTN: Optical Transport Network OTN: Optical Transport Network
ODU: Optical Channel Data Unit ODU: Optical Channel Data Unit
OTU: Optical channel transport unit OTU: Optical channel transport unit
OMS: Optical multiplex section OMS: Optical multiplex section
skipping to change at page 8, line 40 skipping to change at page 8, line 40
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
- The expectedMSI information that is used to check the acceptedMSI information. The acceptedMSI information is the MSI valued received
information. The acceptedMSI information is the MSI valued in-band, after a 3 frames integration.
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
base. base.
4. Connection management in OTN 4. Connection management in OTN
OTN-based connection management is concerned with controlling the OTN-based connection management is concerned with controlling the
connectivity of ODU paths and optical channels (OCh). This document connectivity of ODU paths and optical channels (OCh). This document
focuses on the connection management of ODU paths. The management of focuses on the connection management of ODU paths. The management of
OCh paths is described in [WSON-FRAME]. OCh paths is described in [RFC6163].
While [G872-2001] considered the ODU as a set of layers in the same While [G872-2001] considered the ODU as a set of layers in the same
way as SDH has been modeled, recent ITU-T OTN architecture progress way as SDH has been modeled, recent ITU-T OTN architecture progress
[G872-Am2] includes an agreement to model the ODU as a single layer [G872-Am2] includes an agreement to model the ODU as a single layer
network with the bit rate as a parameter of links and connections. network with the bit rate as a parameter of links and connections.
This allows the links and nodes to be viewed in a single topology as This allows the links and nodes to be viewed in a single topology as
a common set of resources that are available to provide ODUj a common set of resources that are available to provide ODUj
connections independent of the value of j. Note that when the bit connections independent of the value of j. Note that when the bit
rate of ODUj is less than the server bit rate, ODUj connections are rate of ODUj is less than the server bit rate, ODUj connections are
supported by HO-ODU (which has a one-to-one relationship with the supported by HO-ODU (which has a one-to-one relationship with the
skipping to change at page 13, line 12 skipping to change at page 13, line 9
The path computation for ODU connection request is based on the The path computation for ODU connection request is based on the
topology of ODU layer, including OCh layer visibility. topology of ODU layer, including OCh layer visibility.
The OTN path computation can be divided into two layers. One layer is The OTN path computation can be divided into two layers. One layer is
OCh/OTUk, the other is ODUj. [RFC4206] and [RFC6107] define the OCh/OTUk, the other is ODUj. [RFC4206] and [RFC6107] define the
mechanisms to accomplish creating the hierarchy of LSPs. The LSP mechanisms to accomplish creating the hierarchy of LSPs. The LSP
management of multiple layers in OTN can follow the procedures management of multiple layers in OTN can follow the procedures
defined in [RFC4206], [RFC6107] and related MLN drafts. defined in [RFC4206], [RFC6107] and related MLN drafts.
As discussed in section 4, the route path computation for OCh is in As discussed in section 4, the route path computation for OCh is in
the scope of WSON [WSON-Frame]. Therefore, this document only the scope of WSON [RFC6163]. Therefore, this document only considers
considers ODU layer for ODU connection request. ODU layer for ODU connection request.
LSP hierarchy could be applied within the ODU layers. One of the LSP hierarchy can also be applied within the ODU layers. One of the
typical scenarios for ODU layer hierarchy is to maintain typical scenarios for ODU layer hierarchy is to maintain
compatibility with introducing new [G709-V3] services (e.g., ODU0, compatibility with introducing new [G709-V3] services (e.g., ODU0,
ODUflex) into a legacy network configuration (containing [G709-V1] or ODUflex) into a legacy network configuration (containing [G709-V1] or
[G709-V2] OTN equipment). In this scenario, it may be needed to [G709-V2] OTN equipment). In this scenario, it may be needed to
consider introducing hierarchical multiplexing capability in specific consider introducing hierarchical multiplexing capability in specific
network transition scenarios. One method for enabling multiplexing network transition scenarios. One method for enabling multiplexing
hierarchy is by introducing dedicated boards in a few specific places hierarchy is by introducing dedicated boards in a few specific places
in the network and tunneling these new services through [G709-V1] or in the network and tunneling these new services through [G709-V1] or
[G709-V2] containers (ODU1, ODU2, ODU3), thus postponing the need to [G709-V2] containers (ODU1, ODU2, ODU3), thus postponing the need to
upgrade every network element to [G709-V3] capabilities. upgrade every network element to [G709-V3] capabilities.
skipping to change at page 14, line 12 skipping to change at page 14, line 9
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
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 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
New label should be defined to identify the type of TS (i.e., the The signaling protocol should be able to identify the type of TS
2.5 Gbps TS granularity and the new 1.25 Gbps TS granularity). (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
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
skipping to change at page 15, line 13 skipping to change at page 15, line 26
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]). [VCAT] has a clear description of container using LCAS ([G.7042]). [RFC6344] has a clear description
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 constraint signaling
How an ODUk connection service is transported within an operator How an ODUk connection service is transported within an operator
network is governed by operator policy. For example, the ODUk network is governed by operator policy. For example, the ODUk
connection service might be transported over an ODUk path over an connection service might be transported over an ODUk path over an
OTUk section, with the path and section being at the same rate as OTUk section, with the path and section being at the same rate as
that of the connection service. In this case, an entire lambda of that of the connection service. In this case, an entire lambda of
capacity is consumed in transporting the ODUk connection service. capacity is consumed in transporting the ODUk connection service.
On the other hand, the operator might leverage sub-lambda On the other hand, the operator might leverage sub-lambda
skipping to change at page 15, line 36 skipping to change at page 15, line 49
efficiencies within any given networking domain. In this case, efficiencies within any given networking domain. In this case,
ODUk multiplexing may be performed prior to transport over various ODUk multiplexing may be performed prior to transport over various
rate ODU servers over associated OTU sections. rate ODU servers over associated OTU sections.
The identification of constraints and associated encoding in the The identification of constraints and associated encoding in the
signaling for differentiating full lambda LSP or sub lambda LSP is signaling for differentiating full lambda LSP or sub lambda LSP is
for further study. for further study.
- Support for Control of Hitless Adjustment of ODUflex (GFP) - Support for Control of Hitless Adjustment of ODUflex (GFP)
[G.HAO] has been created in ITU-T to specify hitless adjustment of [G.7044] has been created in ITU-T to specify hitless adjustment
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.HAO] is being developed currently, the control of HAO Since the [G.7044] is being developed currently, the control of
is for further study. HAO is for further study.
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 a The path computation process should select a suitable route for an
ODUj connection request. In order to compute the lowest cost path 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
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 other Descriptor of TDM which can be used for ODU. However, some issues
issues should also be considered which are discussed below. 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. So routing protocol should be Arbitrary SONET/SDH, and padding. Hence a new Switching Capability
extended when TDM is ODU type to support representation of ODU value needs to be defined for [G709-V3] ODU switching in order to
switching information, especially the following requirements should allow the definition of a new Switching Capability Specific
be considered: Information field definition. The following requirements should be
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
skipping to change at page 17, line 28 skipping to change at page 17, line 42
(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 different priorities for resource reservation - Support for Tributary Slot Granularity advertisement
[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
computation (i.e. the LSP end points have matching Tributary Slot
Granularity values) the Tributary Slot Granularity needs to be
advertised.
- 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
The routing protocol must be capable of supporting bundling routing protocol must be capable of supporting bundling multiple
multiple OTU links, at the same or different line rates, between OTU links, at the same line rate and muxing hierarchy, between a
a pair of nodes as a TE link. Note that link bundling is optional pair of nodes as a TE link. Note that link bundling is optional
and is implementation dependent. 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 As described in Section 5.2, the routing requirements for
supporting hitless adjustment of ODUflex (GFP) (HAO) are for supporting hitless adjustment of ODUflex (GFP) (G.7044) are for
further study. further study.
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 18, line 41 skipping to change at page 19, line 13
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 must 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 to allocate the correlate the granularity of the TS. This ensures the correct use
TS over the TE link correctly. 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
as ODU0, ODU4, ODU2e and ODUflex. It is possible that equipment as ODU0, ODU4, ODU2e and ODUflex. It is possible that equipment
does not support all the LO ODU signal types introduced by those does not support all the LO ODU signal types introduced by those
new standards or drafts. Furthermore, since multiplexing new standards or drafts. Furthermore, since multiplexing
hierarchy is not allowed before [G709-V3], it is possible that hierarchy is not allowed before [G709-V3], it is possible that
only one end of an ODU link can support multiplexing hierarchy only one end of an ODU link can support multiplexing hierarchy
skipping to change at page 22, line 14 skipping to change at page 22, line 25
[RFC6001] Dimitri Papadimitriou et al, "Generalized Multi-Protocol [RFC6001] Dimitri Papadimitriou et al, "Generalized Multi-Protocol
Label Switching (GMPLS) Protocol Extensions for Multi- Label Switching (GMPLS) Protocol Extensions for Multi-
Layer and Multi-Region Networks (MLN/MRN)", RFC6001, Layer and Multi-Region Networks (MLN/MRN)", RFC6001,
February 21, 2010. February 21, 2010.
[RFC5440] JP. Vasseur, JL. Le Roux, Ed.," Path Computation Element [RFC5440] JP. Vasseur, JL. Le Roux, Ed.," Path Computation Element
(PCE) Communication Protocol (PCEP)", RFC 5440, March (PCE) Communication Protocol (PCEP)", RFC 5440, March
2009. 2009.
[VCAT] 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)",
draft-ietf-ccamp-gmpls-vcat-lcas-11.txt, March 9, 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, December 2009.
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.
skipping to change at page 22, line 40 skipping to change at page 23, line 5
[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.HAO] TD 382 (WP3/15), 31 May - 11 June 2010, Q15 Plenary [G.7044] TD 382 (WP3/15), 31 May - 11 June 2010, Q15 Plenary
Meeting in Geneva, Initial draft G.hao "Hitless Meeting in Geneva, Initial draft G.7044 "Hitless
Adjustment of ODUflex (HAO)". 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.
[WSON-FRAME] 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)", draft-ietf-ccamp-rwa-wson-framework, work in (WSON)", RFC6163, April 2011.
progress.
[PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai [PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai
Zhang, "Requirements for GMPLS applications of PCE", Zhang, "Requirements for GMPLS applications of PCE",
draft-ietf-pce-gmpls-aps-req-01.txt, July 2009. draft-ietf-pce-gmpls-aps-req-04.txt, May 30,2011.
[GMPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS [GMPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, October 2009. Networks", Work in Progress, October 2009.
11. Authors' Addresses 11. Authors' Addresses
Fatai Zhang 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
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Dan Li Dan Li
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
 End of changes. 36 change blocks. 
64 lines changed or deleted 81 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/