idnits 2.17.1 draft-margaria-pce-gmpls-pcep-extensions-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 01, 2010) is 5047 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 909, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-ccamp-gmpls-g-694-lambda-labels-07 == Outdated reference: A later version (-09) exists of draft-ietf-pce-gmpls-aps-req-01 == Outdated reference: A later version (-12) exists of draft-ietf-pce-inter-layer-ext-03 == Outdated reference: A later version (-15) exists of draft-ietf-pce-wson-routing-wavelength-01 -- Obsolete informational reference (is this intentional?): RFC 5467 (Obsoleted by RFC 6387) Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Margaria. C, Ed. 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track O. Gonzalez de Dios. O, Ed. 5 Expires: January 2, 2011 Telefonica Investigacion y 6 Desarrollo 7 F. Zhang. F, Ed. 8 Huawei Technologies 9 July 01, 2010 11 PCEP extensions for GMPLS 12 draft-margaria-pce-gmpls-pcep-extensions-01 14 Abstract 16 This memo provides extensions for the Path Computation Element 17 communication Protocol (PCEP) for the support of GMPLS control plane. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 2, 2011. 36 Copyright Notice 38 Copyright (c) 2010 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1. Contributing Authors . . . . . . . . . . . . . . . . . . . 3 55 1.2. PCEP requirements for GMPLS . . . . . . . . . . . . . . . 3 56 1.3. PCEP existing objects related to GMPLS . . . . . . . . . . 4 57 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5 58 2. PCEP objects and extensions . . . . . . . . . . . . . . . . . 6 59 2.1. Traffic parameters encoding, GENERALIZED-BANDWIDTH . . . . 7 60 2.2. END-POINTS Object extensions . . . . . . . . . . . . . . . 8 61 2.2.1. Generalized endpoint Object Type . . . . . . . . . . . 9 62 2.2.2. END-POINTS TLVs extensions . . . . . . . . . . . . . . 11 63 2.3. LABEL SET object . . . . . . . . . . . . . . . . . . . . . 13 64 2.4. SUGGESTED LABEL SET object . . . . . . . . . . . . . . . . 14 65 2.5. LSPA extensions . . . . . . . . . . . . . . . . . . . . . 14 66 2.6. NO-PATH Object Extension . . . . . . . . . . . . . . . . . 15 67 2.6.1. Extensions to NO-PATH-VECTOR TLV . . . . . . . . . . . 15 68 3. Additional Error Type and Error Values Defined . . . . . . . . 16 69 4. Manageability Considerations . . . . . . . . . . . . . . . . . 18 70 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 71 5.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . . 19 72 5.2. New PCEP TLVs . . . . . . . . . . . . . . . . . . . . . . 19 73 5.3. New PCEP Error Codes . . . . . . . . . . . . . . . . . . . 20 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 22 75 7. Contributing Authors . . . . . . . . . . . . . . . . . . . . . 23 76 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 77 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 78 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 79 9.2. Informative References . . . . . . . . . . . . . . . . . . 27 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 82 1. Introduction 84 PCEP RFCs [RFC5440], [RFC5521], [RFC5541], [RFC5520] are focused on 85 path computation requests in MPLS networks. [RFC4655] defines the 86 PCE framework also for GMPLS networks. This document complements 87 these RFCs by providing some consideration of GMPLS applications and 88 routing requests, for example for OTN and WSON networks. 90 The requirements on PCE extensions to support those characteristics 91 are described in [I-D.ietf-pce-gmpls-aps-req] and 92 [I-D.ietf-pce-wson-routing-wavelength]. 94 1.1. Contributing Authors 96 Elie Sfeir, Franz Rambach (Nokia Siemens Networks) Francisco Javier 97 Jimenez Chico (Telefonica Investigacion y Desarrollo) Suresh BR, 98 Young Lee, SenthilKumar S, Jun Sun (Huawei Technologies), Ramon 99 Casellas (CTTC) 101 1.2. PCEP requirements for GMPLS 103 This section provides a set of PCEP requirements to support GMPLS 104 LSPs and assure signal compatibility in the path. When requesting a 105 path computation (PCReq) to PCE, the PCC should be able to indicate, 106 according to [I-D.ietf-pce-gmpls-aps-req], the following additional 107 attributes: 109 (1) Switching capability: PSC1-4, L2SC, TDM, LSC, FSC 111 (2) Encoding type: as defined in [RFC4202], [RFC4203], e.g., 112 Ethernet, SONET/SDH, Lambda, etc. 114 (3) Signal Type: Indicates the type of elementary signal that 115 constitutes the requested LSP. A lot of signal types with 116 different granularity have been defined in SONET/SDH and G.709 117 ODUk, such as VC11, VC12, VC2, VC3 and VC4 in SDH, and ODU1, ODU2 118 and ODU3 in G.709 ODUk [RFC4606] and [RFC4328]. 120 (4) Concatenation Type: In SDH/SONET and G.709 ODUk networks, two 121 kinds of concatenation modes are defined: contiguous concatenation 122 which requires co-route for each member signal and requires all 123 the interfaces along the path to support this capability, and 124 virtual concatenation which allows diverse routes for the member 125 signals and only requires the ingress and egress interfaces to 126 support this capability. Note that for the virtual concatenation, 127 it also may specify co-routed or separated-routed. See [RFC4606] 128 and [RFC4328] about concatenation information. 130 (5) Concatenation Number: Indicates the number of signals that are 131 requested to be contiguously or virtually concatenated. Also see 132 [RFC4606] and [RFC4328]. 134 (6) Wavelength Label: as defined in 135 [I-D.ietf-ccamp-gmpls-g-694-lambda-labels] 137 (7) e2e Path protection type: as defined in [RFC4872], e.g., 1+1 138 protection, 1:1 protection, (pre-planned) rerouting, etc. 140 (8) Link Protection type: as defined in [RFC4203] 142 (9) Support for unnumbered interfaces: as defined in [RFC3477] 144 (10) Support for asymmetric bandwidth request 146 We describe in this document a proposal to fulfill those 147 requirements. 149 1.3. PCEP existing objects related to GMPLS 151 PCEP as of [RFC5440], [RFC5521] and [I-D.ietf-pce-inter-layer-ext], 152 supports the following information (in the PCReq and PCRep) related 153 to the described RSVP-TE information. 155 From [RFC5440]: 157 o numbered endpoints 159 o bandwidth (float) 161 o ERO 163 o LSP attribute (setup and holding priorities) 165 o Request attribute (include some LSP attributes) 167 From [RFC5521]: 169 o Extensions to PCEP for Route Exclusions define a XRO object and a 170 new semantic (F bit): Fail bit indicating that the existing route 171 is failed and resources present in the RRO can be reused. This 172 object also allows to exclude (strict or not) resources; XRO 173 include the diversity level (node, link, SRLG). The requested 174 diversity is expressed in the XRO. 176 From [I-D.ietf-pce-inter-layer-ext]: 178 o INTER-LAYER : indicates if inter-layer computation is allowed 180 o SWITCH-LAYER : indicates which layer(s) should be considered, can 181 be used to represent the RSVP-TE generalized label request 183 o REQ-ADAP-CAP : indicates the adaptation capabilities requested, 184 can also be used for the endpoints in case of mono-layer 185 computation 187 The shortcomings of the existing PCEP information are: 189 BANDWIDTH does not describe the details of the signal (for example 190 NVC, multiplier) in the context of TDM or OTN networks. 192 END-POINTS does not allow specifying an unnumbered interface, nor 193 the labels on the interface. Those parameters are of interest in 194 case of switching constraints. 196 Current attributes do not allow to express the requested link level 197 protection and end-to-end protection attributes. 199 In order to improve the PCEP, a new object is introduced 200 (GENERALIZED-BANDWIDTH) , a new object type is introduced for the 201 END-POINTS object (generalized-endpoint), and a TLV is added to the 202 LSPA object. In order to allow to restrict the range of labels 203 returned, an additional object is added : LABEL SET 205 1.4. Requirements Language 207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 208 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 209 document are to be interpreted as described in RFC 2119. 211 2. PCEP objects and extensions 213 This section describes the required PCEP objects and extensions. The 214 PCReq and PCRep messages are defined in [RFC5440]. The format of the 215 request and response messages with the proposed extensions 216 (GENERALIZED BANDWIDTH, SUGGESTED LABEL SET and LABEL Set) is as 217 follows: 219 ::= 220 221 [] 222 [] 223 [][] 224 [] 225 [] 226 [] 227 [