draft-ietf-ccamp-gmpls-g709-framework-07.txt   draft-ietf-ccamp-gmpls-g709-framework-08.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: November 30, 2012 May 31, 2012 Expires: December 19, 2012 June 19, 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-07.txt draft-ietf-ccamp-gmpls-g709-framework-08.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 November 30, 2012. This Internet-Draft will expire on December 19, 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 .................................................. 3 1. Introduction .................................................. 2
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 ........................ 6
3.1.2.1. Structure of MSI information ................... 8 3.1.2.1. Structure of MSI information ................... 8
4. Connection management in OTN .................................. 9 4. Connection management in OTN .................................. 9
4.1. Connection management of the ODU ........................ 10 4.1. Connection management of the ODU ........................ 10
5. GMPLS/PCE Implications ....................................... 12 5. GMPLS/PCE Implications ....................................... 12
5.1. Implications for LSP Hierarchy with GMPLS TE ............ 12 5.1. Implications for LSP Hierarchy with GMPLS TE ............ 12
5.2. Implications for GMPLS Signaling ........................ 13 5.2. Implications for GMPLS Signaling ........................ 13
5.3. Implications for GMPLS Routing .......................... 16 5.3. Implications for GMPLS Routing .......................... 15
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 .............................................. 22 9. Acknowledgments .............................................. 21
10. References .................................................. 22 10. References .................................................. 22
10.1. Normative References ................................... 22 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 ............................. 26 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
skipping to change at page 6, line 34 skipping to change at page 6, line 30
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
Table 2 - ODU types and tolerance Table 2 - ODU types and tolerance
One of two options is for mapping client signals into ODUflex One of two options is for mapping client signals into ODUflex
depending on the client signal type: depending on the client signal type:
- Circuit clients are proportionally wrapped. Thus the bit rate and - Circuit clients are proportionally wrapped. Thus the bit rate and
tolerance are defined by the client signal. tolerance are defined by the client signal.
- Packet clients are mapped using the Generic Framing Procedure - Packet clients are mapped using the Generic Framing Procedure
(GFP). [G709-V3] recommends that the bit rate should be set to an (GFP). [G709-V3] recommends that the ODUflex(GFP) will fill an
integer multiplier of the High Order (HO) Optical Channel Physical integral number of tributary slots of the smallest HO ODUk path
Unit (OPU) OPUk TS rate, the tolerance should be +/-100ppm, and over which the ODUflex(GFP) may be carried, and the tolerance
the bit rate should be determined by the node that performs the should be +/-100ppm.
mapping.
[Editors' Note: As outcome of ITU SG15/q11 expert meeting held in
Vimercate in September 2010 it was decided that a resizable
ODUflex(GFP) occupies the same number of TS on every link of the path
(independently of the High Order (HO) OPUk TS rate). Please see WD07
and the meeting report of this meeting for more information.
The authors will update the above text related to Packet client
mapping as soon as new version of G.709 will be updated accordingly
with expert meeting decision reported here.]
3.1.2. Multiplexing ODUj onto Links 3.1.2. Multiplexing ODUj onto Links
The links between the switching nodes are provided by one or more The links between the switching nodes are provided by one or more
wavelengths. Each wavelength carries one OCh, which carries one OTU, wavelengths. Each wavelength carries one OCh, which carries one OTU,
which carries one ODU. Since all of these signals have a 1:1:1 which carries one ODU. Since all of these signals have a 1:1:1
relationship, we only refer to the OTU for clarity. The ODUjs are relationship, we only refer to the OTU for clarity. The ODUjs are
mapped into the TS of the OPUk. Note that in the case where j=k the mapped into the TS of the OPUk. Note that in the case where j=k the
ODUj is mapped into the OTU/OCh without multiplexing. ODUj is mapped into the OTU/OCh without multiplexing.
skipping to change at page 8, line 38 skipping to change at page 8, line 23
by a specific entity (e.g., head end, NMS) through Explicit Label by a specific entity (e.g., head end, NMS) through Explicit Label
Control [RFC3473]. Control [RFC3473].
3.1.2.1. Structure of MSI information 3.1.2.1. Structure of MSI information
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 received
in-band, after a 3 frames integration. 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 [RFC6163]. 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
skipping to change at page 11, line 6 skipping to change at page 10, line 37
+-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++ +-++---+--+ +--+---+--+ +--+---+--+ +--+---+-++
| |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 11, line 35 skipping to change at page 11, line 21
represented. In Figure 3, the operator choice is to hide the real RWA represented. In Figure 3, the operator choice is to hide the real RWA
network topology. network topology.
Node E Node E
Link #5 +--------+ Link #4 Link #5 +--------+ Link #4
+------------------------| |------------------------+ +------------------------| |------------------------+
| ------ | | ------ |
| // \\ | | // \\ |
| || || | | || || |
| | RWA domain | | | | RWA domain | |
+-+-----+ +----+- || || ------+ +-----+-+ +-+-----+ +------ || || ------+ +-----+-+
| | | \\ // | | | | | | \\ // | | |
| |Link #1 | -------- |Link #3 | | | |Link #1 | -------- |Link #3 | |
| +--------+ | | +--------+ + | +--------+ | | +--------+ +
| 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 3 - RWA Hidden Topology for LO ODU connection management Figure 3 - RWA Hidden Topology for LO ODU connection management
Link #5 +---------+ Link #4 Link #5 +---------+ Link #4
+------------------------| |-----------------------+ +------------------------| |-----------------------+
| +----| ODXC |----+ | | +----| ODXC |----+ |
| +-++ +---------+ ++-+ | | +-++ +---------+ ++-+ |
| Node f | | Node E | | Node g | | Node f | | Node E | | Node g |
| +-++ ++-+ | | +-++ ++-+ |
| | +--+ | | | | +--+ | |
+-+-----+ +----+----+--| |--+-----+---+ +-----+-+ +-+-----+ +----+----+--| |--+-----+---+ +-----+-+
| |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 - RWA Visible Topology for LO ODUj connection management Figure 4 - RWA 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 substitute 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
skipping to change at page 14, line 5 skipping to change at page 13, line 37
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 SHOULD 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 MUST 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 15, line 36
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 needs to 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
needs to evaluate the available bandwidth on each candidate link. needs to evaluate the available bandwidth on each candidate link.
The 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 SHOULD 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 SHOULD 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 SHOULD 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 46 skipping to change at page 19, line 30
consideration (Note that a third case, for the sake of completeness, consideration (Note that a third case, for the sake of completeness,
consists on G709-V1 nodes with a new OTN control plane, but such consists on G709-V1 nodes with a new OTN control plane, but such
nodes can be considered as new nodes with limited capabilities). nodes can be considered as new nodes with limited capabilities).
In order to provide backward compatibility, a new Switching In order to provide backward compatibility, a new Switching
Capability type is required for the control of [G709-V3] both in Capability type is required for the control of [G709-V3] both in
routing and signaling. routing and signaling.
From a routing perspective, the advertisement of LSAs carrying new From a routing perspective, the advertisement of LSAs carrying new
Switching Capability type implies the support of new OTN control Switching Capability type implies the support of new OTN control
plane protocols. A new node MUST support both legacy routing (i.e., plane protocols. A new node must support both legacy routing (i.e.,
the procedures defined in [RFC4203] with the switching capabilities the procedures defined in [RFC4203] with the switching capabilities
defined in [RFC4328]) and new routing (i.e., the procedures defined defined in [RFC4328]) and new routing (i.e., the procedures defined
for [G709-V3]), and SHOULD use new routing by default. When detecting for [G709-V3]), and should use new routing by default. When detecting
the presence of a legacy node in the administrative domain (i.e., the presence of a legacy node in the administrative domain (i.e.,
receiving LSAs carrying legacy Switching Capability type), the new receiving LSAs carrying legacy Switching Capability type), the new
node SHOULD advertise its links information by both the new and node should advertise its links information by both the new and
legacy routing approach, so that the legacy node can obtain the link legacy routing approach, so that the legacy node can obtain the link
resource information advertised by the new node. resource information advertised by the new node.
On the other hand, from a signaling perspective, a new node MUST On the other hand, from a signaling perspective, a new node must
support both the legacy signaling procedures defined in [RFC4328] and support both the legacy signaling procedures defined in [RFC4328] and
the new procedures for control of [G709-V3]. Based on the routing the new procedures for control of [G709-V3]. Based on the routing
information, a new node can determine whether its neighbor node is a information, a new node can determine whether its neighbor node is a
legacy one or new one, so that it can determine which signaling legacy one or new one, so that it can determine which signaling
procedure (new or legacy signaling procedure) needs to be performed. procedure (new or legacy signaling procedure) needs to be performed.
In case the new node has not enough information to know which 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 its neighbor can support, it can use the new
signaling procedure with the new Switching Capability type by default. signaling procedure with the new Switching Capability type by default.
Since a legacy node receiving such message will respond with an error Since a legacy node receiving such message will respond with an error
message indicating an unsupported Switching Capability type, the new message indicating an unsupported Switching Capability type, the new
node can perform the signaling again with a procedure [RFC4328] node can perform the signaling again with a procedure [RFC4328]
compliant. 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
skipping to change at page 20, line 45 skipping to change at page 20, line 31
variable bandwidth information need to be carried in the extended variable bandwidth information need to be carried in the extended
signaling message of path setup. For the same consideration, PCECP signaling message of path setup. For the same consideration, PCECP
also has a desire to be extended to carry the new signal type and also has a desire to be extended to carry the new signal type and
related variable bandwidth information when a PCC requests a path related variable bandwidth information when a PCC requests a path
computation. computation.
6. Data Plane Backward Compatibility Considerations 6. Data Plane Backward Compatibility Considerations
If TS auto-negotiation is supported, a node supporting 1.25Gbps TS If TS auto-negotiation is supported, a node supporting 1.25Gbps TS
can interwork with the other nodes that supporting 2.5Gbps TS by can interwork with the other nodes that supporting 2.5Gbps TS by
combining Specific TSs together in data plane. The control plane MUST combining Specific TSs together in data plane. The control plane must
support this TS combination. support this TS combination.
Path Path
+----------+ ------------> +----------+ +----------+ ------------> +----------+
| TS1==|===========\--------+--TS1 | | TS1==|===========\--------+--TS1 |
| TS2==|=========\--\-------+--TS2 | | TS2==|=========\--\-------+--TS2 |
| TS3==|=======\--\--\------+--TS3 | | TS3==|=======\--\--\------+--TS3 |
| TS4==|=====\--\--\--\-----+--TS4 | | TS4==|=====\--\--\--\-----+--TS4 |
| | \ \ \ \----+--TS5 | | | \ \ \ \----+--TS5 |
| | \ \ \------+--TS6 | | | \ \ \------+--TS6 |
skipping to change at page 22, line 7 skipping to change at page 21, line 37
documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], documents that define the protocols ([RFC3473], [RFC4203], [RFC4205],
[RFC4204], and [RFC5440]). [RFC5920] provides an overview of security [RFC4204], and [RFC5440]). [RFC5920] provides an overview of security
vulnerabilities and protection mechanisms for the GMPLS control plane. vulnerabilities and protection mechanisms for the GMPLS 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 and Lou Berger for their
comments. review and useful comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol [RFC4328] D. Papadimitriou, Ed. "Generalized Multi-Protocol
LabelSwitching (GMPLS) Signaling Extensions for G.709 LabelSwitching (GMPLS) Signaling Extensions for G.709
Optical Transport Networks Control", RFC 4328, Jan 2006. Optical Transport Networks Control", RFC 4328, Jan 2006.
[RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label [RFC3471] Berger, L., Editor, "Generalized Multi-Protocol Label
 End of changes. 48 change blocks. 
73 lines changed or deleted 59 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/