draft-ietf-ccamp-flexible-grid-rsvp-te-ext-05.txt   rfc7792.txt 
CCAMP Working Group Fatai Zhang
Internet-Draft Xian Zhang
Intended status: Standards Track Huawei
Adrian Farrel
Old Dog Consulting
Oscar Gonzalez de Dios
Telefonica
D. Ceccarelli
Ericsson
Expires: May 19, 2016 November 20, 2015
RSVP-TE Signaling Extensions in support of Flexi-grid DWDM networks Internet Engineering Task Force (IETF) F. Zhang
Request for Comments: 7792 X. Zhang
Category: Standards Track Huawei
ISSN: 2070-1721 A. Farrel
Old Dog Consulting
O. Gonzalez de Dios
Telefonica
D. Ceccarelli
Ericsson
March 2016
draft-ietf-ccamp-flexible-grid-rsvp-te-ext-05.txt RSVP-TE Signaling Extensions in Support of Flexi-Grid
Dense Wavelength Division Multiplexing (DWDM) Networks
Abstract Abstract
This memo describes the extensions to the Resource reSerVation This memo describes the extensions to the Resource Reservation
Protocol Traffic Engineering (RSVP-TE) signaling protocol to support Protocol - Traffic Engineering (RSVP-TE) signaling protocol to
Label Switched Paths (LSPs) in a GMPLS-controlled network that support Label Switched Paths (LSPs) in a GMPLS-controlled network
includes devices using the flexible optical grid. that includes devices using the flexible optical grid.
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Status of This Memo
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six This is an Internet Standards Track document.
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at This document is a product of the Internet Engineering Task Force
http://www.ietf.org/ietf/1id-abstracts.txt. (IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
The list of Internet-Draft Shadow Directories can be accessed at Information about the current status of this document, any errata,
http://www.ietf.org/shadow.html. and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc7792.
This Internet-Draft will expire on May 19, 2016. Copyright Notice
Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction ................................................ 2 1. Introduction ....................................................3
2. Terminology ................................................. 3 2. Terminology .....................................................3
2.1. Conventions used in this document .......................3 2.1. Conventions Used in This Document ..........................3
3. Requirements for Flexible Grid Signaling .....................3 3. Requirements for Flexible-Grid Signaling ........................4
3.1. Slot Width ............................................. 4 3.1. Slot Width .................................................4
3.2. Frequency Slot ......................................... 4 3.2. Frequency Slot .............................................5
4. Protocol Extensions ......................................... 5 4. Protocol Extensions .............................................6
4.1. Traffic Parameters...................................... 5 4.1. Traffic Parameters .........................................6
4.1.1. Applicability to Fixed Grid Networks ...............6 4.1.1. Applicability to Fixed-Grid Networks ................7
4.2. Generalized Label....................................... 6 4.2. Generalized Label ..........................................7
4.3. Signaling Procedures.................................... 7 4.3. Signaling Procedures .......................................7
5. IANA Considerations ......................................... 7 5. IANA Considerations .............................................8
5.1. RSVP Objects Class Types................................ 7 5.1. Class Types for RSVP Objects ...............................8
6. Manageability Considerations................................. 8 6. Manageability Considerations ....................................8
7. Implementation Status........................................ 8 7. Security Considerations .........................................8
7.1. Centre Tecnologic de Telecomunicacions de Catalunya (CTTC)8 8. References ......................................................9
8. Acknowledgments ............................................ 10 8.1. Normative References .......................................9
9. Security Considerations..................................... 10 8.2. Informative References .....................................9
10. References ................................................ 10 Acknowledgments ...................................................11
10.1. Normative References.................................. 10 Contributors ......................................................11
10.2. Informative References................................ 10 Authors' Addresses ................................................12
11. Contributors' Addresses.................................... 11
12. Authors' Addresses .........................................12
1. Introduction 1. Introduction
[G.694.1] defines the Dense Wavelength Division Multiplexing (DWDM) [G.694.1] defines the Dense Wavelength Division Multiplexing (DWDM)
frequency grids for Wavelength Division Multiplexing (WDM) frequency grids for Wavelength Division Multiplexing (WDM)
applications. A frequency grid is a reference set of frequencies applications. A frequency grid is a reference set of frequencies
used to denote allowed nominal central frequencies that may be used used to denote allowed nominal central frequencies that may be used
for defining applications that utilize WDM transmission. The channel for defining applications that utilize WDM transmission. The channel
spacing is the frequency spacing between two allowed nominal central spacing is the frequency spacing between two allowed nominal central
frequencies. All of the wavelengths on a fiber use different central frequencies. All of the wavelengths on a fiber use different central
frequencies and occupy a designated range of frequency. frequencies and occupy a designated range of frequencies.
Fixed grid channel spacing is selected from 12.5 GHz, 25 GHz, 50 GHz, Fixed-grid channel spacing is selected from 12.5 GHz, 25 GHz, 50 GHz,
100 GHz and integer multiples of 100 GHz. But [G.694.1] also defines 100 GHz, and integer multiples of 100 GHz. Additionally, [G.694.1]
"flexible grids", known as "flexi-grid". The terms "frequency slot" defines "flexible grids", also known as "flexi-grid". The terms
(i.e., the frequency range allocated to a specific channel and "frequency slot" (i.e., the frequency range allocated to a specific
unavailable to other channels within a flexible grid) and "slot channel and unavailable to other channels within a flexible grid) and
width" (i.e., the full width of a frequency slot in a flexible grid) "slot width" (i.e., the full width of a frequency slot in a flexible
are introduced in [G.694.1] to define a flexible grid. grid) are introduced in [G.694.1] to define a flexible grid.
[FLEX-FWK] defines a framework and the associated control plane [RFC7698] defines a framework and the associated control-plane
requirements for the Generalized Multi-Protocol Label Switching requirements for the GMPLS-based [RFC3945] control of flexi-grid DWDM
(GMPLS) [RFC3945] based control of flexi-grid DWDM networks. networks.
[RFC6163] provides a framework for GMPLS and Path Computation [RFC6163] provides a framework for GMPLS and Path Computation Element
Element (PCE) control of Wavelength Switched Optical Networks (PCE) control of Wavelength Switched Optical Networks (WSONs), and
(WSONs), and [WSON-SIG] describes the requirements and protocol [RFC7689] describes the requirements and protocol extensions for
extensions for signaling to set up Label Switched Paths (LSPs) in signaling to set up Label Switched Paths (LSPs) in WSONs.
WSONs.
This document describes the additional requirements and protocol This document describes the additional requirements and protocol
extensions to Resource reSerVation Protocol-Traffic Engineering extensions to Resource Reservation Protocol - Traffic Engineering
(RSVP-TE) [RFC3473] to set up LSPs in networks that support the (RSVP-TE) [RFC3473] to set up LSPs in networks that support the
flexi-grid. flexi-grid.
2. Terminology 2. Terminology
For terminology related to flexi-grid, please refer to [FLEX-FWK] For terminology related to flexi-grid, please refer to [RFC7698] and
and [G.694.1]. [G.694.1].
2.1. Conventions used in this document 2.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
3. Requirements for Flexible Grid Signaling 3. Requirements for Flexible-Grid Signaling
The architecture for establishing LSPs in a flexi-grid network is The architecture for establishing LSPs in a flexi-grid network is
described in [FLEX-FWK]. described in [RFC7698].
An optical spectrum LSP occupies a specific frequency slot, i.e., a An optical-spectrum LSP occupies a specific frequency slot, i.e., a
range of frequencies. The process of computing a route and the range of frequencies. The process of computing a route and the
allocation of a frequency slot is referred to as Routing and allocation of a frequency slot is referred to as "Routing and
Spectrum Assignment (RSA). [FLEX-FWK] describes three architectural Spectrum Assignment" (RSA). [RFC7698] describes three architectural
approaches to RSA: combined RSA, separated RSA, and distributed SA. approaches to RSA: combined RSA, separated RSA, and distributed SA.
The first two approaches are referred to as "centralized SA" because The first two approaches are referred to as "centralized SA", because
both routing and spectrum (frequency slot) assignment are performed routing (i.e., path determination) and spectrum assignment (i.e.,
by a centralized entity before the signaling procedure. selection of frequency slots) are both performed by a centralized
entity prior to the signaling procedure.
In the case of centralized SA, the assigned frequency slot is In the case of centralized SA, the assigned frequency slot is
specified in the RSVP-TE Path message during LSP setup. In the case specified in the RSVP-TE Path message during LSP setup. In the case
of distributed SA, the slot width of the flexi-grid LSP is specified of distributed SA, the slot width of the flexi-grid LSP is specified
in the Path message, allowing the network elements to select the in the Path message, allowing the network elements to select the
frequency slot to be used when they process the RSVP-TE messages. frequency slot to be used when they process the RSVP-TE messages.
If the capability to switch or convert the whole optical spectrum If the capability to switch or convert the whole optical spectrum
allocated to an optical spectrum LSP is not available at some nodes allocated to an optical-spectrum LSP is not available at some nodes
along the path of the LSP, the LSP is subject to the Optical along the path of the LSP, the LSP is subject to the Optical
"Spectrum Continuity Constraint" as described in [FLEX-FWK]. "spectrum continuity constraint" as described in [RFC7698].
The remainder of this section states the additional requirements for The remainder of this section states the additional requirements for
signaling in a flexi-grid network. signaling in a flexi-grid network.
3.1. Slot Width 3.1. Slot Width
The slot width is an end-to-end parameter representing how much The slot width is an end-to-end parameter representing how much
frequency resource is requested for a flexi-grid LSP. It is the frequency resource is requested for a flexi-grid LSP. It is the
equivalent of optical bandwidth, although the amount of bandwidth equivalent of optical bandwidth, although the amount of bandwidth
associated with a slot width will depend on the signal encoding. associated with a slot width will depend on the signal encoding.
Different LSPs may request different amounts of frequency resource Different LSPs may request different amounts of frequency resource in
in flexible grid networks, so the slot width MUST be carried in the flexible-grid networks, so the slot width MUST be carried in the
signaling message during LSP establishment. This enables the nodes signaling message during LSP establishment. This enables the nodes
along the LSP to know how much frequency resource has been requested along the LSP to know how much frequency resource has been requested
(in a Path message) and has been allocated (by a Resv message) for (in a Path message) and how much has been allocated (by a
the LSP. Resv message) for the LSP.
3.2. Frequency Slot 3.2. Frequency Slot
The frequency slot information identifies which part of the The frequency slot information identifies which part of the frequency
frequency spectrum is allocated on each link for an LSP in a flexi- spectrum is allocated on each link for an LSP in a flexi-grid
grid network. network.
This information MUST be present in a Resv message to indicate, hop- This information MUST be present in a Resv message to indicate,
by-hop, the central frequency of the allocated resource. In hop by hop, the central frequency of the allocated resource. In
combination with the slot width indicated in a Resv message (see combination with the slot width indicated in a Resv message (see
Section 3.1) the central frequency carried in a Resv message Section 3.1), the central frequency carried in a Resv message
identifies the resources reserved for the LSP (known as the identifies the resources reserved for the LSP (known as the
frequency slot). frequency slot).
The frequency slot can be represented by the two parameters as The frequency slot can be represented by two parameters, as follows:
follows:
Frequency slot = [(central frequency) - (slot width)/2] ~ Frequency slot = [(central frequency) - (slot width)/2] ~
[(central frequency) + (slot width)/2] [(central frequency) + (slot width)/2]
As is common with other resource identifiers (i.e., labels) in GMPLS As is common with other resource identifiers (i.e., labels) in GMPLS
signaling, it must be possible for the head-end node when sending a signaling, it must be possible for the head-end node, when sending a
Path message to suggest or require the central frequency to be used Path message, to suggest or require the central frequency to be used
for the LSP. Furthermore, for bidirectional LSPs, the Path message for the LSP. Furthermore, for bidirectional LSPs, the Path message
MUST be able to specify the central frequency to be used for reverse MUST be able to specify the central frequency to be used for
direction traffic. reverse-direction traffic.
As described in [G.694.1], the allowed frequency slots for the As described in [G.694.1], the allowed frequency slots for the
flexible DWDM grid have a nominal central frequency (in THz) defined flexible DWDM grid have a nominal central frequency (in THz),
by: defined by:
193.1 + n * 0.00625 193.1 + n * 0.00625
where n is zero or a positive or negative integer. where n is zero or a positive or negative integer.
The slot width (in GHz) is defined as: The slot width (in GHz) is defined as:
12.5 * m 12.5 * m
where m is a positive integer. where m is a positive integer.
It is possible that an implementation supports only a subset of the It is possible that an implementation supports only a subset of the
possible slot widths and central frequencies. For example, an possible slot widths and central frequencies. For example, an
implementation could be built where the nominal central frequency implementation can be built that is
granularity is 12.5 GHz (by only allowing values of n that are even)
and that only supports slot widths as a multiple of 25 GHz (by only
allowing values of m that are even).
Further details can be found in [FLEX-FWK]. 1. limited to have a nominal central frequency granularity of
12.5 GHz, by only allowing values of n that are even, and
4. Protocol Extensions 2. further limited to only support slot widths of 25 GHz, by only
allowing values of m that are even.
This section defines the extensions to RSVP-TE signaling for GMPLS Further details can be found in [RFC7698].
[RFC3473] to support flexible grid networks.
4.1. Traffic Parameters 4. Protocol Extensions
In RSVP-TE, the SENDER_TSPEC object in the Path message indicates This section defines the extensions to RSVP-TE signaling for GMPLS
the requested resource reservation. The FLOWSPEC object in the Resv [RFC3473] to support flexible-grid networks.
message indicates the actual resource reservation.
As described in Section 3.1, the slot width represents how much 4.1. Traffic Parameters
frequency resource is requested for a flexi-grid LSP. That is, it
describes the end-to-end traffic profile of the LSP. Therefore, the
traffic parameters for a flexi-grid LSP encode the slot width.
This document defines new C-Types for the SENDER_TSPEC and FLOWSPEC In RSVP-TE, the SENDER_TSPEC object in the Path message indicates the
objects to carry Spectrum Switched Optical Network (SSON) traffic requested resource reservation. The FLOWSPEC object in the Resv
parameters: message indicates the actual resource reservation. As described in
Section 3.1, the slot width represents how much frequency resource is
requested for a flexi-grid LSP. That is, it describes the end-to-end
traffic profile of the LSP. Therefore, the traffic parameters for a
flexi-grid LSP encode the slot width.
SSON SENDER_TSPEC: Class = 12, C-Type = TBD1. This document defines new Class Types (C-Types) for the SENDER_TSPEC
and FLOWSPEC objects to carry Spectrum-Switched Optical Network
(SSON) traffic parameters:
SSON FLOWSPEC: Class = 9, C-Type = TBD2. SSON SENDER_TSPEC: Class = 12, C-Type = 8.
SSON FLOWSPEC: Class = 9, C-Type = 8.
The SSON traffic parameters carried in both objects MUST have the The SSON traffic parameters carried in both objects MUST have the
same format as shown in Figure 1. format shown in Figure 1.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| m | Reserved | | m | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: The SSON Traffic Parameters Figure 1: The SSON Traffic Parameters
m (16 bits): a positive integer and the slot width is specified by m (16 bits): a positive integer; the slot width is specified by
m*12.5 GHz. m * 12.5 GHz.
The Reserved bits MUST be set to zero and ignored upon receipt. The Reserved bits MUST be set to zero and ignored upon receipt.
4.1.1. Applicability to Fixed Grid Networks 4.1.1. Applicability to Fixed-Grid Networks
Note that the slot width (i.e., traffic parameters) of a fixed grid Note that the slot width (i.e., traffic parameters) of a fixed grid
defined in [G.694.1] can also be specified by using the SSON traffic defined in [G.694.1] can also be specified by using the SSON traffic
parameters. The fixed grid channel spacings (12.5 GHz, 25 GHz, 50 parameters. The fixed-grid channel spacings (12.5 GHz, 25 GHz,
GHz, 100 GHz and integer multiples of 100 GHz) are also the 50 GHz, 100 GHz, and integer multiples of 100 GHz) are also the
multiples of 12.5 GHz, so the m parameter can be used to represent multiples of 12.5 GHz, so the m parameter can be used to represent
these slot widths. these slot widths.
Therefore, it is possible to consider using the new traffic Therefore, it is possible to consider using the new traffic parameter
parameter object types in common signaling messages for flexi-grid object types in common signaling messages for flexi-grid and legacy
and legacy DWDM networks. DWDM networks.
4.2. Generalized Label 4.2. Generalized Label
In the case of a flexible grid network, the labels that have been In the case of a flexible-grid network, the labels that have been
requested or allocated as signaled in the RSVP-TE objects are requested or allocated as signaled in the RSVP-TE objects are encoded
encoded as described in [FLEX-LBL]. This new label encoding can as described in [RFC7699]. This new label encoding can appear in any
appear in any RSVP-TE object or sub-object that can carry a label. RSVP-TE object or sub-object that can carry a label.
As noted in Section 4.2 of [FLEX-LBL], the m parameter forms part of As noted in Section 4.2 of [RFC7699], the m parameter forms part of
the label as well as part of the traffic parameters. the label as well as part of the traffic parameters.
As described in Section 4.3 of [FLEX-LBL], a "compound label", As described in Section 4.3 of [RFC7699], a "compound label",
constructed from a concatenation of the flexi-grid LABELs, is used constructed from a concatenation of the flexi-grid labels, is used
when signaling an LSP that uses multiple flexi-grid slots. when signaling an LSP that uses multiple flexi-grid slots.
4.3. Signaling Procedures 4.3. Signaling Procedures
There are no differences between the signaling procedure described There are no differences between the signaling procedures described
for LSP control in [FLEX-FWK] and those required for use in a fixed- for LSP control in [RFC7698] and those required for use in a
grid network [WSON-SIG]. Obviously, the TSpec, FlowSpec, and label fixed-grid network [RFC7689]. Obviously, the TSpec, FlowSpec, and
formats described in Sections 4.1 and 4.2 are used. The signaling label formats described in Sections 4.1 and 4.2 are used. The
procedures for distributed SA and centralized SA can be applied. signaling procedures for distributed SA and centralized SA can be
applied.
5. IANA Considerations 5. IANA Considerations
5.1. RSVP Objects Class Types 5.1. Class Types for RSVP Objects
This document introduces two new Class Types for existing RSVP This document introduces two new Class Types for existing RSVP
objects. IANA is requested to make allocations from the "Resource objects. IANA has made the following allocations from the "Resource
ReSerVation Protocol (RSVP) Parameters" registry using the "Class Reservation Protocol (RSVP) Parameters" registry using the "Class
Names, Class Numbers, and Class Types" sub-registry. Names, Class Numbers, and Class Types" sub-registry.
Class Number Class Name Reference Class Number Class Name Reference
------------ ----------------------- --------- ------------ ----------------------- ---------
9 FLOWSPEC [RFC2205] 9 FLOWSPEC [RFC2205]
Class Type (C-Type): Class Type (C-Type):
(TBD2) SSON FLOWSPEC [This.I-D] (8) SSON FLOWSPEC RFC 7792
Class Number Class Name Reference Class Number Class Name Reference
------------ ----------------------- --------- ------------ ----------------------- ---------
12 SENDER_TSPEC [RFC2205] 12 SENDER_TSPEC [RFC2205]
Class Type (C-Type): Class Type (C-Type):
(TBD1) SSON SENDER_TSPEC [This.I-D] (8) SSON SENDER_TSPEC RFC 7792
IANA is requested to assign the same value for TBD1 and TBD2, and a
value of 8 is suggested.
6. Manageability Considerations 6. Manageability Considerations
This document makes minor modifications to GMPLS signaling, but does This document makes minor modifications to GMPLS signaling but does
not change the manageability considerations for such networks. not change the manageability considerations for such networks.
Clearly, protocol analysis tools and other diagnostic aids Clearly, protocol analysis tools and other diagnostic aids (including
(including logging systems and MIB modules) will need to be enhanced logging systems and MIB modules) will need to be enhanced to support
to support the new traffic parameters and label formats. the new traffic parameters and label formats.
7. Implementation Status
[RFC Editor Note: Please remove this entire seciton prior to
publication as an RFC.]
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of
this Internet-Draft, and is based on a proposal described in RFC
6982 [RFC6982]. The description of implementations in this section
is intended to assist the IETF in its decision processes in
progressing drafts to RFCs. Please note that the listing of any
individual implementation here does not imply endorsement by the
IETF. Furthermore, no effort has been spent to verify the
information presented here that was supplied by IETF contributors.
This is not intended as, and must not be construed to be, a catalog
of available implementations or their features. Readers are advised
to note that other implementations may exist.
According to RFC 6982, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable
experimentation and feedback that have made the implemented
protocols more mature. It is up to the individual working groups to
use this information as they see fit."
7.1. Centre Tecnologic de Telecomunicacions de Catalunya (CTTC)
Organization Responsible for the Implementation:
Centre Tecnologic de Telecomunicacions de Catalunya (CTTC)
Optical Networks and Systems Department
Implementation Name and Details:
ADRENALINE testbed
http://networks.cttc.es/experimental-testbeds/
Brief Description:
Experimental testbed implementation of GMPLS/PCE control plane.
Level of Maturity:
Implemented as extensions to a mature GMLPS/PCE control plane.
It is limited to research / prototyping stages, but it has been
used successfully for more than the last five years.
Coverage:
Support for the Tspec, FlowSpec, and label formats as described
version 03 of this document. Label format support extends to the
following RSVP-TE objects and sub-objects:
- Generalized Label Object
- Suggested Label Object
- Upstream Label Object
- ERO Label Subobjects
It is expected that this implementation will evolve to follow the
evolution of this document.
Licensing:
Proprietary
Implementation Experience:
Implementation of this document reports no issues.
General implementation experience has been reported in a number
of journal papers. Contact Ramon Casellas for more information or
see
http://networks.cttc.es/publications/?search=GMPLS&research_area=opt
ical-networks-systems
Contact Information:
Ramon Casellas: ramon.casellas@cttc.es
Interoperability:
No report.
8. Acknowledgments
This work was supported in part by the FP-7 IDEALIST project under
grant agreement number 317999.
9. Security Considerations 7. Security Considerations
This document introduces no new security considerations to [RFC3473]. This document introduces no new security considerations to [RFC3473].
See also [RFC5920] for a discussion of security considerations for See also [RFC5920] for a discussion of security considerations for
GMPLS signaling. GMPLS signaling.
10. References 8. References
10.1. Normative References 8.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to indicate [G.694.1] International Telecommunication Union, "Spectral grids for
requirements levels", RFC 2119, March 1997. WDM applications: DWDM frequency grid", ITU-T
Recommendation G.694.1, February 2012,
<https://www.itu.int/rec/T-REC-G.694.1/en>.
[RFC3473] L. Berger, Ed., "Generalized Multi-Protocol Label [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Switching (GMPLS) Signaling Resource ReserVation Protocol- Requirement Levels", BCP 14, RFC 2119,
Traffic Engineering (RSVP-TE) Extensions", RFC 3473, DOI 10.17487/RFC2119, March 1997,
January 2003. <http://www.rfc-editor.org/info/rfc2119>.
[G.694.1] ITU-T Recommendation G.694.1 (revision 2), "Spectral grids [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label
for WDM applications: DWDM frequency grid", February 2012. Switching (GMPLS) Signaling Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE) Extensions",
RFC 3473, DOI 10.17487/RFC3473, January 2003,
<http://www.rfc-editor.org/info/rfc3473>.
[FLEX-LBL] King, D., Farrel, A. and Y. Li, "Generalized Labels for [RFC7699] Farrel, A., King, D., Li, Y., and F. Zhang, "Generalized
the Flexi-Grid in Lambda Switched Capable (LSC) Label Labels for the Flexi-Grid in Lambda Switch Capable (LSC)
Switching Routers", draft-ietf-ccamp-flexigrid-lambda- Label Switching Routers", RFC 7699, DOI 10.17487/RFC7699,
label, work in progress. November 2015, <http://www.rfc-editor.org/info/rfc7699>.
10.2. Informative References 8.2. Informative References
[RFC3945] Mannie, E., "Generalized Multi-Protocol Label Switching [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
(GMPLS)" Architecture, RFC3945, October 2004. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
September 1997, <http://www.rfc-editor.org/info/rfc2205>.
[RFC2205] Braden, R., Zhang L., Berson, S., Herzog, S. and S. Jamin, [RFC3945] Mannie, E., Ed., "Generalized Multi-Protocol Label
"Resource ReServation Protocol (RSVP) - Version 1, Switching (GMPLS) Architecture", RFC 3945,
Functional Specification", RFC2205, September 1997. DOI 10.17487/RFC3945, October 2004,
<http://www.rfc-editor.org/info/rfc3945>.
[RFC5920] L. Fang et al., "Security Framework for MPLS and GMPLS [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS
Networks", RFC 5920, July 2010. Networks", RFC 5920, DOI 10.17487/RFC5920, July 2010,
<http://www.rfc-editor.org/info/rfc5920>.
[RFC6163] Y. Lee, G. Bernstein and W. Imajuku, "Framework for GMPLS [RFC6163] Lee, Y., Ed., Bernstein, G., Ed., and W. Imajuku,
and Path Computation Element (PCE) Control of Wavelength "Framework for GMPLS and Path Computation Element (PCE)
Switched Optical Networks (WSONs)", RFC 6163, April 2011. Control of Wavelength Switched Optical Networks (WSONs)",
RFC 6163, DOI 10.17487/RFC6163, April 2011,
<http://www.rfc-editor.org/info/rfc6163>.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running [RFC7689] Bernstein, G., Ed., Xu, S., Lee, Y., Ed., Martinelli, G.,
Code: The Implementation Status Section", RFC 6982, July and H. Harai, "Signaling Extensions for Wavelength
2013. Switched Optical Networks", RFC 7689,
DOI 10.17487/RFC7689, November 2015,
<http://www.rfc-editor.org/info/rfc7689>.
[RFC Editor Note: This reference can be removed when Section 7 is [RFC7698] Gonzalez de Dios, O., Ed., Casellas, R., Ed., Zhang, F.,
removed] Fu, X., Ceccarelli, D., and I. Hussain, "Framework and
Requirements for GMPLS-Based Control of Flexi-Grid Dense
Wavelength Division Multiplexing (DWDM) Networks",
RFC 7698, DOI 10.17487/RFC7698, November 2015,
<http://www.rfc-editor.org/info/rfc7698>.
[FLEX-FWK] Gonzalez de Dios, O, Casellas R., Zhang, F., Fu, X., Acknowledgments
Ceccarelli, D., and I. Hussain, "Framework and
Requirements for GMPLS based control of Flexi-grid DWDM
networks", draft-ietf-ccamp-flexi-grid-fwk, work in
progress.
[WSON-SIG] G. Bernstein, Sugang Xu, Y. Lee, G. Martinelli and This work was supported in part by the FP-7 IDEALIST project under
Hiroaki Harai, "Signaling Extensions for Wavelength grant agreement number 317999.
Switched Optical Networks", draft-ietf-ccamp-wson-
signaling, work in progress.
11. Contributors' Addresses Contributors
Ramon Casellas Ramon Casellas
CTTC CTTC
Av. Carl Friedrich Gauss n7 Av. Carl Friedrich Gauss n7
Castelldefels, Barcelona 08860 Castelldefels, Barcelona 08860
Spain Spain
Email: ramon.casellas@cttc.es Email: ramon.casellas@cttc.es
Felipe Jimenez Arribas Felipe Jimenez Arribas
Telefonica Investigacion y Desarrollo Telefonica Investigacion y Desarrollo
Emilio Vargas 6 Emilio Vargas 6
Madrid, 28045 Madrid 28045
Spain Spain
Email: felipej@tid.es Email: felipej@tid.es
Yi Lin Yi Lin
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
China
Phone: +86-755-28972914 Phone: +86 755-28972914
Email: yi.lin@huawei.com Email: yi.lin@huawei.com
Qilei Wang Qilei Wang
ZTE ZTE
wang.qilei@zte.com.cn
Email: wang.qilei@zte.com.cn
Haomian Zheng Haomian Zheng
Huawei Technologies Huawei Technologies
zhenghaomian@huawei.com
12. Authors' Addresses Email: zhenghaomian@huawei.com
Authors' Addresses
Fatai Zhang Fatai Zhang
Huawei Technologies Huawei Technologies
Email: zhangfatai@huawei.com Email: zhangfatai@huawei.com
Xian Zhang Xian Zhang
Huawei Technologies Huawei Technologies
Email: zhang.xian@huawei.com Email: zhang.xian@huawei.com
Adrian Farrel Adrian Farrel
Old Dog Consulting Old Dog Consulting
Email: adrian@olddog.co.uk Email: adrian@olddog.co.uk
Oscar Gonzalez de Dios Oscar Gonzalez de Dios
Telefonica Investigacion y Desarrollo Telefonica Investigacion y Desarrollo
Emilio Vargas 6 Ronda de la Comunicacion S/N
Madrid, 28045 Madrid 28050
Spain Spain
Phone: +34 913374013
Email: ogondio@tid.es Phone: +34 913129647
Email: oscar.gonzalezdedios@telefonica.com
Daniele Ceccarelli Daniele Ceccarelli
Ericsson Ericsson
Via A. Negrone 1/A Via A. Negrone 1/A
Genova - Sestri Ponente Genova - Sestri Ponente
Italy Italy
Email: daniele.ceccarelli@ericsson.com Email: daniele.ceccarelli@ericsson.com
 End of changes. 108 change blocks. 
321 lines changed or deleted 252 lines changed or added

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