draft-ietf-ccamp-gmpls-g709-framework-14.txt   draft-ietf-ccamp-gmpls-g709-framework-15.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: February 2, 2014 August 2, 2013 Expires: March 22, 2014 September 22, 2013
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-14.txt draft-ietf-ccamp-gmpls-g709-framework-15.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 February 2, 2014. This Internet-Draft will expire on March 22, 2014.
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 published in 2012. G.709 as published in 2012.
Table of Contents Table of Contents
1. Introduction .................................................. 2 1. Introduction ................................................. 2
2. Terminology ................................................... 3 2. Terminology .................................................. 3
3. G.709 Optical Transport Network ............................... 4 3. G.709 Optical Transport Network .............................. 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 ........................ 6 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 Label Switch Path (LSP) Hierarchy ...... 12 5.1. Implications for Label Switch Path (LSP) Hierarchy ...... 12
5.2. Implications for GMPLS Signaling ........................ 13 5.2. Implications for GMPLS Signaling ........................ 13
5.3. Implications for GMPLS Routing .......................... 15 5.3. Implications for GMPLS Routing .......................... 15
5.4. Implications for Link Management Protocol ............... 17 5.4. Implications for Link Management Protocol ............... 17
5.5. Implications for Control Plane Backward Compatibility ... 18 5.5. Implications for Control Plane Backward Compatibility ... 18
5.6. Implications for Path Computation Elements .............. 19 5.6. Implications for Path Computation Elements .............. 19
5.7. Implications for Management of GMPLS Networks ........... 19 5.7. Implications for Management of GMPLS Networks ........... 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 ................................. 23 10.2. Informative References ................................ 23
11. Authors' Addresses .......................................... 24 11. Authors' Addresses .......................................... 24
12. Contributors ................................................ 25 12. Contributors ................................................ 25
1. Introduction 1. Introduction
Optical Transport Networks (OTN) has become a mainstream layer 1 Optical Transport Networks (OTN) has become a mainstream layer 1
technology for the transport network. Operators want to introduce technology for the transport network. Operators want to introduce
control plane capabilities based on GMPLS to OTN, to realize the control plane capabilities based on GMPLS to OTN, to realize the
benefits associated with a high-function control plane (e.g., benefits associated with a high-function control plane (e.g.,
improved network resiliency, resource usage efficiency, etc.). improved network resiliency, resource usage efficiency, etc.).
skipping to change at page 4, line 16 skipping to change at page 4, line 16
is either directly mapped into an OTUk (k = j) or multiplexed into a is either directly mapped into an OTUk (k = j) or multiplexed into a
server HO ODUk (k > j) container. server HO ODUk (k > j) container.
HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, 4.) HO ODU: Higher Order ODU. The HO ODUk (k can be 1, 2, 2e, 3, 4.)
represents the entity transporting a multiplex of LO ODUj tributary represents the entity transporting a multiplex of LO ODUj tributary
signals in its OPUk area. signals in its OPUk area.
ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a ODUflex: Flexible ODU. A flexible ODUk can have any bit rate and a
bit rate tolerance of +/-100 ppm (parts per million). bit rate tolerance of +/-100 ppm (parts per million).
In general, throughout this document, 'ODUj' is used to refer to ODU
entities acting as LO ODU, and 'ODUk' is used to refer to ODU
entities being used as HO ODU.
3. G.709 Optical Transport Network 3. G.709 Optical Transport Network
This section provides an informative overview of those aspects of the This section provides an informative overview of those aspects of the
OTN impacting control plane protocols. This overview is based on the OTN impacting control plane protocols. This overview is based on the
ITU-T Recommendations that contain the normative definition of the ITU-T Recommendations that contain the normative definition of the
OTN. Technical details regarding OTN architecture and interfaces are OTN. Technical details regarding OTN architecture and interfaces are
provided in the relevant ITU-T Recommendations. provided in the relevant ITU-T Recommendations.
Specifically, [G872-2012] describes the functional architecture of Specifically, [G872-2012] describes the functional architecture of
optical transport networks providing optical signal transmission, optical transport networks providing optical signal transmission,
skipping to change at page 8, line 34 skipping to change at page 8, line 43
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 MSI, is correct demultiplexing. This information, known as MSI, is
transported in the OPUk overhead and is local to each link. In case transported in the OPUk overhead and is local to each link. In case
of bidirectional paths the association between TPN and TS must be the of bidirectional paths the association between TPN and TS must be the
same in both directions. 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.
- TPN: the port number of the ODUj transported by the HO ODUk. The - TPN: the port number of the ODUj transported by the HO ODUk. The
TPN is the same for all the TSs assigned to the transport of the TPN is the same for all the TSs assigned to the transport of the
same ODUj instance. 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 granularity is 2.5Gbps, and by 8 in the OPU3 overhead when the TS granularity is 2.5Gbps, and by 8
entries when the TS granularity is 1.25Gbps. entries when the TS granularity is 1.25Gbps.
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
(Referring to [G798-V4]): (Referring to [G798-V4]):
- The Transmitted MSI (TxMSI) information inserted in OPU (e.g., - The Transmitted MSI (TxMSI) information inserted in OPU (e.g.,
OPU3) overhead by the source of the HO ODUk trail. OPU3) overhead by the source of the HO ODUk trail.
- The expected MSI (ExMSI) information that is used to check the - The expected MSI (ExMSI) information that is used to check the
accepted MSI (AcMSI) information. The AcMSI information is the MSI accepted MSI (AcMSI) information. The AcMSI information is the MSI
valued received in-band, after a three-frame integration. valued received in-band, after a three-frame integration.
As described in [G798-V4], the sink of the HO ODU trail checks the As described in [G798-V4], the sink of the HO ODU trail checks the
complete content of the AcMSI information against the ExMSI. If the complete content of the AcMSI information against the ExMSI. If the
AcMSI is different from the ExMSI, then the traffic is dropped and a AcMSI is different from the ExMSI, then the traffic is dropped and a
payload mismatch alarm is generated. 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
skipping to change at page 10, line 19 skipping to change at page 10, line 30
mapped into an OCh. mapped into an OCh.
From the perspective of control plane, there are two kinds of network From the perspective of control plane, there are two kinds of network
topology to be considered. topology to be considered.
(1) ODU layer (1) ODU layer
In this case, the ODU links are presented between adjacent OTN nodes, In this case, the ODU links are presented between adjacent OTN nodes,
as illustrated in Figure 2. In this layer there are ODU links with a as illustrated in Figure 2. In this layer there are ODU links with a
variety of TSs available, and nodes that are Optical Digital Cross variety of TSs available, and nodes that are Optical Digital Cross
Connects (ODXCs). Lo ODU connections can be setup based on the Connects (ODXCs). LO ODU connections can be setup based on the
network topology. network topology.
Link #5 +--+---+--+ Link #4 Link #5 +--+---+--+ Link #4
+--------------------------| |--------------------------+ +--------------------------| |--------------------------+
| | ODXC | | | | ODXC | |
| +---------+ | | +---------+ |
| Node E | | Node E |
| | | |
+-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++ +-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++
| |Link #1 | |Link #2 | |Link #3 | | | |Link #1 | |Link #2 | |Link #3 | |
skipping to change at page 11, line 4 skipping to change at page 11, line 15
configuration of the ODUj to OTUk mapping (j = k) or multiplexing (j configuration of the ODUj to OTUk mapping (j = k) or multiplexing (j
< k), and demapping (j = k) or demultiplexing (j < k). < k), and 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., Reconfiguration Optical Add/Drop Multiplexer (ROADM), node (e.g., Reconfiguration Optical Add/Drop Multiplexer (ROADM),
Optical Cross-Connect (OXC)) that are capable of OCh switching, which Optical Cross-Connect (OXC)) that are capable of OCh switching, which
is illustrated in Figure 3 and Figure 4. There are ODU layer and OCh is illustrated in Figure 3 and Figure 4. There are ODU layer and OCh
layer, so it is simply a Multi-Layer Networks (MLN) (see [RFC6001]). layer, so it is simply a Multi-Layer Networks (MLN) (see [RFC6001]).
OCh connections may be created on demand, which is described in OCh connections may be created on demand, which is described in
section 5.1. 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 underlying 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 OCh represented. In Figure 3, the operator choice is to hide the real OCh
layer network topology. layer network topology.
Node E Node E
Link #5 +--------+ Link #4 Link #5 +--------+ Link #4
+------------------------| |------------------------+ +------------------------| |------------------------+
| ------ | | ------ |
skipping to change at page 12, line 5 skipping to change at page 12, line 20
| | +--+ | | | | +--+ | |
+-+-----+ +----+----+--| |--+-----+---+ +-----+-+ +-+-----+ +----+----+--| |--+-----+---+ +-----+-+
| |Link #1 | | +--+ | |Link #3 | | | |Link #1 | | +--+ | |Link #3 | |
| +--------+ | Node h | +--------+ | | +--------+ | Node h | +--------+ |
| ODXC | | ODXC +--------+ ODXC | | ODXC | | ODXC | | ODXC +--------+ ODXC | | ODXC |
+-------+ +---------+ Link #2+---------+ +-------+ +-------+ +---------+ Link #2+---------+ +-------+
Node A Node B Node C Node D Node A Node B Node C Node D
Figure 4 - OCh Visible Topology for LO ODUj connection management Figure 4 - OCh Visible Topology for LO ODUj connection management
In Figure 4, the cloud of previous figure is substitute by the real In Figure 4, the cloud of previous figure is substituted by the real
topology. The nodes f, g, h are nodes with OCh switching capability. topology. The nodes f, g, h are nodes with OCh switching capability.
In the examples (i.e., Figure 3 and Figure 4), we have considered the In the examples (i.e., Figure 3 and Figure 4), we have considered the
case in which LO ODUj connections are supported by OCh connection, case in which LO ODUj connections are supported by OCh connection,
and the case in which the supporting underlying connection can be and the case in which the supporting underlying connection can be
also made by a combination of HO ODU/OCh connections. also made by a combination of HO ODU/OCh connections.
In this case, the ODU routing/path selection process will request an In this case, the ODU routing/path selection process will request an
HO ODU/OCh connection between node C and node E from the OCh domain. HO ODU/OCh connection between node C and node E from the OCh domain.
The connection will appear at ODU level as a Forwarding Adjacency, The connection will appear at ODU level as a Forwarding Adjacency,
skipping to change at page 13, line 38 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 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 ODUj including: support the new ODUj including:
- ODU0 - ODU0
- ODU2e - ODU2e
- ODU4 - ODU4
- ODUflex - ODUflex
For ODUflex signal type, its bit rate must be carried additionally For ODUflex signal type, its bit rate must be carried additionally
in the Traffic Parameter to setup an ODUflex connection. in the Traffic Parameter to setup an ODUflex connection.
For other ODU signal types, their bit rates and tolerances are For other ODU signal types, their bit rates and tolerances are
fixed and can be deduced from the signal types. fixed and can be deduced from the signal types.
- Support for LSP setup using different TS granularity - Support for LSP setup using different TS granularity
The signaling protocol should be able to identify the TS The signaling protocol should be able to identify the TS
granularity (i.e., the 2.5Gbps TS granularity and the new 1.25Gbps granularity (i.e., the 2.5Gbps TS granularity and the new 1.25Gbps
TS granularity) to be used for establishing an Hierarchical LSP TS granularity) to be used for establishing an Hierarchical LSP
which will be used to carry service LSP(s) requiring specific TS which will be used to carry service LSP(s) requiring specific TS
granularity. granularity.
- 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
A new label format must be defined to carry the exact TSs A new label format must be defined to carry the exact TSs
allocation information related to the extended mapping and allocation information related to the extended mapping and
multiplexing hierarchy (For example, ODU0 into ODU2 multiplexing multiplexing hierarchy (For example, ODU0 into ODU2 multiplexing
(with 1.25Gbps TS granularity)), in order to set up the ODU (with 1.25Gbps TS granularity)), in order to set up the ODU
connection. connection.
- Support for TPN allocation and negotiation - Support for TPN allocation and negotiation
TPN needs to be configured as part of the MSI information (see TPN needs to be configured as part of the MSI information (see
more information in Section 3.1.2.1). A signaling mechanism must more information in Section 3.1.2.1). A signaling mechanism must
be identified to carry TPN information if control plane is used to be identified to carry TPN information if control plane is used to
configure MSI information. 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 ([G7042]). [RFC6344] has a clear description container using LCAS ([G7042]). [RFC6344] has a clear description
of VCAT and LCAS control in SONET/SDH and OTN. of VCAT and LCAS control in SONET/SDH and OTN.
- Support for Control of Hitless Adjustment of ODUflex (GFP) - Support for Control of Hitless Adjustment of ODUflex (GFP)
[G7044] has been created in ITU-T to specify Hitless Adjustment of [G7044] has been created in ITU-T to specify Hitless Adjustment of
ODUflex (GFP) (HAO) that is used to increase or decrease the 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.
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.
skipping to change at page 15, line 33 skipping to change at page 15, line 50
the switching capability and related Maximum LSP Bandwidth and the the switching capability and related Maximum LSP Bandwidth and the
Switching Capability specific information. When the Switching Switching Capability specific information. When the Switching
Capability field is TDM the Switching Capability Specific Information Capability field is TDM the Switching Capability Specific Information
field includes Minimum LSP Bandwidth, an indication whether the field includes Minimum LSP Bandwidth, an indication whether the
interface supports Standard or Arbitrary SONET/SDH, and padding. interface supports Standard or Arbitrary SONET/SDH, and padding.
Hence a new Switching Capability value needs to be defined for [G709- Hence a new Switching Capability value needs to be defined for [G709-
2012] ODU switching in order to allow the definition of a new 2012] ODU switching in order to allow the definition of a new
Switching Capability Specific Information field definition. The Switching Capability Specific Information field definition. The
following requirements should be considered: 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
The bit rate (i.e., bandwidth) of each TS is dependent on the TS The bit rate (i.e., bandwidth) of each 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.249409620Gbps, bandwidth of a 1.25G TS in an OTU2 is about 1.249409620Gbps,
while the bandwidth of a 1.25G TS in an OTU3 is about while the bandwidth of a 1.25G TS in an OTU3 is about
1.254703729Gbps. 1.254703729Gbps.
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 should be capable of carrying the Therefore, the routing protocol should be capable of carrying the
necessary link bandwidth information for performing accurate necessary link bandwidth information for performing accurate
route computation for any of the fixed rate ODUs as well as route computation for any of the fixed rate ODUs as well as
ODUflex. 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 restricted to signal being advertised by an interface could be restricted to
switched (i.e. forwarded to switching matrix without switched (i.e. forwarded to switching matrix without
multiplexing/demultiplexing actions), restricted to terminated multiplexing/demultiplexing actions), restricted to terminated
(demuxed) or both of them. The capability advertised by an (demuxed) or both of them. The capability advertised by an
interface needs further distinction in order to separate interface needs further distinction in order to separate
termination and switching capabilities. termination and 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-2012] defines two types of TS but each link can only [G709-2012] defines two types of TS but each link can only
support a single type at a given time. In order to perform a support a single type at a given time. In order to perform a
correct path computation (i.e. the LSP end points have matching correct path computation (i.e. the LSP end points have matching
Tributary Slot Granularity values) the Tributary Slot Granularity Tributary Slot Granularity values) the Tributary Slot Granularity
needs to be advertised. needs to be 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 up to 8 priority levels as defined in capable of supporting up to 8 priority levels as defined in
[RFC4202]. [RFC4202].
- Support link bundling - Support link bundling
As described in [RFC4201], link bundling can improve routing As described in [RFC4201], link bundling can improve routing
scalability by reducing the amount of TE links that has to be scalability by reducing the amount of TE links that has to be
handled by routing protocol. The routing protocol should be handled by routing protocol. The routing protocol should be
capable of supporting bundling multiple OTU links, at the same capable of supporting bundling multiple OTU links, at the same
line rate and muxing hierarchy, between a pair of nodes as a TE line rate and muxing hierarchy, between a pair of nodes as a TE
link. Note that link bundling is optional and is implementation link. Note that link bundling is optional and is implementation
dependent. 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
skipping to change at page 17, line 40 skipping to change at page 18, line 11
LMP [RFC4204] provides a control plane protocol for exchanging and LMP [RFC4204] provides a control plane protocol for exchanging and
correlating link capabilities. correlating link capabilities.
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 cases, routing is not present (e.g. User- routing. Since in certain cases, routing is not present (e.g. User-
Network Interface (UNI) case) we need to extend link management Network Interface (UNI) case) we need to extend link management
protocol capabilities to cover this aspect. In case of routing protocol capabilities to cover this aspect. In case of routing
presence, the discovery via LMP could also be optional. presence, the discovery via LMP 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.25Gbps granularity should fall back to 2.5Gbps node with 1.25Gbps granularity should fall back to 2.5Gbps
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-2012], Many new ODU signal types have been introduced in [G709-2012],
such as ODU0, ODU4, ODU2e and ODUflex. It is possible that such as ODU0, ODU4, ODU2e and ODUflex. It is possible that
equipment does not support all the LO ODU signal types introduced equipment does not support all the LO ODU signal types introduced
by those new standards or drafts. Furthermore, since multiplexing by those new standards or drafts. Furthermore, since multiplexing
hierarchy was not allowed by the legacy OTN referenced by hierarchy may not be supported by the legacy OTN, it is possible
[RFC4328], it is possible that only one end of an ODU link can that only one end of an ODU link can support multiplexing
support multiplexing hierarchy capability, or the two ends of the hierarchy capability, or the two ends of the link support
link support different multiplexing hierarchy capabilities (e.g., different multiplexing hierarchy capabilities (e.g., one end of
one end of the link supports ODU0 into ODU1 into ODU3 the link supports ODU0 into ODU1 into ODU3 multiplexing while the
multiplexing while the other end supports ODU0 into ODU2 into other end supports ODU0 into ODU2 into ODU3 multiplexing).
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
With the introduction of [G709-2012], there may be OTN composed of a With the introduction of [G709-2012], there may be OTN composed of a
mixture of nodes, some of which support the legacy OTN and run mixture of nodes, some of which support the legacy OTN and run
skipping to change at page 18, line 46 skipping to change at page 19, line 15
This section discusses the compatibility of nodes implementing the This section discusses the compatibility of nodes implementing the
control plane procedures defined [RFC4328], in support of the legacy control plane procedures defined [RFC4328], in support of the legacy
OTN, and the control plane procedures defined to support [G709-2012], OTN, and the control plane procedures defined to support [G709-2012],
as outlined by this document. as outlined by this document.
Compatibility needs to be considered only when controlling ODU1 or Compatibility needs to be considered only when controlling ODU1 or
ODU2 or ODU3 connection, because the legacy OTN only support these ODU2 or ODU3 connection, because the legacy OTN only support these
three ODU signal types. In such cases, there are several possible three ODU signal types. In such cases, there are several possible
options including: options including:
- A node supporting [G709-2012] could support only the [G709-2012] - A node supporting [G709-2012] could support only the [G709-2012]
related control plane procedures, in which case both types of related control plane procedures, in which case both types of
nodes would be unable to jointly control an LSP for an ODU type nodes would be unable to jointly control an LSP for an ODU type
that both nodes support in the data plane. Note that this case is that both nodes support in the data plane.
supported by the procedures defined in [RFC3473] as a different
Switching Capability/Type value is used for the different control
plane versions.
- A node supporting [G709-2012] could support both the [G709-2012] - A node supporting [G709-2012] could support both the [G709-2012]
related control plane and the control plane defined in [RFC4328]. related control plane and the control plane defined in [RFC4328].
o Such a node could identify which set of procedure to follow o Such a node could identify which set of procedure to follow
when initiating an LSP based on the Switching Capability value when initiating an LSP based on the Switching Capability value
advertised in routing. advertised in routing.
o Such a node could follow the set of procedures based on the o Such a node could follow the set of procedures based on the
Switching Type received in signaling messages from an upstream Switching Type received in signaling messages from an upstream
node. node.
o Such a node, when processing a transit LSP, could select which o Such a node, when processing a transit LSP, could select which
signaling procedures to follow based on the Switching signaling procedures to follow based on the Switching
Capability value advertised in routing by the next hop node. Capability value advertised in routing by the next hop node.
5.6. Implications for Path Computation Elements 5.6. Implications for Path Computation Elements
[PCE-APS] describes the requirements for GMPLS applications of PCE in [RFC7025] 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 Path Computation Client (PCC) or attributes appropriately once a Path Computation Client (PCC) or
another PCE requests a path computation. The TE attributes which can another PCE requests a path computation. The TE attributes which can
be contained in the path calculation request message from the PCC or be contained in the path calculation request message from the PCC or
the PCE defined in [RFC5440] includes switching capability, encoding the PCE defined in [RFC5440] includes switching capability, encoding
type, signal type, etc. type, signal type, etc.
As described in section 5.2.1, new signal types and new signals with As described in section 5.2, 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, PCE signaling message of path setup. For the same consideration, PCE
Communication Protocol (PCECP) also has a desire to be extended to Communication Protocol (PCECP) also has a desire to be extended to
carry the new signal type and related variable bandwidth information carry the new signal type and related variable bandwidth information
when a PCC requests a path computation. when a PCC requests a path computation.
5.7. Implications for Management of GMPLS Networks 5.7. Implications for Management of GMPLS Networks
From the management perspective, it should be capable of managing not From the management perspective, it should be capable of managing not
only the legacy OTN referenced by [RFC4328], but also new management only the legacy OTN referenced by [RFC4328], but also new management
skipping to change at page 23, line 37 skipping to change at page 24, line 5
(GMPLS) Architecture", RFC 3945, October 2004. (GMPLS) Architecture", RFC 3945, October 2004.
[RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path
Computation Element (PCE)-Based Architecture", Computation Element (PCE)-Based Architecture",
RFC 4655, August 2006. RFC 4655, August 2006.
[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
Zhang, "Requirements for GMPLS applications of PCE",
draft-ietf-pce-gmpls-aps-req, Work in Progress.
[RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC5920, July 2010. Networks", RFC5920, July 2010.
[RFC7025] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai
Zhang, "Requirements for GMPLS applications of PCE",
RFC7025, September 2013.
[TDM-OAM] A. Kern, A. Takacs, "GMPLS RSVP-TE Extensions for [TDM-OAM] A. Kern, A. Takacs, "GMPLS RSVP-TE Extensions for
SONET/SDH and OTN OAM Configuration", draft-ietf-ccamp- SONET/SDH and OTN OAM Configuration", draft-ietf-ccamp-
rsvp-te-sdh-otn-oam-ext, Work in Progress. rsvp-te-sdh-otn-oam-ext, Work in Progress.
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
skipping to change at page 25, line 17 skipping to change at page 25, line 29
Jianrui Han Jianrui Han
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
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-28972913 Phone: +86-755-28972913
Email: hanjianrui@huawei.com Email: hanjianrui@huawei.com
Malcolm Betts Malcolm Betts
Huawei Technologies Co., Ltd.
Email: malcolm.betts@huawei.com Email: malcolm.betts@rogers.com
Pietro Grandi Pietro Grandi
Alcatel-Lucent Alcatel-Lucent
Optics CTO Optics CTO
Via Trento 30 20059 Vimercate (Milano) Italy Via Trento 30 20059 Vimercate (Milano) Italy
+39 039 6864930 +39 039 6864930
Email: pietro_vittorio.grandi@alcatel-lucent.it Email: pietro_vittorio.grandi@alcatel-lucent.it
Eve Varma Eve Varma
Alcatel-Lucent Alcatel-Lucent
 End of changes. 46 change blocks. 
64 lines changed or deleted 61 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/