Network Working Group C. Margaria. C, Ed. Internet-Draft Nokia Siemens Networks Intended status: Standards Track O. Gonzalez de Dios. O, Ed. Expires: January 2, 2011 Telefonica Investigacion y Desarrollo F. Zhang. F, Ed. Huawei Technologies July 01, 2010 PCEP extensions for GMPLS draft-margaria-pce-gmpls-pcep-extensions-01 Abstract This memo provides extensions for the Path Computation Element communication Protocol (PCEP) for the support of GMPLS control plane. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 2, 2011. Copyright Notice Copyright (c) 2010 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 Margaria. C, et al. Expires January 2, 2011 [Page 1] Internet-Draft PCEP Ext for GMPLS July 2010 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3 1.2. PCEP requirements for GMPLS . . . . . . . . . . . . . . . 3 1.3. PCEP existing objects related to GMPLS . . . . . . . . . . 4 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. PCEP objects and extensions . . . . . . . . . . . . . . . . . 6 2.1. Traffic parameters encoding, GENERALIZED-BANDWIDTH . . . . 7 2.2. END-POINTS Object extensions . . . . . . . . . . . . . . . 8 2.2.1. Generalized endpoint Object Type . . . . . . . . . . . 9 2.2.2. END-POINTS TLVs extensions . . . . . . . . . . . . . . 11 2.3. LABEL SET object . . . . . . . . . . . . . . . . . . . . . 13 2.4. SUGGESTED LABEL SET object . . . . . . . . . . . . . . . . 14 2.5. LSPA extensions . . . . . . . . . . . . . . . . . . . . . 14 2.6. NO-PATH Object Extension . . . . . . . . . . . . . . . . . 15 2.6.1. Extensions to NO-PATH-VECTOR TLV . . . . . . . . . . . 15 3. Additional Error Type and Error Values Defined . . . . . . . . 16 4. Manageability Considerations . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 19 5.2. New PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . 19 5.3. New PCEP Error Codes . . . . . . . . . . . . . . . . . . . 20 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 23 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Margaria. C, et al. Expires January 2, 2011 [Page 2] Internet-Draft PCEP Ext for GMPLS July 2010 1. Introduction PCEP RFCs [RFC5440], [RFC5521], [RFC5541], [RFC5520] are focused on path computation requests in MPLS networks. [RFC4655] defines the PCE framework also for GMPLS networks. This document complements these RFCs by providing some consideration of GMPLS applications and routing requests, for example for OTN and WSON networks. The requirements on PCE extensions to support those characteristics are described in [I-D.ietf-pce-gmpls-aps-req] and [I-D.ietf-pce-wson-routing-wavelength]. 1.1. Contributing Authors Elie Sfeir, Franz Rambach (Nokia Siemens Networks) Francisco Javier Jimenez Chico (Telefonica Investigacion y Desarrollo) Suresh BR, Young Lee, SenthilKumar S, Jun Sun (Huawei Technologies), Ramon Casellas (CTTC) 1.2. PCEP requirements for GMPLS This section provides a set of PCEP requirements to support GMPLS LSPs and assure signal compatibility in the path. When requesting a path computation (PCReq) to PCE, the PCC should be able to indicate, according to [I-D.ietf-pce-gmpls-aps-req], the following additional attributes: (1) Switching capability: PSC1-4, L2SC, TDM, LSC, FSC (2) Encoding type: as defined in [RFC4202], [RFC4203], e.g., Ethernet, SONET/SDH, Lambda, etc. (3) Signal Type: Indicates the type of elementary signal that constitutes the requested LSP. A lot of signal types with different granularity have been defined in SONET/SDH and G.709 ODUk, such as VC11, VC12, VC2, VC3 and VC4 in SDH, and ODU1, ODU2 and ODU3 in G.709 ODUk [RFC4606] and [RFC4328]. (4) Concatenation Type: In SDH/SONET and G.709 ODUk networks, two kinds of concatenation modes are defined: contiguous concatenation which requires co-route for each member signal and requires all the interfaces along the path to support this capability, and virtual concatenation which allows diverse routes for the member signals and only requires the ingress and egress interfaces to support this capability. Note that for the virtual concatenation, it also may specify co-routed or separated-routed. See [RFC4606] and [RFC4328] about concatenation information. Margaria. C, et al. Expires January 2, 2011 [Page 3] Internet-Draft PCEP Ext for GMPLS July 2010 (5) Concatenation Number: Indicates the number of signals that are requested to be contiguously or virtually concatenated. Also see [RFC4606] and [RFC4328]. (6) Wavelength Label: as defined in [I-D.ietf-ccamp-gmpls-g-694-lambda-labels] (7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1 protection, 1:1 protection, (pre-planned) rerouting, etc. (8) Link Protection type: as defined in [RFC4203] (9) Support for unnumbered interfaces: as defined in [RFC3477] (10) Support for asymmetric bandwidth request We describe in this document a proposal to fulfill those requirements. 1.3. PCEP existing objects related to GMPLS PCEP as of [RFC5440], [RFC5521] and [I-D.ietf-pce-inter-layer-ext], supports the following information (in the PCReq and PCRep) related to the described RSVP-TE information. From [RFC5440]: o numbered endpoints o bandwidth (float) o ERO o LSP attribute (setup and holding priorities) o Request attribute (include some LSP attributes) From [RFC5521]: o Extensions to PCEP for Route Exclusions define a XRO object and a new semantic (F bit): Fail bit indicating that the existing route is failed and resources present in the RRO can be reused. This object also allows to exclude (strict or not) resources; XRO include the diversity level (node, link, SRLG). The requested diversity is expressed in the XRO. From [I-D.ietf-pce-inter-layer-ext]: Margaria. C, et al. Expires January 2, 2011 [Page 4] Internet-Draft PCEP Ext for GMPLS July 2010 o INTER-LAYER : indicates if inter-layer computation is allowed o SWITCH-LAYER : indicates which layer(s) should be considered, can be used to represent the RSVP-TE generalized label request o REQ-ADAP-CAP : indicates the adaptation capabilities requested, can also be used for the endpoints in case of mono-layer computation The shortcomings of the existing PCEP information are: BANDWIDTH does not describe the details of the signal (for example NVC, multiplier) in the context of TDM or OTN networks. END-POINTS does not allow specifying an unnumbered interface, nor the labels on the interface. Those parameters are of interest in case of switching constraints. Current attributes do not allow to express the requested link level protection and end-to-end protection attributes. In order to improve the PCEP, a new object is introduced (GENERALIZED-BANDWIDTH) , a new object type is introduced for the END-POINTS object (generalized-endpoint), and a TLV is added to the LSPA object. In order to allow to restrict the range of labels returned, an additional object is added : LABEL SET 1.4. 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 RFC 2119. Margaria. C, et al. Expires January 2, 2011 [Page 5] Internet-Draft PCEP Ext for GMPLS July 2010 2. PCEP objects and extensions This section describes the required PCEP objects and extensions. The PCReq and PCRep messages are defined in [RFC5440]. The format of the request and response messages with the proposed extensions (GENERALIZED BANDWIDTH, SUGGESTED LABEL SET and LABEL Set) is as follows: ::= [] [] [][] [] [] [] [