Network Working Group C. Margaria. C, Ed. Internet-Draft E. Sfeir. E Intended status: Standards Track F. Rambach. F Expires: June 30, 2010 Nokia Siemens Networks O. Gonzalez de Dios. O F. Jimenez Chico. F.J. Telefonica Investigacion y Desarrollo December 27, 2009 PCEP extensions for GMPLS draft-margaria-pce-gmpls-pcep-extensions-00 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 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. This Internet-Draft will expire on June 30, 2010. Copyright Notice Copyright (c) 2009 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 Margaria. C, et al. Expires June 30, 2010 [Page 1] Internet-Draft PCEP Ext for GMPLS December 2009 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 BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Margaria. C, et al. Expires June 30, 2010 [Page 2] Internet-Draft PCEP Ext for GMPLS December 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. PCEP requirements . . . . . . . . . . . . . . . . . . . . 3 1.2. PCEP existing objects related to GMPLS . . . . . . . . . . 4 1.3. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. PCEP objects and extensions . . . . . . . . . . . . . . . . . 5 2.1. Traffic parameters encoding, GENERALIZED-BANDWIDTH . . . . 6 2.2. Endpoints encoding . . . . . . . . . . . . . . . . . . . . 8 2.3. LABEL SET object . . . . . . . . . . . . . . . . . . . . . 10 2.4. LSPA extensions . . . . . . . . . . . . . . . . . . . . . 11 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 4. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.1. Normative References . . . . . . . . . . . . . . . . . . . 11 5.2. Informative References . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Margaria. C, et al. Expires June 30, 2010 [Page 3] Internet-Draft PCEP Ext for GMPLS December 2009 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 documents 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 is described in [I-D.ietf-pce-gmpls-aps-req] and [I-D.ietf-pce-wson-routing-wavelength]. 1.1. PCEP requirements This section provides a set of PCEP requirements to support signal compatibility constraints. 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. (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] Margaria. C, et al. Expires June 30, 2010 [Page 4] Internet-Draft PCEP Ext for GMPLS December 2009 (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] We describe in this document a proposal to fulfill those requirements. 1.2. 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]: 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: Margaria. C, et al. Expires June 30, 2010 [Page 5] Internet-Draft PCEP Ext for GMPLS December 2009 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-unnumbered), 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.3. 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. 2. PCEP objects and extensions This section describes the required PCEP objects and extensions. The PCReq/PCRep message is defined in [RFC5440], with extensions (GENERALIZED BANDWIDTH and LABEL Set) Margaria. C, et al. Expires June 30, 2010 [Page 6] Internet-Draft PCEP Ext for GMPLS December 2009 ::= [] [] [][] [] [[] [][< GENERALIZED-BANDWIDTH>] ] [] [