draft-ietf-ccamp-gmpls-g709-framework-02.txt   draft-ietf-ccamp-gmpls-g709-framework-03.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
Expires: January 12, 2011 July 12, 2010 D. Ceccarelli
Ericsson
Expires: April 21, 2011 October 21, 2010
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-02.txt draft-ietf-ccamp-gmpls-g709-framework-03.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 37 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 January 12, 2011. This Internet-Draft will expire on April 21, 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.1.1. ODUj types and parameters......................6
3.1.2. Multiplexing ODUj onto Links........................7 3.1.2. Multiplexing ODUj onto Links........................7
3.1.2.1. Link Parameters................................8 3.1.2.1. Structure of MSI information...................8
3.1.2.2. Tributary Port Number Assignment...............9 4. Connection management in OTN..................................9
4. Connection management in OTN.................................10
4.1. Connection management of the ODU........................10 4.1. Connection management of the ODU........................10
5. GMPLS/PCE Implications.......................................13 5. GMPLS/PCE Implications.......................................12
5.1. Implications for LSP Hierarchy with GMPLS TE............13 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.2.1. Identifying OTN signals............................14
5.2.2. Tributary Port Number..............................15
5.2.3. Support for constraint signaling...................15
5.3. Implications for GMPLS Routing..........................15 5.3. Implications for GMPLS Routing..........................15
5.4. Implications for Link Management Protocol (LMP).........17 5.4. Implications for Link Management Protocol (LMP).........18
5.4.1. Correlating the Granularity of the TS..............18 5.4.1. Correlating the Granularity of the TS..............18
5.4.2. Correlating the Supported LO ODU Signal Types......18 5.4.2. Correlating the Supported LO ODU Signal Types......18
5.5. Implications for Path Computation Elements..............18 5.5. Implications for Path Computation Elements..............19
6. Security Considerations......................................19 6. Data Plane Backward Compatibility Considerations.............19
7. IANA Considerations..........................................19 7. Security Considerations......................................20
8. Acknowledgments..............................................19 8. IANA Considerations..........................................20
9. References...................................................19 9. Acknowledgments..............................................20
9.1. Normative References....................................19 10. References..................................................20
9.2. Informative References..................................21 10.1. Normative References...................................20
10. Authors' Addresses..........................................21 10.2. Informative References.................................21
11. Contributors................................................22 11. Authors' Addresses..........................................22
APPENDIX A: ODU connection examples.............................23 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 6, line 5 skipping to change at page 6, line 5
| ODUflex for GFP-F | | | ODUflex for GFP-F | |
| Mapped client signal | Configured bit rate | | Mapped client signal | Configured bit rate |
+-----------------------+-----------------------------------+ +-----------------------+-----------------------------------+
Table 1 - ODU types and bit rates Table 1 - ODU types and bit rates
NOTE - The nominal ODUk rates are approximately: 2 498 775.126 kbit/s NOTE - The nominal ODUk rates are approximately: 2 498 775.126 kbit/s
(ODU1), 10 037 273.924 kbit/s (ODU2), 40 319 218.983 kbit/s (ODU3), (ODU1), 10 037 273.924 kbit/s (ODU2), 40 319 218.983 kbit/s (ODU3),
104 794 445.815 kbit/s (ODU4) and 10 399 525.316 kbit/s (ODU2e). 104 794 445.815 kbit/s (ODU4) and 10 399 525.316 kbit/s (ODU2e).
+-------------------+--------------------------------------+ +-----------------------+-----------------------------------+
| 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 | | | ODUflex for CBR | client signal bit rate tolerance, |
| Client signals | client signal bit rate tolerance, | | Client signals | with a maximum of+-100 ppm |
| | with a maximum of+-100 ppm | | | |
| | | | ODUflex for GFP-F | |
| ODUflex for GFP-F | | | Mapped client signal | +- 20 ppm |
| Mapped client | +- 20 ppm | +-----------------------+-----------------------------------+
| signal | |
+-------------------+--------------------------------------+
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 +/- 20ppm, 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.
3.1.1.1. ODUj types and parameters [Editors' Note: As outcome of ITU SG15/q11 expert meeting held in
Vimercate in September 2010 it was decided that a resizable
When ODUj connections are setup, two types of information should be ODUflex(GFP) occupies the same number of TS on every link of the path
conveyed in a connection request: (independently of the High Order (HO) OPUk TS rate). Please see WD07
and the meeting report of this meeting for more information.
(a) End to end:
Client payload type (e.g. STM64; Ethernet etc.)
Bit rate and tolerance: Note for j = 0, 1, 2, 2e, 3, 4 this
information may be carried as an enumerated type. For the ODUflex
the actual bit rate and tolerance must be provided.
(b) Hop by hop: The authors will update the above text related to Packet client
TS assignment and port number carried by the Multiplex Structure mapping as soon as new version of G.709 will be updated accordingly
Identifier (MSI) bytes as described in section 3.1.2. 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 OPU. 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 OTUk. 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
OTU2 4 8 10Gb/s OTU2 4 8 10Gb/s
OTU3 16 32 40Gb/s OTU3 16 32 40Gb/s
OTU4 -- 80 100Gb/s OTU4 -- 80 100Gb/s
To maintain backwards compatibility while providing the ability to To maintain backwards compatibility while providing the ability to
interconnect nodes that support 1.25Gb/s TS at one end of a link and interconnect nodes that support 1.25Gb/s TS at one end of a link and
2.5Gb/s TS at the other, the 'new' equipment will fall back to the 2.5Gb/s TS at the other, the 'new' equipment will fall back to the
use of a 2.5Gb/s TS if connected to legacy equipment. This use of a 2.5Gb/s TS if connected to legacy equipment. This
information is carried in band by the payload type. information is carried in band by the payload type.
The actual bit rate of the TS in an OTUk depends on the value of k. The actual bit rate of the TS in an OTUk depends on the value of k.
Thus the number of TS occupied by an ODUj may vary depending on the Thus the number of TS occupied by an ODUj may vary depending on the
values of j and k. For example an ODU2e uses 9 TS in an OTU3 but values of j and k. For example an ODU2e uses 9 TS in an OTU3 but
skipping to change at page 8, line 35 skipping to change at page 8, line 28
- ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity - ODU2e into ODU3 or ODU4 multiplexing with 1.25Gbps TS granularity
o ODU2e occupies 9 of the 32 TS for ODU3 or 8 of the 80 TS for o ODU2e occupies 9 of the 32 TS for ODU3 or 8 of the 80 TS for
ODU4 ODU4
In general the mapping of an ODUj (including ODUflex) into the OTUk In general the mapping of an ODUj (including ODUflex) into the OTUk
TSs is determined locally, and it can also be explicitly controlled TSs is determined locally, and it can also be explicitly controlled
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. Link Parameters 3.1.2.1. Structure of MSI information
Per [RFC4201], each OTU can be treated as a component link of a link
bundle. The available capacity between nodes is the sum of the
available capacity on the OTUs that interconnect the nodes. This
total capacity is represented as the capacity of a link bundle.
Note that there will typically be more than one OTU between a pair of
nodes so that the available capacity will typically be distributed
across multiple OTUs. Thus, in order to be able to determine the
maximum payload that can be carried on a bundled link, the link state
advertisement must also provide the largest number of TSes available
on any one component OTU.
In order to compute the lowest cost path for a ODUj connection
request the critical parameters that need to be provided (for the
purposes of routing) are:
- Number of TS
- Maximum number of TS available for a LSP (i.e., Maximum LSP
Bandwidth)
- Bit rate of the TS. (Note: This may be efficiently encoded as a
two integers representing the value of k and the granularity.)
3.1.2.2. Tributary Port Number Assignment
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 organized as a set of entries, with one entry for each HO ODUj is local to each link. In case of bidirectional paths the association
TS. The information carried by each entry is: between TPN and TS MUST be the same in both directions.
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:
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.
The MSI information inserted in OPU3 overhead by the source of the HO On each node and on every link, two MSI values have to be provisioned:
ODUk trail is checked by the sink of the HO ODUk trail. G.709 default
behavior requires that the multiplexing structure of the HO ODUk be
provided by means of pre-provisioned MSI information, termed
expectedMSI. The sink of the HO ODU trail checks the complete content
of the MSI information (including the TPN) that was received in-band,
termed acceptedMSI, against the expectedMSI. If the acceptedMSI is
different from the expectedMSI, then the traffic is dropped and a
payload mismatch alarm is generated.
Note that the values of the TPN MUST be either agreed between the The TxMSI information inserted in OPU (e.g., OPU3) overhead by the
source and the sink of the HO ODU trail either via control plane source of the HO ODUk trail.
signaling or provisioning by the management plane. The expectedMSI information that is used to check the acceptedMSI
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
acceptedMSI information (against the expectedMSI.
If the acceptedMSI is different from the expectedMSI, then the
traffic is dropped and a payload mismatch alarm is generated.
Provisioning of TPN can be performed either by network management
system or control plane. In the last case, control plane is also
responsible for negotiating the provisioned values on a link by link
base.
4. Connection management in OTN 4. Connection management in OTN
OTN-based connection management is concerned with controlling the OTN-based connection management is concerned with controlling the
connectivity of ODU paths and optical channels (OCh). This document connectivity of ODU paths and optical channels (OCh). This document
focuses on the connection management of ODU paths. The management of focuses on the connection management of ODU paths. The management of
OCh paths is described in [WSON-FRAME]. OCh paths is described in [WSON-FRAME].
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
skipping to change at page 13, line 12 skipping to change at page 12, line 35
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 to 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 framework for extensions The purpose of this section is to provide a set of requirements to be
of the current GMPLS protocol suite and the PCE applications and evaluated for extensions of the current GMPLS protocol suite and the
protocols to encompass OTN enhancements and connection management. PCE applications and protocols to encompass OTN enhancements and
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 [RFC4206bis] 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
skipping to change at page 13, line 40 skipping to change at page 13, line 21
For the ODU layers, in order to maintain compatibility with For the ODU layers, in order to maintain compatibility with
introducing new [G709-V3] services (e.g., ODU0, ODUflex) into a introducing new [G709-V3] services (e.g., ODU0, ODUflex) into a
legacy network configuration (containing [G709-V1] or [G709-V2] OTN legacy network configuration (containing [G709-V1] or [G709-V2] OTN
equipment), it may be needed to consider introducing multi-stage equipment), it may be needed to consider introducing multi-stage
multiplexing capability in specific network transition scenarios. One multiplexing capability in specific network transition scenarios. One
method for enabling multi-stage multiplexing is by introducing method for enabling multi-stage multiplexing is by introducing
dedicated boards in a few specific places in the network and dedicated boards in a few specific places in the network and
tunneling these new services through [G709-V1] or [G709-V2] tunneling these new services through [G709-V1] or [G709-V2]
containers (ODU1, ODU2, ODU3), thus postponing the need to upgrade containers (ODU1, ODU2, ODU3), thus postponing the need to upgrade
every network element to [G709-V3] capabilities. In such case, one every network element to [G709-V3] capabilities. In such case, one
ODUj connection can be nested into another ODUk connection, which ODUj connection can be nested into another ODUk connection, which
forms the LSP hierarchy in ODU layer. Here, [RFC4206], [RFC4206bis] forms the LSP hierarchy in ODU layer. Here, [RFC4206], [RFC4206bis]
and [MLN-EXT] (including related modifications, if needed) are and [MLN-EXT] (including related modifications, if needed) are
relevant to connection set up. relevant to connection set up.
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 2, [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.
5.2.1. Identifying OTN signals
[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 new signal Parameters are also defined in [RFC4328]. The following signaling
types have been added since [RFC4328] was published: aspects should be considered additionally since [RFC4328] was
published:
(1) New signal types of sub-lambda layer - Support for specifying the new signal types and the related
traffic information
THE traffic parameters should be extended in signaling message to
support the new optical Channel Data Unit (ODUj) including:
Optical Channel Data Unit (ODUj):
- ODU0 - ODU0
- ODU2e - ODU2e
- ODU4 - ODU4
- ODUflex - ODUflex
(2) A new TS granularity (i.e., 1.25 Gbps) For ODUflex, since it has a variable bandwidth/bit rate BR and a
bit rate tolerance T, the (node local) mapping process must be
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
stuffing bytes. Therefore, bit rate and bit rate tolerance should
also be carried in the Traffic Parameter in the signaling of
connection setup request.
(3) Signal type with variable bandwidth: For other ODU signal types, the bit rates and tolerances of them
are fixed and can be deduced from the signal types.
ODUflex has a variable bandwidth/bit rate BR and a bit rate - Support for LSP setup using different Tributary Slot granularity
tolerance T. As described above the (node local) mapping process
must be 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 stuffing bytes. Therefore, bit rate and bit rate
tolerance should be carried in the Traffic Parameter in the
signaling of connection setup request.
(4) Extended multiplexing hierarchy (For example, ODU0 into OTU2 New label should be defined to identify the type of TS (i.e., the
multiplexing (with 1,25Gbps TS granularity).) 2.5 Gbps TS granularity and the new 1.25 Gbps TS granularity).
So the encoding provided in [RFC4328] needs to be extended to support - Support for LSP setup of new ODUk/ODUflex containers with related
all the signal types and related mapping and multiplexing with all mapping and multiplexing capabilities
kinds of TSs. Moreover, the extensions should consider the
extensibility to match future evolvement of OTN.
For item (1) and (3), new traffic parameters may need to be extended New label should be defined to carry the exact TS allocation
in signaling message; information related to the extended mapping and multiplexing
For item (2) and (4), new label should be defined to carry the exact hierarchy (For example, ODU0 into ODU2 multiplexing (with 1,25Gbps
TS allocation information related to the extended multiplexing TS granularity)), in order to setting up the ODU connection.
hierarchy.
5.2.2. Tributary Port Number - Support for Tributary Port Number allocation and negotiation
The tributary port number may be assigned locally by the node at the Tributary Port Number needs to be configured as part of the MSI
(traffic) ingress end of the link and in this case as described above information (See more information in Section 3.1.2.1). A new
must be conveyed to the far end of the link as a "transparent" extension object has to be defined to carry TPN information if
parameter i.e. the control plane does not need to understand this control plane is used to configure MSI information.
information. The TPN may also be assigned by the control plane when
establishing LSP.
5.2.3. 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. On capacity is consumed in transporting the ODUk connection service.
the other hand, the operator might leverage sub-lambda multiplexing
capabilities in the network to improve infrastructure efficiencies
within any given networking domain. In this case, ODUk multiplexing
may be performed prior to transport over various rate ODU servers
over associated OTU sections.
The identification of constraints and associated encoding in the On the other hand, the operator might leverage sub-lambda
signaling for differentiating full lambda LSP or sub lambda LSP is multiplexing capabilities in the network to improve infrastructure
for further study. efficiencies within any given networking domain. In this case,
ODUk multiplexing may be performed prior to transport over various
rate ODU servers over associated OTU sections.
The identification of constraints and associated encoding in the
signaling for differentiating full lambda LSP or sub lambda LSP is
for further study.
- Support for Control of Hitless Adjustment of ODUflex (GFP)
[G.HAO] has been created in ITU-T to specify hitless adjustment of
ODUflex (GFP) (HAO) that is used to increase or decrease the
bandwidth of an ODUflex (GFP) that is transported in an OTN
network.
The procedure of ODUflex (GFP) adjustment requires the
participation of every node along the path. Therefore, it is
recommended to use the control plane signaling to initiate the
adjustment procedure in order to avoid the manual configuration at
each node along the path.
Since the [G.HAO] is being developed currently, the control of HAO
is for further study.
All the extensions above should consider the extensibility to match
future evolvement of OTN.
5.3. Implications for GMPLS Routing 5.3. Implications for GMPLS Routing
The path computation process should select a suitable route for a The path computation process should select a suitable route for a
ODUj connection request. In order to compute the lowest cost path it ODUj connection request. In order to compute the lowest cost path it
must evaluate the number (and availability) of TSs on each candidate must evaluate the available bandwidth on each candidate link. The
link. The routing protocol should be extended to convey some routing protocol should be extended to convey some information to
information to represent ODU TE topology. As described above the represent ODU TE topology.
number of TSs (on a link bundle), the bandwidth of the TS and the
maximum number that are available to convey a single ODUj must be
provided.
GMPLS Routing [RFC4202] defines Interface Switching Capability GMPLS Routing [RFC4202] defines Interface Switching Capability
Descriptor of TDM which can be used for ODU. However, some other Descriptor of TDM which can be used for ODU. However, some other
issues should also be considered which are discussed below. issues should also be considered which are discussed below.
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
skipping to change at page 17, line 19 skipping to change at page 17, line 15
connection service, the operator governs the manner in which the connection service, the operator governs the manner in which the
request is fulfilled in their network. Considerations include request is fulfilled in their network. Considerations include
deployed network infrastructure capabilities, associated policies deployed network infrastructure capabilities, associated policies
(e.g., at what link fill threshold should a particular higher- (e.g., at what link fill threshold should a particular higher-
rate ODUk be utilized), etc. Thus, for example, an ODU2 rate ODUk be utilized), etc. Thus, for example, an ODU2
connection service request could be supported by: OTU2 links connection service request could be supported by: OTU2 links
(here the connection service rate is the same as the link rate), (here the connection service rate is the same as the link rate),
a combination of OTU2 and OTU3 links, OTU3 links, etc. 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 be capable of differentiating between these two protocol should clearly distinguish the capacity that is
types of link capacity. multiplexed in an ODUk that in turn is adapted in an OTUk from
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
Link bundling can improve routing scalability by reducing the Link bundling can improve routing scalability by reducing the
amount of TE links that has to be handled by routing protocol. amount of TE links that has to be handled by routing protocol.
The routing protocol must be capable of supporting bundling The routing protocol must be capable of supporting bundling
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)
As described in Section 5.2, the routing requirements for
supporting hitless adjustment of ODUflex (GFP) (HAO) are for
further study.
As mentioned in Section 5.1, one method of enabling multi-stage As mentioned in Section 5.1, one method of enabling multi-stage
multiplexing is via usage of dedicated boards to allow tunneling of multiplexing is via usage of dedicated boards to allow tunneling of
new services through legacy ODU1, ODU2, ODU3 containers. Such new services through legacy ODU1, ODU2, ODU3 containers. Such
dedicated boards may have some constraints with respect to switching dedicated boards may have some constraints with respect to switching
matrix access; detection and representation of such constraints is matrix access; detection and representation of such constraints is
for further study. for 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
skipping to change at page 19, line 15 skipping to change at page 19, line 22
[RFC5440] includes switching capability, encoding type, signal type, [RFC5440] includes switching capability, encoding type, signal type,
etc. etc.
As described in section 5.2.1, new signal types and new signals with As described in section 5.2.1, new signal types and new signals with
variable bandwidth information need to be carried in the extended variable bandwidth information need to be carried in the extended
signaling message of path setup. For the same consideration, 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. Security Considerations 6. Data Plane Backward Compatibility Considerations
The node supporting 1.25Gbps TS can interwork with the other nodes
that supporting 2.5Gbps TS by combining Specific TSs together in data
plane. The control plane MUST support this TS combination.
Take Figure 5 as an example. Assume that there is an ODU2 link
between node A and B, where node A only supports the 2.5Gbps TS while
node B supports the 1.25Gbps TS. In this case, the TS#i and TS#i+4
(where i<=4) of node B are combined together. When creating an ODU1
service in this ODU2 link, node B reserves the TS#i and TS#i+4 with
the granularity of 1.25Gbps. But in the label sent from B to A, it is
indicated that the TS#i with the granularity of 2.5Gbps is reserved.
Path
+----------+ ------------> +----------+
| TS1==|===========\--------+--TS1 |
| TS2==|=========\--\-------+--TS2 |
| TS3==|=======\--\--\------+--TS3 |
| TS4==|=====\--\--\--\-----+--TS4 |
| | \ \ \ \----+--TS5 |
| | \ \ \------+--TS6 |
| | \ \--------+--TS7 |
| | \----------+--TS8 |
+----------+ <------------ +----------+
node A Resv node B
Figure 5 - Interworking between 1.25Gbps TS and 2.5Gbps TS
In the contrary direction, when receiving a label from node A
indicating that the TS#i with the granularity of 2.5Gbps is reserved,
node B will reserved the TS#i and TS#i+4 with the granularity of
1.25Gbps in its control plane.
7. Security Considerations
The use of control plane protocols for signaling, routing, and path The use of control plane protocols for signaling, routing, and path
computation opens an OTN to security threats through attacks on those computation opens an OTN to security threats through attacks on those
protocols. The data plane technology for an OTN does not introduce protocols. The data plane technology for an OTN does not introduce
any specific vulnerabilities, and so the control plane may be secured any specific vulnerabilities, and so the control plane may be secured
using the mechanisms defined for the protocols discussed. using the mechanisms defined for the protocols discussed.
For further details of the specific security measures refer to the For further details of the specific security measures refer to the
documents that define the protocols ([RFC3473], [RFC4203], [RFC4205], documents that define the protocols ([RFC3473], [RFC4203], [RFC4205],
[RFC4204], and [RFC5440]). [GMPLS-SEC] provides an overview of [RFC4204], and [RFC5440]). [GMPLS-SEC] provides an overview of
security vulnerabilities and protection mechanisms for the GMPLS security vulnerabilities and protection mechanisms for the GMPLS
control plane. control plane.
7. IANA Considerations 8. IANA Considerations
This document makes not requests for IANA action. This document makes not requests for IANA action.
8. Acknowledgments 9. Acknowledgments
We would like to thank Maarten Vissers for his review and useful We would like to thank Maarten Vissers for his review and useful
comments. comments.
9. References 10. References
9.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
Switching (GMPLS) Signaling Functional Description", RFC Switching (GMPLS) Signaling Functional Description", RFC
3471, January 2003. 3471, January 2003.
[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label [RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label
skipping to change at page 21, line 5 skipping to change at page 21, line 41
Layer and Multi-Region Networks (MLN/MRN)", draft-ietf- Layer and Multi-Region Networks (MLN/MRN)", draft-ietf-
ccamp-gmpls-mln-extensions-12.txt, February 21, 2010. ccamp-gmpls-mln-extensions-12.txt, 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.
[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.
9.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.
[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
Meeting in Geneva, Initial draft G.hao "Hitless
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
(WSON)", draft-ietf-ccamp-rwa-wson-framework, work in (WSON)", draft-ietf-ccamp-rwa-wson-framework, work in
progress. progress.
[PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai [PCE-APS] Tomohiro Otani, Kenichi Ogaki, Diego Caviglia, and Fatai
Zhang, "Requirements for GMPLS applications of PCE", Zhang, "Requirements for GMPLS applications of PCE",
draft-ietf-pce-gmpls-aps-req-01.txt, July 2009. draft-ietf-pce-gmpls-aps-req-01.txt, July 2009.
[GMPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS [GMPLS-SEC] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", Work in Progress, October 2009. Networks", Work in Progress, October 2009.
10. Authors' Addresses 11. Authors' Addresses
Fatai Zhang Fatai Zhang
Huawei Technologies Huawei Technologies
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Phone: +86-755-28972912 Phone: +86-755-28972912
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Dan Li Dan Li
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
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: 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
skipping to change at page 22, line 29 skipping to change at page 23, line 20
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
11. Contributors Daniele Ceccarelli
Ericsson
Via A. Negrone 1/A
Genova - Sestri Ponente
Italy
Email: daniele.ceccarelli@ericsson.com
12. Contributors
Jianrui Han Jianrui Han
Huawei Technologies Co., Ltd. Huawei Technologies Co., Ltd.
F3-5-B R&D Center, Huawei Base F3-5-B R&D Center, Huawei Base
Bantian, Longgang District Bantian, Longgang District
Shenzhen 518129 P.R.China Shenzhen 518129 P.R.China
Phone: +86-755-28972913 Phone: +86-755-28972913
Email: hanjianrui@huawei.com Email: hanjianrui@huawei.com
skipping to change at page 23, line 45 skipping to change at page 24, line 46
occupying several TSs. For example, if ODU1 is multiplexed into ODU2, occupying several TSs. For example, if ODU1 is multiplexed into ODU2,
and ODU2 is mapped into OTU2, the ODU1 is a LO ODU and the ODU2 is a and ODU2 is mapped into OTU2, the ODU1 is a LO ODU and the ODU2 is a
HO ODU (from a multiplexing perspective). HO ODU (from a multiplexing perspective).
Thus, a LO ODUj represents the container transporting a client of the Thus, a LO ODUj represents the container transporting a client of the
OTN that is either directly mapped into an OTUk (k = j) or OTN that is either directly mapped into an OTUk (k = j) or
multiplexed into a server HO ODUk (k > j) container. Consequently, multiplexed into a server HO ODUk (k > j) container. Consequently,
the HO ODUk represents the entity transporting a multiplex of LO ODUj the HO ODUk represents the entity transporting a multiplex of LO ODUj
tributary signals in its OPUk area. tributary signals in its OPUk area.
In the case of LO ODUj mapped into an OTUk (k = j) directly, Figure 5 In the case of LO ODUj mapped into an OTUk (k = j) directly, Figure 6
give an example of this kind of LO ODU connection. give an example of this kind of LO ODU connection.
In Figure 5, The LO ODUj is switched at the intermediate ODXC node. In Figure 6, The LO ODUj is switched at the intermediate ODXC node.
OCh and OTUk are associated with each other. From the viewpoint of OCh and OTUk are associated with each other. From the viewpoint of
connection management, the management of OTUk is similar with OCh. LO connection management, the management of OTUk is similar with OCh. LO
ODUj and OCh/OTUk have client/server relationships. ODUj and OCh/OTUk have client/server relationships.
For example, one LO ODU1 connection can be setup between Node A and For example, one LO ODU1 connection can be setup between Node A and
Node C. This LO ODU1 connection is to be supported by OCh/OTU1 Node C. This LO ODU1 connection is to be supported by OCh/OTU1
connections, which are to be set up between Node A and Node B and connections, which are to be set up between Node A and Node B and
between Node B and Node C. LO ODU1 can be mapped into OTU1 at Node A, between Node B and Node C. LO ODU1 can be mapped into OTU1 at Node A,
demapped from it in Node B, switched at Node B, and then mapped into demapped from it in Node B, switched at Node B, and then mapped into
the next OTU1 and demapped from this OTU1 at Node C. the next OTU1 and demapped from this OTU1 at Node C.
skipping to change at page 24, line 29 skipping to change at page 25, line 29
| | OCh/OTUk | | OCh/OTUk | | | | OCh/OTUk | | OCh/OTUk | |
| +--------(a)---------+ +--------(a)---------+ | | +--------(a)---------+ +--------(a)---------+ |
| | | | | | | | | | | |
+------++-+ +--+---+--+ +-++------+ +------++-+ +--+---+--+ +-++------+
| |EO| |OE| |EO| |OE| | | |EO| |OE| |EO| |OE| |
| +--+----------------+--+ +--+----------------+--+ | | +--+----------------+--+ +--+----------------+--+ |
| ODXC | | ODXC | | ODXC | | ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
Node A Node B Node C Node A Node B Node C
Figure 5 - Connection of LO ODUj (1) Figure 6 - Connection of LO ODUj (1)
In the case of LO ODUj multiplexing into HO ODUk, Figure 6 gives an In the case of LO ODUj multiplexing into HO ODUk, Figure 7 gives an
example of this kind of LO ODU connection. example of this kind of LO ODU connection.
In Figure 6, OCh, OTUk, HO ODUk are associated with each other. The In Figure 7, OCh, OTUk, HO ODUk are associated with each other. The
LO ODUj is multiplexed/de-multiplexed into/from the HO ODU at each LO ODUj is multiplexed/de-multiplexed into/from the HO ODU at each
ODXC node and switched at each ODXC node (i.e. trib port to line port, ODXC node and switched at each ODXC node (i.e. trib port to line port,
line card to line port, line port to trib port). From the viewpoint line card to line port, line port to trib port). From the viewpoint
of connection management, the management of these HO ODUk and OTUk of connection management, the management of these HO ODUk and OTUk
are similar to OCh. LO ODUj and OCh/OTUk/HO ODUk have client/server are similar to OCh. LO ODUj and OCh/OTUk/HO ODUk have client/server
relationships. When a LO ODU connection is setup, it will be using relationships. When a LO ODU connection is setup, it will be using
the existing HO ODUk (/OTUk/OCh) connections which have been set up. the existing HO ODUk (/OTUk/OCh) connections which have been set up.
Those HO ODUk connections provide LO ODU links, of which the LO ODU Those HO ODUk connections provide LO ODU links, of which the LO ODU
connection manager requests a link connection to support the LO ODU connection manager requests a link connection to support the LO ODU
connection. connection.
skipping to change at page 25, line 20 skipping to change at page 26, line 20
| | OCh/OTUk/HO ODUk | | OCh/OTUk/HO ODUk | | | | OCh/OTUk/HO ODUk | | OCh/OTUk/HO ODUk | |
| +--------(c)---------+ +---------(c)--------+ | | +--------(c)---------+ +---------(c)--------+ |
| | | | | | | | | | | |
+------++-+ +--+---+--+ +-++------+ +------++-+ +--+---+--+ +-++------+
| |EO| |OE| |EO| |OE| | | |EO| |OE| |EO| |OE| |
| +--+----------------+--+ +--+----------------+--+ | | +--+----------------+--+ +--+----------------+--+ |
| ODXC | | ODXC | | ODXC | | ODXC | | ODXC | | ODXC |
+---------+ +---------+ +---------+ +---------+ +---------+ +---------+
Node A Node B Node C Node A Node B Node C
Figure 6 - Connection of LO ODUj (2) Figure 7 - Connection of LO ODUj (2)
Intellectual Property Intellectual Property
The IETF Trust takes no position regarding the validity or scope of The IETF Trust takes no position regarding the validity or scope of
any Intellectual Property Rights or other rights that might be any Intellectual Property Rights or other rights that might be
claimed to pertain to the implementation or use of the technology claimed to pertain to the implementation or use of the technology
described in any IETF Document or the extent to which any license described in any IETF Document or the extent to which any license
under such rights might or might not be available; nor does it under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any represent that it has made any independent effort to identify any
such rights. such rights.
 End of changes. 55 change blocks. 
176 lines changed or deleted 216 lines changed or added

This html diff was produced by rfcdiff 1.40. The latest version is available from http://tools.ietf.org/tools/rfcdiff/