draft-ietf-ccamp-gmpls-g709-framework-03.txt   draft-ietf-ccamp-gmpls-g709-framework-04.txt 
Network Working Group Fatai Zhang Network Working Group Fatai Zhang
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: April 21, 2011 October 21, 2010 Expires: September 11, 2011 March 11, 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-03.txt draft-ietf-ccamp-gmpls-g709-framework-04.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 April 21, 2011. This Internet-Draft will expire on September 11, 2011.
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
1. Introduction..................................................2 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 ........................ 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..........................15 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.4.1. Correlating the Granularity of the TS..............18 5.5. Implications for Path Computation Elements .............. 19
5.4.2. Correlating the Supported LO ODU Signal Types......18 6. Data Plane Backward Compatibility Considerations ............. 19
5.5. Implications for Path Computation Elements..............19 7. Security Considerations ..................................... 20
6. Data Plane Backward Compatibility Considerations.............19 8. IANA Considerations .......................................... 20
7. Security Considerations......................................20 9. Acknowledgments .............................................. 20
8. IANA Considerations..........................................20 10. References .................................................. 21
9. Acknowledgments..............................................20 10.1. Normative References ................................... 21
10. References..................................................20 10.2. Informative References ................................ 22
10.1. Normative References...................................20 11. Authors' Addresses .......................................... 23
10.2. Informative References.................................21 12. Contributors ................................................ 24
11. Authors' Addresses..........................................22 APPENDIX A: ODU connection examples ............................. 25
12. Contributors................................................23
APPENDIX A: ODU connection examples.............................24
1. Introduction 1. Introduction
OTN has become a mainstream layer 1 technology for the transport OTN has become a mainstream layer 1 technology for the transport
network. Operators want to introduce control plane capabilities based network. Operators want to introduce control plane capabilities based
on Generalized Multi-Protocol Label Switching (GMPLS) to OTN networks, on Generalized Multi-Protocol Label Switching (GMPLS) to OTN networks,
to realize the benefits associated with a high-function control plane to realize the benefits associated with a high-function control plane
(e.g., improved network resiliency, resource usage efficiency, etc.). (e.g., improved network resiliency, resource usage efficiency, etc.).
GMPLS extends MPLS to encompass time division multiplexing (TDM) GMPLS extends MPLS to encompass time division multiplexing (TDM)
skipping to change at page 4, line 12 skipping to change at page 4, line 10
LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4, LO ODU: Lower Order ODU. The LO ODUj (j can be 0, 1, 2, 2e, 3, 4,
flex.) represents the container transporting a client of the OTN that flex.) represents the container transporting a client of the OTN that
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 up to 100 ppm. bit rate tolerance up to +/-100 ppm.
3. G.709 Optical Transport Network (OTN) 3. G.709 Optical Transport Network (OTN)
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-2001] and [G872Am2] describe the functional Specifically, [G872-2001] and [G872Am2] describe the functional
skipping to change at page 6, line 15 skipping to change at page 6, line 15
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| ODU Type | ODU bit-rate tolerance | | ODU Type | ODU bit-rate tolerance |
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
| ODU0 | +- 20 ppm | | ODU0 | +- 20 ppm |
| ODU1 | +- 20 ppm | | ODU1 | +- 20 ppm |
| ODU2 | +- 20 ppm | | ODU2 | +- 20 ppm |
| ODU3 | +- 20 ppm | | ODU3 | +- 20 ppm |
| ODU4 | +- 20 ppm | | ODU4 | +- 20 ppm |
| ODU2e | +- 100 ppm | | ODU2e | +- 100 ppm |
| | | | | |
| ODUflex for CBR | client signal bit rate tolerance, | | ODUflex for CBR | |
| Client signals | with a maximum of+-100 ppm | | Client signals | +- 100 ppm |
| | | | | |
| ODUflex for GFP-F | | | ODUflex for GFP-F | |
| Mapped client signal | +- 20 ppm | | Mapped client signal | +- 100 ppm |
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
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 bit rate should be set to an
integer multiplier of the High Order (HO) Optical Channel Physical integer multiplier of the High Order (HO) Optical Channel Physical
Unit (OPU) OPUk TS rate, the tolerance should be +/- 20ppm, and Unit (OPU) OPUk TS rate, the tolerance should be +/-100ppm, and
the bit rate should be determined by the node that performs the the bit rate should be determined by the node that performs the
mapping. mapping.
[Editors' Note: As outcome of ITU SG15/q11 expert meeting held in [Editors' Note: As outcome of ITU SG15/q11 expert meeting held in
Vimercate in September 2010 it was decided that a resizable Vimercate in September 2010 it was decided that a resizable
ODUflex(GFP) occupies the same number of TS on every link of the path 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 (independently of the High Order (HO) OPUk TS rate). Please see WD07
and the meeting report of this meeting for more information. and the meeting report of this meeting for more information.
The authors will update the above text related to Packet client The authors will update the above text related to Packet client
mapping as soon as new version of G.709 will be updated accordingly mapping as soon as new version of G.709 will be updated accordingly
with expert meeting decision reported here.] 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 OPU. 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 OTUk. 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.
The initial versions of G.709 [G709-V1] only provided a single TS The initial versions of G.709 [G709-V1] only provided a single TS
granularity, nominally 2.5Gb/s. [G709-V3], approved in 2009, added an granularity, nominally 2.5Gb/s. [G709-V3], approved in 2009, added an
additional TS granularity, nominally 1.25Gb/s. The number and type of additional TS granularity, nominally 1.25Gb/s. The number and type of
TSs provided by each of the currently identified OTUk is provided TSs provided by each of the currently identified OTUk is provided
below: below:
2.5Gb/s 1.25Gb/s Nominal Bit rate 2.5Gb/s 1.25Gb/s Nominal Bit rate
OTU1 1 2 2.5Gb/s OTU1 1 2 2.5Gb/s
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
information. The acceptedMSI information is the MSI valued received - The expectedMSI information that is used to check the acceptedMSI
in-band, after a 3 frames integration information. The acceptedMSI information is the MSI valued
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.
skipping to change at page 10, line 32 skipping to change at page 10, line 32
multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is multiplexed with other LO ODUjs into an OTUk (j < k), and the OTUk is
mapped into an OCh. See Appendix A for more information. mapped into an OCh. See Appendix A for more information.
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,
which is illustrated in Figure 2. In this layer there are ODU links which is illustrated in Figure 2. In this layer there are ODU links
with a variety of TSes available, and nodes that are ODXCs. Lo ODU with a variety of TSs available, and nodes that are ODXCs. Lo ODU
connections can be setup based on the network topology. connections can be setup based on the 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 12, line 29 skipping to change at page 12, line 29
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
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 to node E from the RWA domain. HO-ODU/OCh connection between node C and node E from the RWA domain.
The connection will appear at ODU level as a Forwarding Adjacency, The connection will appear at ODU level as a Forwarding Adjacency,
which will be used to create the ODU connection. which will be used to create the ODU connection.
5. GMPLS/PCE Implications 5. GMPLS/PCE Implications
The purpose of this section is to provide a set of requirements to be The purpose of this section is to provide a set of requirements to be
evaluated for extensions of the current GMPLS protocol suite and the evaluated for extensions of the current GMPLS protocol suite and the
PCE applications and protocols to encompass OTN enhancements and PCE applications and protocols to encompass OTN enhancements and
connection management. connection management.
5.1. Implications for LSP Hierarchy with GMPLS TE 5.1. Implications for LSP Hierarchy with GMPLS TE
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 [RFC4206bis] 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], [RFC4206bis] 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 [WSON-Frame]. Therefore, this document only
considers ODU layer for ODU connection request. considers ODU layer for ODU connection request.
For the ODU layers, in order to maintain compatibility with LSP hierarchy could be applied within the ODU layers. One of the
introducing new [G709-V3] services (e.g., ODU0, ODUflex) into a typical scenarios for ODU layer hierarchy is to maintain
legacy network configuration (containing [G709-V1] or [G709-V2] OTN compatibility with introducing new [G709-V3] services (e.g., ODU0,
equipment), it may be needed to consider introducing multi-stage ODUflex) into a legacy network configuration (containing [G709-V1] or
multiplexing capability in specific network transition scenarios. One [G709-V2] OTN equipment). In this scenario, it may be needed to
method for enabling multi-stage multiplexing is by introducing consider introducing hierarchical multiplexing capability in specific
dedicated boards in a few specific places in the network and network transition scenarios. One method for enabling multiplexing
tunneling these new services through [G709-V1] or [G709-V2] hierarchy is by introducing dedicated boards in a few specific places
containers (ODU1, ODU2, ODU3), thus postponing the need to upgrade in the network and tunneling these new services through [G709-V1] or
every network element to [G709-V3] capabilities. In such case, one [G709-V2] containers (ODU1, ODU2, ODU3), thus postponing the need to
ODUj connection can be nested into another ODUk connection, which upgrade every network element to [G709-V3] capabilities.
forms the LSP hierarchy in ODU layer. Here, [RFC4206], [RFC4206bis]
and [MLN-EXT] (including related modifications, if needed) are In such case, one ODUj connection can be nested into another ODUk
relevant to connection set up. (j<k) connection, which forms the LSP hierarchy in ODU layer. The
creation of the outer ODUk connection can be triggered via network
planning, or by the signaling of the inner ODUj connection. For the
former case, the outer ODUk connection can be created in advance
based on network planning. For the latter case, the multi-layer
network signaling described in [RFC4206], [RFC6107] and [RFC6001]
(including related modifications, if needed) are relevant to create
the ODU connections with multiplexing hierarchy. In both cases, the
outer ODUk connection is advertised as a Forwarding Adjacency (FA).
5.2. Implications for GMPLS Signaling 5.2. Implications for GMPLS Signaling
The signaling function and Resource reSerVation Protocol-Traffic The signaling function and Resource reSerVation Protocol-Traffic
Engineering (RSVP-TE) extensions are described in [RFC3471] and [RFC Engineering (RSVP-TE) extensions are described in [RFC3471] and [RFC
3473]. For OTN-specific control, [RFC4328] defines signaling 3473]. For OTN-specific control, [RFC4328] defines signaling
extensions to support G.709 Optical Transport Networks Control as extensions to support G.709 Optical Transport Networks Control as
defined in [G709-V1]. defined in [G709-V1].
As described in Section 3, [G709-V3] introduced some new features As described in Section 3, [G709-V3] introduced some new features
skipping to change at page 14, line 43 skipping to change at page 15, line 7
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
Adjustment Scheme (LCAS)
GMPLS signaling should support the creation of Virtual
Concatenation of ODUk signal with k=1, 2, 3. The signaling should
also support the control of dynamic capacity changing of a VCAT
container using LCAS ([G.7042]). [VCAT] has a clear description 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
multiplexing capabilities in the network to improve infrastructure multiplexing capabilities in the network to improve infrastructure
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.
skipping to change at page 16, line 19 skipping to change at page 16, line 39
be considered: 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 for carrying the TS granularity that the interface can
support
One type of ODUj can be multiplexed to an OTUk using different TS
granularity. For example, ODU1 can be multiplexed into ODU2 with
either 2.5Gbps TS granularity or 1.25G TS granularity. The
routing protocol should be capable of carrying the TS granularity
supported by the ODU interface.
- Support any ODU and ODUflex - Support any ODU and ODUflex
The bit rate (i.e., bandwidth) of TS is dependent on the TS The bit rate (i.e., bandwidth) of TS is dependent on the TS
granularity and the signal type of the link. For example, the granularity and the signal type of the link. For example, the
bandwidth of a 1.25G TS in an OTU2 is about 1.249409620 Gbps, bandwidth of a 1.25G TS in an OTU2 is about 1.249409620 Gbps,
while the bandwidth of a 1.25G TS in an OTU3 is about 1.254703729 while the bandwidth of a 1.25G TS in an OTU3 is about 1.254703729
Gbps. Gbps.
One LO ODU may need different number of TSs when multiplexed into One LO ODU may need different number of TSs when multiplexed into
different HO ODUs. For example, for ODU2e, 9 TSs are needed when different HO ODUs. For example, for ODU2e, 9 TSs are needed when
multiplexed into an ODU3, while only 8 TSs are needed when multiplexed into an ODU3, while only 8 TSs are needed when
multiplexed into an ODU4. For ODUflex, the total number of TSs to multiplexed into an ODU4. For ODUflex, the total number of TSs to
be reserved in a HO ODU equals the maximum of [bandwidth of be reserved in a HO ODU equals the maximum of [bandwidth of
ODUflex / bandwidth of TS of the HO ODU]. ODUflex / bandwidth of TS of the HO ODU].
Therefore, the routing protocol must be capable of carrying the Therefore, the routing protocol must 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 link multiplexing capacity and - Support for differentiating between terminating and switching
link rate capacity capability
When a network operator receives a request for a particular ODU
connection service, the operator governs the manner in which the Due to internal constraints and/or limitations, the type of
request is fulfilled in their network. Considerations include signal being advertised by an interface could be just switched
deployed network infrastructure capabilities, associated policies (i.e. forwarded to switching matrix without
(e.g., at what link fill threshold should a particular higher- multiplexing/demultiplexing actions), just terminated (demuxed)
rate ODUk be utilized), etc. Thus, for example, an ODU2 or both of them. The capability advertised by an interface needs
connection service request could be supported by: OTU2 links further distinction in order to separate termination and
(here the connection service rate is the same as the link rate), switching capabilities.
a combination of OTU2 and OTU3 links, OTU3 links, etc.
Therefore, to allow the required flexibility, the routing Therefore, to allow the required flexibility, the routing
protocol should clearly distinguish the capacity that is protocol should clearly distinguish the terminating and switching
multiplexed in an ODUk that in turn is adapted in an OTUk from capability.
the ODUk capacity that is switched in matrix and directly adapted
in an OTUk without further multiplexing.
- 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
skipping to change at page 17, line 42 skipping to change at page 18, line 5
multiple OTU links, at the same or different line rates, between multiple OTU links, at the same or different line rates, between
a pair of nodes as a TE link. Note that link bundling is optional a 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) (HAO) are for
further study. further study.
As mentioned in Section 5.1, one method of enabling multi-stage As mentioned in Section 5.1, one method of enabling multiplexing
multiplexing is via usage of dedicated boards to allow tunneling of hierarchy is via usage of dedicated boards to allow tunneling of new
new services through legacy ODU1, ODU2, ODU3 containers. Such services through legacy ODU1, ODU2, ODU3 containers. Such dedicated
dedicated boards may have some constraints with respect to switching boards may have some constraints with respect to switching matrix
matrix access; detection and representation of such constraints is access; detection and representation of such constraints is for
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.
skipping to change at page 18, line 26 skipping to change at page 18, line 33
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.
5.4.1. 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 node different TS granularity. In order to allow interconnection the
with 1.25Gb/s granularity must fall back to 2.5Gb/s granularity. node with 1.25Gb/s granularity must fall back to 2.5Gb/s
granularity.
Therefore, it is necessary for the two ends of a link to correlate Therefore, it is necessary for the two ends of a link to
the granularity of the TS. This ensures that both ends of the link correlate the granularity of the TS. This ensures to allocate the
advertise consistent capabilities (for routing) and ensures that TS over the TE link correctly.
viable connections are established.
5.4.2. Correlating the Supported LO ODU Signal Types - Correlating the supported LO ODU signal types and multiplexing
hierarchy capability
Many new ODU signal types have been introduced [G709-V3], such as Many new ODU signal types have been introduced in [G709-V3], such
ODU0, ODU4, ODU2e and ODUflex. It is possible that equipment does not as ODU0, ODU4, ODU2e and ODUflex. It is possible that equipment
support all the LO ODU signal types introduced by those new standards does not support all the LO ODU signal types introduced by those
or drafts. If one end of a link can not support a certain LO ODU new standards or drafts. Furthermore, since multiplexing
signal type, the link cannot be selected to carry such type of LO ODU hierarchy is not allowed before [G709-V3], it is possible that
connection. only one end of an ODU link can support multiplexing hierarchy
capability, or the two ends of the link support different
multiplexing hierarchy capabilities (e.g., one end of the link
supports ODU0 into ODU1 into ODU3 multiplexing while the other
end supports ODU0 into ODU2 into ODU3 multiplexing).
Therefore, it is necessary for the two ends of an HO ODU link to For the control and management consideration, it is necessary for
correlate which types of LO ODU can be supported by the link. After the two ends of an HO ODU link to correlate which types of LO ODU
correlating, the capability information can be flooded by IGP, so can be supported and what multiplexing hierarchy capabilities can
that the correct path for an ODU connection can be calculated. be provided by the other end.
5.5. Implications for Path Computation Elements 5.5. Implications for Path Computation Elements
[PCE-APS] describes the requirements for GMPLS applications of PCE in [PCE-APS] describes the requirements for GMPLS applications of PCE in
order to establish GMPLS LSP. PCE needs to consider the GMPLS TE order to establish GMPLS LSP. PCE needs to consider the GMPLS TE
attributes appropriately once a PCC or another PCE requests a path attributes appropriately once a PCC or another PCE requests a path
computation. The TE attributes which can be contained in the path computation. The TE attributes which can be contained in the path
calculation request message from the PCC or the PCE defined in calculation request message from the PCC or the PCE defined in
[RFC5440] includes switching capability, encoding type, signal type, [RFC5440] includes switching capability, encoding type, signal type,
etc. etc.
skipping to change at page 21, line 25 skipping to change at page 21, line 45
Generalized Multi-Protocol Label Switching (GMPLS)", RFC Generalized Multi-Protocol Label Switching (GMPLS)", RFC
4205, October 2005. 4205, October 2005.
[RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204, [RFC4204] Lang, J., Ed., "Link Management Protocol (LMP)", RFC 4204,
October 2005. October 2005.
[RFC4206] K. Kompella, Y. Rekhter, Ed., " Label Switched Paths (LSP) [RFC4206] K. Kompella, Y. Rekhter, Ed., " Label Switched Paths (LSP)
Hierarchy with Generalized Multi-Protocol Label Switching Hierarchy with Generalized Multi-Protocol Label Switching
(GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005. (GMPLS) Traffic Engineering (TE)", RFC 4206, October 2005.
[RFC4206bis] K. Shiomoto, A. Farrel, "Procedures for Dynamically [RFC6107] K. Shiomoto, A. Farrel, "Procedures for Dynamically
Signaled Hierarchical Label Switched Paths", draft-ietf- Signaled Hierarchical Label Switched Paths", RFC6107,
ccamp-lsp-hierarchy-bis-08.txt, February 2010. February 2011.
[MLN-EXT] 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)", draft-ietf- Layer and Multi-Region Networks (MLN/MRN)", RFC6001,
ccamp-gmpls-mln-extensions-12.txt, 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
(VCAT) and the Link Capacity Adjustment Scheme (LCAS)
with Generalized Multi-Protocol Label Switching (GMPLS)",
draft-ietf-ccamp-gmpls-vcat-lcas-11.txt, March 9, 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.
[G709-V2] ITU-T, "Interface for the Optical Transport Network [G709-V2] ITU-T, "Interface for the Optical Transport Network
(OTN)," G.709 Recommendation, March 2003. (OTN)," G.709 Recommendation, March 2003.
[G7042] ITU-T G.7042/Y.1305, "Link capacity adjustment scheme
(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.HAO] 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.hao "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 [WSON-FRAME] 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
skipping to change at page 22, line 47 skipping to change at page 23, line 35
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.
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-28973237 Phone: +86-755-28973237
Email: danli@huawei.com Email: huawei.danli@huawei.com
Han Li Han Li
China Mobile Communications Corporation China Mobile Communications Corporation
53 A Xibianmennei Ave. Xuanwu District 53 A Xibianmennei Ave. Xuanwu District
Beijing 100053 P.R. China Beijing 100053 P.R. China
Phone: +86-10-66006688 Phone: +86-10-66006688
Email: lihan@chinamobile.com Email: lihan@chinamobile.com
Sergio Belotti Sergio Belotti
Alcatel-Lucent Alcatel-Lucent
Optics CTO Optics CTO
Via Trento 30 20059 Vimercate (Milano) Italy Via Trento 30 20059 Vimercate (Milano) Italy
+39 039 6863033 +39 039 6863033
Email: sergio.belotti@alcatel-lucent.it Email: sergio.belotti@alcatel-lucent.it
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
 End of changes. 38 change blocks. 
123 lines changed or deleted 139 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/