PCEP Extension for Flexible Grid Networks
draft-ietf-pce-flexible-grid-00
The information below is for an old version of the document.
Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
---|---|---|---|
Authors | Young Lee , Haomian Zheng , Ramon Casellas , Ricard Vilalta , Daniele Ceccarelli , Francesco Lazzeri | ||
Last updated | 2019-02-20 | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | I-D Exists | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-pce-flexible-grid-00
PCE Working Group Y. Lee (Editor) Internet Draft H. Zheng Intended status: Standard Track Huawei Expires: June 19, 2019 R. Casellas R. Vilalta CTTC D. Ceccarelli F. Lazzeri Ericsson February 20, 2019 PCEP Extension for Flexible Grid Networks draft-ietf-pce-flexible-grid-00 Abstract This document provides the Path Computation Element Communication Protocol (PCEP) extensions for the support of Routing and Spectrum Assignment (RSA) in Flexible Grid networks. 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 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 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Lee, et al Expires June 2018 [Page 1] Internet-Draft PCEP Extension for Flexible Grid February 2019 This Internet-Draft will expire on June 19, 2019. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Terminology....................................................3 2. Requirements Language..........................................3 3. Introduction...................................................3 4. Spectrum Assignment (SA) Object................................4 4.1. Frequency-Slot Selection TLV..............................6 4.2. Frequency-slot Restriction Constraint TLV.................8 4.2.1. Frequency-Slot Restriction Field....................10 5. Encoding of a RSA Path Reply..................................10 5.1. Error Indicator..........................................11 5.2. NO-PATH Indicator........................................12 6. Manageability Considerations..................................12 6.1. Control of Function and Policy...........................13 6.2. Information and Data Models..............................13 6.3. Verifying Correct Operation..............................13 6.4. Requirements on Other Protocols and Functional Components13 6.5. Impact on Network Operation..............................14 7. Security Considerations.......................................14 8. IANA Considerations...........................................14 8.1. New PCEP Object..........................................14 8.2. New PCEP TLV: Frequency Slot Selection TLV...............15 8.3. New PCEP TLV: Frequency Slot Restriction Constraint TLV..15 8.4. New PCEP TLV: Spectrum Allocation TLV....................15 8.5. New No-Path Reasons......................................16 8.6. New Error-Types and Error-Values.........................16 9. References....................................................17 Lee et al. Expires June 2019 [Page 2] Internet-Draft PCEP Extension for Flexible Grid February 2019 9.1. Informative References...................................17 9.2. Normative References.....................................18 10. Contributors.................................................19 Authors' Addresses...............................................20 1. Terminology This document uses the terminology defined in [RFC4655], [RFC5440] and [RFC7698]. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Introduction [RFC4655] defines a PCE based path computation architecture and explains how a Path Computation Element (PCE) may compute Label Switched Paths (LSP) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and Generalized MPLS (GMPLS) networks at the request of Path Computation Clients (PCCs). A PCC is said to be any network component that makes such a request and may be, for instance, an Optical Switching Element within a Wavelength Division Multiplexing (WDM) network. The PCE, itself, can be located anywhere within the network, and may be within an optical switching element, a Network Management System (NMS) or Operational Support System (OSS), or may be an independent network server. The PCE communications Protocol (PCEP) is the communication protocol used between a PCC and a PCE, and may also be used between cooperating PCEs. [RFC4657] sets out the common protocol requirements for PCEP. Additional application-specific requirements for PCEP are deferred to separate documents. [PCEP-WSON] provides the PCEP extensions for the support of Routing and Wavelength Assignment (RWA) in Wavelength Switched Optical Networks (WSON) based on the requirements specified in [RFC6163] and [RFC7449]. [RFC7698] provides Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Lee et al. Expires June 2019 [Page 3] Internet-Draft PCEP Extension for Flexible Grid February 2019 Networks. To allow efficient allocation of optical spectral bandwidth for systems that have high bit-rates, the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings, and the concept of the "frequency slot". In such an environment, a data- plane connection is switched based on allocated, variable-sized frequency ranges within the optical spectrum, creating what is known as a flexible grid (flexi-grid). This document provides PCEP extensions to support Routing and Spectrum Assignment (RSA) in in Spectrum Switched Optical Networks (SSON)[RFC7698]. Figure 2 shows one typical PCE based implementation, which is referred to as the Combined Routing and Spectrum Assignment (R&SA) [RFC7698]. With this architecture, the two processes of routing and spectrum assignment are accessed via a single PCE. This architecture is the base architecture from which the PCEP extensions are going to be specified in this document. +----------------------------+ +-----+ | +-------+ +--+ | | | | |Routing| |SA| | | PCC |<----->| +-------+ +--+ | | | | | +-----+ | PCE | +----------------------------+ Figure 1 Combined Process (R&SA) architecture 4. Spectrum Assignment (SA) Object Spectrum allocation can be performed by the PCE by different means: (a) By means of Explicit Label Control (ELC) where the PCE allocates which label to use for each interface/node along the path. (b) By means of a Label Set where the PCE provides a range of potential frequency slots to allocate by each node along the path. This document aligns with GMPLS extensions for PCEP [PCEP-GMPLS] for generic property such as label, label-set and label assignment Lee et al. Expires June 2019 [Page 4] Internet-Draft PCEP Extension for Flexible Grid February 2019 noting that frequency is a type of label. Frequency restrictions and constraints are also formulated in terms of labels per [RFC7579]. Option (b) allows distributed spectrum allocation (performed during signaling) to complete spectrum assignment. Additionally, given a range of potential spectrums to allocate, the request SHOULD convey the heuristic / mechanism to the allocation. The format of a PCReq message after incorporating the Spectrum Assignment (SA) object is as follows: <PCReq Message> ::= <Common Header> [<svec-list>] <request-list> Where: <request-list>::=<request>[<request-list>] <request>::= <RP> <GENERALIZED ENDPOINTS> [ <SA> ] [other optional objects...] If the SA object is present in the request, it MUST be encoded after the ENDPOINTS object. The format of the Spectrum Assignment (SA) object body is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | Flags |M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frequency-Slot Selection TLV | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frequency-Slot Restriction Constraint TLV | Lee et al. Expires June 2019 [Page 5] Internet-Draft PCEP Extension for Flexible Grid February 2019 . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // Optional TLVs // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 SA Object o Reserved (16 bits) o Flags (16 bits) The following new flags SHOULD be set . M (Mode - 1 bit): M bit is used to indicate the mode of spectrum assignment. When M bit is set to 1, this indicates that the spectrum assigned by the PCE must be explicit. That is, the selected way to convey the allocated spectrum is by means of Explicit Label Control (ELC) [RFC4003] for each hop of a computed LSP. Otherwise, the spectrum assigned by the PCE needs not be explicit (i.e., it can be suggested in the form of label set objects in the corresponding response, to allow distributed SA. In such case, the PCE MUST return a Label Set Field as described in Section 2.6 of [RFC7579] in the response. See Section 5 of this document for the encoding discussion of a Label Set Field in a PCRep message. 4.1. Frequency-Slot Selection TLV The Frequency-Slot Selection TLV is used to indicate the frequency- slot selection constraint in regard to the order of frequency-slot assignment to be returned by the PCE. This TLV is only applied when M bit is set in the SA Object specified in Section 3.1. This TLV MUST NOT be used when the M bit is cleared. The Frequency-Slot Selection sub-TLV value field is defined as: Lee et al. Expires June 2019 [Page 6] Internet-Draft PCEP Extension for Flexible Grid February 2019 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| FSA Method | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Where: S (Symmetry, 1 bit): This flag is only meaningful when the request is for a bidirectional LSP (see [RFC5440]). 0 denotes requiring the same frequency-slot in both directions; 1 denotes that different spectrums on both directions are allowed. Frequency-Slot Assignment (FSA) Method (7 bits): 0: unspecified (any); This does not constrain the SA method used by a PCC This value is implied when the Frequency-Slot Selection sub-TLV is absent. 1: First-Fit. All the feasible frequency slots are numbered (based on "n" parameter), and this SA method chooses the available frequency-slot with the lowest index (of "n" parameter). 2: Random. This SA method chooses an feasible frequency-slot ("n" paramerer) randomly. 3-127: Unassigned. The processing rules for this TLV are as follows: If a PCE does not support the attribute(s), its behavior is specified below: - S bit not supported: a PathErr MUST be generated with the Error Code "Routing Problem" (24) with error sub-code "Unsupported Frequency slot Selection Symmetry value" (TDB). - FSA method not supported: a PathErr MUST be generated with the Error Code "Routing Problem" (24) with error sub-code Lee et al. Expires June 2019 [Page 7] Internet-Draft PCEP Extension for Flexible Grid February 2019 "Unsupported Frequency Slot Assignment value" (TDB). A Frequency Slot Selection TLV can be constructed by a node and added to an ERO Hop Attributes subobject in order to be processed by downstream nodes (transit and egress). As defined in [RFC7570], the R bit reflects the LSP_REQUIRED_ATTRIBUTE and LSP_ATTRIBUTE semantic defined in [RFC5420], and it SHOULD be set accordingly. Once a node properly parses the Spectrum Selection sub-TLV received in an ERO Hop Attributes subobject, the node use the indicated spectrum assignment method (at that hop) for the LSP. In addition, the node SHOULD report compliance by adding an RRO Hop Attributes subobject with the WSON Processing Hop Attribute TLV (and its sub-TLVs) that indicate the utilized method. Frequency-Slot Selection TLVs carried in an RRO Hop Attributes subobject are subject to [RFC7570] and standard RRO processing; see [RFC3209]. 4.2. Frequency-slot Restriction Constraint TLV For any request that contains a Frequency-slot assignment, the requester (PCC) MUST be able to specify a restriction on the frequency-slots to be used. This restriction is to be interpreted by the PCE as a constraint on the tuning ability of the origination laser transmitter or on any other maintenance related constraints. The format of the Frequency-Slot Restriction Constraint TLV is as follows: <Frequency-lot Restriction Constraint> ::= <Action> <Count> <Reserved> (<Link Identifiers> <Freq-slot Restriction>)... Where <Link Identifiers> ::= <Link Identifier> [<Link Identifiers>] See Section 4.3.1 in [PCEP-WSON] for the encoding of the Link Identifiers Field. Lee et al. Expires June 2019 [Page 8] Internet-Draft PCEP Extension for Flexible Grid February 2019 The Frequency slot Restriction Constraint TLV type is TBD. This TLV MAY appear more than once to be able to specify multiple restrictions. The TLV data is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Action | Count | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifiers | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frequency Slot Restriction Field | // . . . . // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 spectrum Restriction Constraint TLV Encoding o Action: 8 bits . 0 - Inclusive List indicates that one or more link identifiers are included in the Link Set. Each identifies a separate link that is part of the set. . 1 - Inclusive Range indicates that the Link Set defines a range of links. It contains two link identifiers. The first identifier indicates the start of the range (inclusive). The second identifier indicates the end of the range (inclusive). All links with numeric values between the bounds are considered to be part of the set. A value of zero in either position indicates that there is no bound on the corresponding portion of the range. Note that the Action field can be set to 0 when unnumbered link identifier is used. Lee et al. Expires June 2019 [Page 9] Internet-Draft PCEP Extension for Flexible Grid February 2019 o Count: The number of the link identifiers (8 bits) Note that a PCC MAY add a spectrum restriction that applies to all links by setting the Count field to zero and specifying just a set of spectrums. Note that all link identifiers in the same list must be of the same type. o Reserved: Reserved for future use (16 bits) o Link Identifiers: Identifies each link ID for which restriction is applied. The length is dependent on the link format and the Count field. See Section 4.3.1 in [PCEP-WSON] for Link Identifier encoding and Section 3.3.1 for the Spectrum Restriction Field encoding, respectively. 4.2.1. Frequency-Slot Restriction Field The Frequency-Slot Restriction Field of the Frequency slot restriction TLV is encoded as defined in https://tools.ietf.org/html/draft-ietf-ccamp-flexible-grid-ospf-ext- 09#section-4.1.1. 5. Encoding of a RSA Path Reply This section provides the encoding of a RSA Path Reply for frequency slot allocation as discussed in Section 4. Spectrum Allocation TLV The Spectrum Allocation TLV type is TBD, recommended value is TBD. The TLV data is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length |M| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Link Identifier | | . . . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Lee et al. Expires June 2019 [Page 10] Internet-Draft PCEP Extension for Flexible Grid February 2019 | Allocated Spectrum(s) | // . . . . // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 Spectrum Allocation TLV Encoding o Type (16 bits): The type of the TLV. o Length (15 bits): The length of the TLV including the Type and Length fields. o M (Mode): 1 bit - 0 indicates the allocation is under Explicit Label Control. - 1 indicates the allocation is expressed in Label Sets. Note that all link identifiers in the same list must be of the same type. o Link Identifier (variable): Identifies the interface to which assignment spectrum(s) is applied. See Section 3.3 for Link Identifier encoding. o Allocated Spectrum(s) (variable): Indicates the allocated spectrum(s) to the link identifier. See Section 3.3.1 for encoding details. This TLV is encoded as an attributes TLV, per [RFC5420], which is carried in the ERO LSP Attribute Subobjects per [RFC7570]. The type value of the Spectrum Restriction Constraint TLV is TBD by IANA. 5.1. Error Indicator To indicate errors associated with the RSA request, a new Error Type (TDB) and subsequent error-values are defined as follows for inclusion in the PCEP-ERROR Object: Lee et al. Expires June 2019 [Page 11] Internet-Draft PCEP Extension for Flexible Grid February 2019 A new Error-Type (TDB) and subsequent error-values are defined as follows: . Error-Type=TBD; Error-value=1: if a PCE receives a RSA request and the PCE is not capable of processing the request due to insufficient memory, the PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=TDB) and an Error-value(Error- value=1). The PCE stops processing the request. The corresponding RSA request MUST be cancelled at the PCC. . Error-Type=TBD; Error-value=2: if a PCE receives a RSA request and the PCE is not capable of RSA computation, the PCE MUST send a PCErr message with a PCEP-ERROR Object (Error-Type=TDB) and an Error-value (Error-value=2). The PCE stops processing the request. The corresponding RSA computation MUST be cancelled at the PCC. 5.2. NO-PATH Indicator To communicate the reason(s) for not being able to find RSA for the path request, the NO-PATH object can be used in the corresponding response. The format of the NO-PATH object body is defined in [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide additional information about why a path computation has failed. One new bit flag is defined to be carried in the Flags field in the NO-PATH-VECTOR TLV carried in the NO-PATH Object. . Bit TDB: When set, the PCE indicates no feasible route was found that meets all the constraints (e.g., spectrum restriction, etc.) associated with RSA. 6. Manageability Considerations Manageability of SSON Routing and Spectrum Assignment (RSA) with PCE must address the following considerations: Lee et al. Expires June 2019 [Page 12] Internet-Draft PCEP Extension for Flexible Grid February 2019 6.1. Control of Function and Policy In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuring the following PCEP session parameters on a PCC: . The ability to send a Flexi-Grid RSA request. In addition to the parameters already listed in Section 8.1 of [RFC5440], a PCEP implementation SHOULD allow configuring the following PCEP session parameters on a PCE: . The support for Flexi-Grid RSA . . A set of Flexi-Grid RSA specific policies (authorized sender, request rate limiter, etc). These parameters may be configured as default parameters for any PCEP session the PCEP speaker participates in, or may apply to a specific session with a given PCEP peer or a specific group of sessions with a specific group of PCEP peers. 6.2. Information and Data Models Extensions to the PCEP YANG module may include to cover the Flexi- Grid RSA information introduced in this document. Liveness Detection and Monitoring Mechanisms defined in this document do not imply any new liveness detection and monitoring requirements in addition to those already listed in section 8.3 of [RFC5440]. 6.3. Verifying Correct Operation Mechanisms defined in this document do not imply any new verification requirements in addition to those already listed in section 8.4 of [RFC5440] 6.4. Requirements on Other Protocols and Functional Components The PCE Discovery mechanisms ([RFC5089] and [RFC5088]) may be used to advertise Flexi-Grid RSA path computation capabilities to PCCs. Lee et al. Expires June 2019 [Page 13] Internet-Draft PCEP Extension for Flexible Grid February 2019 This draft has requirements on other protocols (ERO objects, etc. which are under TEAS or CCAMP.) 6.5. Impact on Network Operation Mechanisms defined in this document do not imply any new network operation requirements in addition to those already listed in section 8.6 of [RFC5440]. 7. Security Considerations This document has no requirement for a change to the security models within PCEP. However, the additional information distributed in order to address the RSA problem represents a disclosure of network capabilities that an operator may wish to keep private. Consideration should be given to securing this information. 8. IANA Considerations IANA maintains a registry of PCEP parameters. IANA has made allocations from the sub-registries as described in the following sections. 8.1. New PCEP Object As described in Section 4.1, a new PCEP Object is defined to carry frequency-slot assignment related constraints. IANA is to allocate the following from "PCEP Objects" sub-registry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-objects): Object Class Name Object Reference Value Type --------------------------------------------------------- TDB SA 1: Spectrum Assignment [This.I-D] Lee et al. Expires June 2019 [Page 14] Internet-Draft PCEP Extension for Flexible Grid February 2019 8.2. New PCEP TLV: Frequency Slot Selection TLV As described in Sections 4.2, a new PCEP TLV is defined to indicate spectrum selection constraints. IANA is to allocate this new TLV from the "PCEP TLV Type Indicators" subregistry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- indicators). Value Description Reference --------------------------------------------------------- TBD Spectrum Selection [This.I-D] 8.3. New PCEP TLV: Frequency Slot Restriction Constraint TLV As described in Section 4.3, a new PCEP TLV is defined to indicate wavelength restriction constraints. IANA is to allocate this new TLV from the "PCEP TLV Type Indicators" subregistry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- indicators). Value Description Reference --------------------------------------------------------- TBD Frequency Slot Restriction [This.I-D] Constraint 8.4. New PCEP TLV: Spectrum Allocation TLV As described in Section 5, a new PCEP TLV is defined to indicate the allocation of freq-slots(s) by the PCE in response to a request by the PCC. IANA is to allocate this new TLV from the "PCEP TLV Type Indicators" subregistry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-tlv-type- indicators). Value Description Reference --------------------------------------------------------- TBD Spectrum Allocation [This.I-D] Lee et al. Expires June 2019 [Page 15] Internet-Draft PCEP Extension for Flexible Grid February 2019 8.5. New No-Path Reasons As described in Section 4.3, a new bit flag are defined to be carried in the Flags field in the NO-PATH-VECTOR TLV carried in the NO-PATH Object. This flag, when set, indicates that no feasible route was found that meets all the RSA constraints (e.g., spectrum restriction, signal compatibility, etc.) associated with a RSA path computation request. IANA is to allocate this new bit flag from the "PCEP NO-PATH-VECTOR TLV Flag Field" subregistry (http://www.iana.org/assignments/pcep/pcep.xhtml#no-path-vector- tlv). Bit Description Reference ----------------------------------------------------- TBD No RSA constraints met [This.I-D] 8.6. New Error-Types and Error-Values As described in Section 5.1, new PCEP error codes are defined for WSON RWA errors. IANA is to allocate from the ""PCEP-ERROR Object Error Types and Values" sub-registry (http://www.iana.org/assignments/pcep/pcep.xhtml#pcep-error-object). Error- Meaning Error-Value Reference Type --------------------------------------------------------------- TDB Flexi-Grid RSA Error 1: Insufficient [This.I-D] Memory 2: RSA computation [This.I-D] Not supported Lee et al. Expires June 2019 [Page 16] Internet-Draft PCEP Extension for Flexible Grid February 2019 9. References 9.1. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2863] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000. [RFC4003] Berger, L., "GMPLS Signaling Procedure for Egress Control", RFC 4003, February 2005. [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, August 2006. [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) Communication Protocol Generic Requirements", RFC 4657, September 2006. [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation Element (PCE) communication Protocol", RFC 5440, March 2009. [RFC5088] Le Roux, JL, JP. Vasseur, Y. Ikejiri, and R. Zhang, "OSPF Protocol Extensions for Path Computation Element (PCE) Discovery," RFC 5088, January 2008. [RFC5089] Le Roux, JL, JP. Vasseur, Y. Ikejiri, and R. Zhang, "IS-IS Protocol Extensions for Path Computation Element (PCE) Discovery," RFC 5089, January 2008. [RFC6163] Lee, Y. and Bernstein, G. (Editors), and W. Imajuku, "Framework for GMPLS and PCE Control of Wavelength Switched Optical Networks", RFC 6163, March 2011. [RFC6566] Y. Lee, G. Bernstein, D. Li, G. Martinelli, "A Framework for the Control of Wavelength Switched Optical Networks (WSON) with Impairments", RFC 6566, March 2012. [RFC7420] Koushik, A., E. Stephan, Q. Zhao, D. King, and J. Hardwick, "Path Computation Element Communication Protocol (PCEP) Management Information Base (MIB) Module", RFC 7420, December 2014. Lee et al. Expires June 2019 [Page 17] Internet-Draft PCEP Extension for Flexible Grid February 2019 [RFC7446] Y. Lee, G. Bernstein. (Editors), "Routing and Wavelength Assignment Information Model for Wavelength Switched Optical Networks", RFC 7446, February 2015. [RFC7449] Lee, Y., et. al., "PCEP Requirements for WSON Routing and Wavelength Assignment", RFC 7449, February 2015. 9.2. Normative References [PCEP-GMPLS] Margaria, et al., "PCEP extensions for GMPLS", draft- ietf-pce-gmpls-pcep-extensions, work in progress. [RFC5420] Farrel, A. "Encoding of Attributes for MPLS LSP Establishment Using Resource Reservation Protocol Traffic Engineering (RSVP-TE)", RFC5420, February 2009. [RFC5521] Oki, E, T. Takeda, and A. Farrel, "Extensions to the Path Computation Element Communication Protocol (PCEP) for Route Exclusions", RFC 5521, April 2009. [RFC6205] Tomohiro, O. and D. Li, "Generalized Labels for Lambda- Switching Capable Label Switching Routers", RFC 6205, January, 2011. [RFC7570] Margaria, et al., "Label Switched Path (LSP) Attribute in the Explicit Route Object (ERO)", RFC 7570, July 2015. [RFC7689] Bernstein et al, "Signaling Extensions for Wavelength Switched Optical Networks", RFC 7689, November 2015. [RFC7688] Y. Lee, and G. Bernstein, "OSPF Enhancement for Signal and Network Element Compatibility for Wavelength Switched Optical Networks", RFC 7688, November 2015. [RFC7698] O. Gonzalez de Dios, R. Casellas, editors, "Framework and Requirements for GMPLS-Based Control of Flexi-Grid Dense Wavelength Division Multiplexing (DWDM) Networks", RFC 7698, November 2015. [RFC7581] Bernstein and Lee, "Routing and Wavelength Assignment Information Encoding for Wavelength Switched Optical Networks", RFC7581, June 2015. Lee et al. Expires June 2019 [Page 18] Internet-Draft PCEP Extension for Flexible Grid February 2019 [RFC7579] Bernstein and Lee, "General Network Element Constraint Encoding for GMPLS Controlled Networks", RFC 7579, June 2015. [PCEP-WSON] Y. Lee (Ed.), and R. Casellas (Ed.), "PCEP Extension for WSON Routing and Wavelength Assignment", draft-ietf-pce- wson-rwa-ext, work in progress. 10. Contributors Lee et al. Expires June 2019 [Page 19] Internet-Draft PCEP Extension for Flexible Grid February 2019 Authors' Addresses Young Lee, Editor Huawei Technologies Email: leeyoung@huawei.com Haomian Zheng Huawei Technologies Email: zhenghaomian@huawei.com Ramon Casellas CTTC Av. Carl Friedrich Gauss n7 Castelldefels, Barcelona 08860 Spain Email: ramon.casellas@cttc.es Ricard Vilalta CTTC Email: ricard.vilalta@cttc.es Daniele Ceccarelli Ericsson AB Gronlandsgatan 21 Kista - Stockholm Email: daniele.ceccarelli@ericsson.com Francesco Lazzeri Ericsson Via Melen 77 Genova - Italy Email: francesco.lazzeri@ericsson.com Lee et al. Expires June 2019 [Page 20]