idnits 2.17.00 (12 Aug 2021) /tmp/idnits30297/draft-zhang-pce-pcep-extensions-for-sdh-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 : ---------------------------------------------------------------------------- ** There are 7 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([GMPLS-REQ]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 4, 2010) is 4513 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: 'RFC3209' is defined on line 880, but no explicit reference was found in the text == Unused Reference: 'RFC3473' is defined on line 883, but no explicit reference was found in the text == Unused Reference: 'RFC3477' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'RFC4090' is defined on line 891, but no explicit reference was found in the text == Unused Reference: 'RFC5226' is defined on line 894, but no explicit reference was found in the text == Unused Reference: 'RFC4606' is defined on line 899, but no explicit reference was found in the text == Unused Reference: 'RFC4655' is defined on line 904, but no explicit reference was found in the text == Unused Reference: 'RFC4657' is defined on line 907, but no explicit reference was found in the text == Unused Reference: 'RFC4674' is defined on line 911, but no explicit reference was found in the text == Unused Reference: 'RFC5088' is defined on line 914, but no explicit reference was found in the text == Unused Reference: 'RFC5440' is defined on line 917, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'GMPLS-REQ' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 4 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Fatai Zhang 2 Internet Draft Suresh B R 3 Category: Standards Track SenthilKumarS 4 Jun Sun 5 Huawei 6 Expires: July 3, 2010 January 4, 2010 8 Extensions to the Path Computation Element Communication Protocol for 9 Traffic Engineering Label Switched Paths in SDH Networks 11 draft-zhang-pce-pcep-extensions-for-sdh-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on July 3, 2010. 36 Abstract 38 [GMPLS-REQ] describes functional requirements for Generalized Multi- 39 Protocol Label Switching (GMPLS) application of Path Computation 40 Element (PCE). This document explains the application-specific 41 extensions for the Path Computation Element Communication Protocol 42 (PCEP) to support SDH. PCEP is the communication protocol defined by 43 IETF in RFC5440. 45 Conventions used in this document 47 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 48 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 49 document are to be interpreted as described in [RFC2119]. 51 Table of Contents 53 1. Introduction.................................................2 54 1.1. Requirements Language...................................3 55 2. Terminology..................................................3 56 3. Requirements.................................................3 57 4. Protocol Procedure and Extensions............................4 58 4.1. RP Object Extension.....................................4 59 4.1.1. Requested GMPLS Label Information..................5 60 4.2. No-PATH Object Extension................................6 61 4.2.1. Extensions to NO-PATH-VECTOR TLV...................6 62 4.3. END-POINTS Object Extension.............................7 63 4.3.1. Destination Prefix Information TLV.................7 64 4.4. New Object - QoS........................................8 65 4.4.1. SDH-ASON QoS Parameters TLV........................9 66 4.4.2. LSP Protection Information TLV....................13 67 4.4.3. QoS Object in PCReq and PCRep.....................15 68 4.5. Additional Error Type and Error Values Defined.........16 69 5. Manageability Considerations................................17 70 6. IANA Considerations.........................................17 71 6.1. New PCEP Object........................................17 72 6.2. New PCEP TLVs..........................................18 73 6.3. PCEP RP Object Flag Field..............................18 74 6.4. PCEP NO-PATH-VECTOR TLV Flag Field.....................18 75 6.5. New PCEP Error Codes...................................19 76 7. Security Considerations.....................................19 77 8. References..................................................20 78 8.1. Normative References...................................20 79 8.2. Informative References.................................20 80 9. Authors' Addresses..........................................21 82 1. Introduction 84 RFC4655 defines the PCE based architecture and explains how a PCE may 85 compute LSPs in MPLS Traffic Engineering (TE) and GMPLS) networks at 86 the request of Path Computation Clients (PCCs). 88 RFC5440 specifies the PCEP for communication between a PCC and a PCE, 89 or between two PCEs, in compliance with RFC4657. However, that 90 specification does not provide a mechanism to request path 91 computation for establishing TE LSPs in SDH network. [GMPLS-REQ] 92 addresses the functional requirements for GMPLS in PCE application. 94 This document describes the protocol extensions to PCEP to support 95 path computation for SDH networks. 97 1.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC2119. 103 2. Terminology 105 The following terminology is used in this document. 107 PCC: Path Computation Client. Any client application requesting a 108 path computation to be performed by the Path Computation Element. 110 PCE: Path Computation Element. An entity (component, application, or 111 network node) that is capable of computing a network path or 112 route based on a network graph and applying computational 113 constraints. 115 PCEP: Path Computation Element Communication Protocol. PCEP is a 116 request/response protocol used for the communication between a 117 PCC and a PCE, or between two PCEs. 119 PCEP Peer: An element involved in a PCEP session (For example, a PCC 120 or a PCE). 122 PCEP Session: The PCEP session is a logical connection established 123 automatically between the PCEP peers. 125 This document also uses the terminology defined in RFC4655, and 126 RFC5440. 128 3. Requirements 130 This section summarizes the PCEP extensions for GMPLS requirements 131 specific to SDH networks. This document introduces no new messages 132 for PCEP. However, extensions have been introduced to the existing 133 PCEP objects, sub-objects and TLVs. Also, few new objects and TLVs 134 have been introduced to support SDH. The details on the PCEP objects 135 and TLVs are mentioned below: 137 Enhanced Objects 139 o PCEP RP Object 140 o PCEP End Point (IPv4/Node ID) Object 142 Newly Introduced Object 144 o PCEP QoS Object 146 Newly Introduced TLVs 148 o Requested GMPLS Label 149 o Destination Prefix Information 150 o SONET/SDH QoS Parameters 151 o LSP Protection Information 153 4. Protocol Procedure and Extensions 155 4.1. RP Object Extension 157 The PCE architecture can be extended to support various network types 158 such as SDH, WDM, OTN, PTN and so on. The application-specific PCEP 159 requirements and protocol enhancements varies from network to network. 160 PCE MAY select the appropriate policy profile depending on the 161 current path request which is applicable to a particular network type. 163 The PCC can specify its network type in the RP object of the PCEP 164 protocol. The RP (Request Parameters) object MUST be carried within 165 each PCReq and PCRep messages and MAY be carried within PCNtf and 166 PCErr messages. The RP object can handle the requests and responses 167 of various network types for the computation of TE LSPs. 169 The RP object can also specify the next hop information. The simple 170 routing implementation can perform route look-up using the 171 destination IP address ignoring the additional information contained 172 in the request. More sophisticated routing implementations can use 173 additional information contained in the request to influence route 174 selection. This additional information includes resource class, input 175 network interface, traffic and service parameters. 177 The modified RP object carrying the additional information is as 178 follows: 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Object Class | OT |Res|P|I| Object Length | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | NT | Flags |O|B|R| Pri | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Request-ID-number | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | | 190 // Optional TLVs // 191 | | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 NT - Network Type (3-bits). This field denotes the network type. 196 Bit NT Type 198 000 DC: Data Communication Networks (default) 200 001 SDH: Synchronous Digital Hierarchy Network 202 010 WDM: Wavelength Division Multiplexing Network 204 011 OTN: Optical Transport Network 206 100 PTN: Packet Transport Network 208 111 Multi-layered path request 210 The RP object carrying bits ranging from 101 to 110 in the NT flag 211 must be ignored. In future these bits can be used to represent new 212 network types. 214 4.1.1. Requested GMPLS Label Information 216 The Requested GMPLS Label Information TLV is a new OPTIONAL TLV and 217 MUST only appear inside RP object. The receiver SHOULD ignore the TLV 218 if it appears in any other object other than RP object. This TLV will 219 appear only when the resources required are requested using 220 generalized label. If multiple instance of this TLV is present, the 221 receiver SHOULD accept the first instance and SHOULD ignore the rest. 223 The format of Requested GMPLS Label Information TLV is as follows: 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | Type = 13 | Length | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Encoding | Switching | Carried | 231 | Type | Type | Payload ID | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 Type (16-bits) - Specifies the type of the TLV (Value = 13). 236 Length (16-bits) - Specifies the length of the value field (Value = 237 4). 239 Encoding Type (8-bits) - Specifies the encoding type of the LSP being 240 requested. 242 The details of Encoding type is discussed in RFC 3471. 244 Switching Type (8-bits) - Specifies the switching type requested by 245 the LSP. 247 The details of Switching type is discussed in RFC 3471. 249 Carried Payload ID (16-bits) - Specifies the ID of the payload 250 carried by the LSP. 252 4.2. No-PATH Object Extension 254 The NO-PATH object is used in PCRep messages in response to an 255 unsuccessful path computation request (the PCE could not find a path 256 by satisfying the set of constraints). In this scenario, PCE MUST 257 include a NO-PATH object in the PCRep message. 259 The N0-PATH object carries the NO-PATH-VECTOR TLV that specifies more 260 information on the reasons that led to a negative reply. In case of 261 SDH networks there could be some more additional constraints that led 262 to the failure like protection mismatch, lack of resources, and so on. 263 Few new flags have been introduced in 32-bit flag field of the NO- 264 PATH-VECTOR TLV and no modifications have been made in the NO-PATH 265 object. 267 4.2.1. Extensions to NO-PATH-VECTOR TLV 269 The modified NO-PATH-VECTOR TLV carrying the additional information 270 is as follows: 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type = 1 | Length = 4 | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | Flags |N|P|U|U|N| 278 | Field |R|M|S|D|P| 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 New fields PM and NR are defined in the 28th and 27th bit of the 282 Flags field respectively. 284 PM - Protection Mismatch (1-bit). Specifies the mismatch of the 285 protection type in the request. 287 NR - No Resource (1-bit). Specifies that the resources are not 289 currently sufficient to provide the path. 291 4.3. END-POINTS Object Extension 293 The END-POINTS object is used in a PCReq message to specify the 294 source IP address and the destination IP address of the path for 295 which a path computation is requested. New OPTIONAL TLVs are defined 296 that are to be carried in the END-POINTS object for the path that 297 depends on the previous hop address, destination prefix, and 298 additional interface information. 300 4.3.1. Destination Prefix Information TLV 302 The Destination Prefix Information TLV is a new OPTIONAL TLV. It MUST 303 only appear inside END-POINTS (IPv4/Node ID) object. The receiver 304 SHOULD ignore the Destination Prefix Information TLV if it appears in 305 any other object other than END-POINTS object. This TLV contains the 306 prefix length for the destination IPv4 address and will appear when 307 prefix length is in the range between 0 and 32 (inclusive). 309 The format of the Destination Prefix Information TLV is as follows: 311 0 1 2 3 312 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 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | Type = 20 | Length = 4 | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | Destination | Flags |E| Reserved | 317 | Prefix Length | Field |M| | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 Destination Prefix Length (8-bits) - Specifies the prefix length of 320 the destination IPv4 address. 322 Flags Field (7-bits) - Reserved for future to define new flags. It 323 MUST be filled with zeros and SHOULD be ignored by the receiver. 325 EM- Exact Prefix Match (1-bit) - Specifies whether exact prefix match 326 is required for the destination IPv4 address. 328 Bit EM Type 330 0 Exact prefix match is not required 332 1 Exact prefix match is required 334 Reserved (16-bits) - Reserved. MUST be set to zero and SHOULD be 335 ignored by the receiver. 337 4.4. New Object - QoS 339 When a PCC requests a PCE for a route, and if PCE provides the 340 response to the request, it MAY be useful for the PCC and the PCE to 341 include the traffic parameters. These traffic parameters specify a 342 base set of capabilities for SDH networks such as Service Level 343 Agreement (SLA), protection scheme, segment recovery, concatenation, 344 transparency, and so on. The QoS object handles the quality of 345 service parameters for TE-LSPs in SDH networks. 347 The QoS object can be included in the PCReq and PCRep messages by the 348 PCC and PCE respectively. It represents the parameters that become 349 necessary to manage bandwidth in the networks. When a PCE cannot find 350 a path by satisfying a set of constraints requested by the PCC, the 351 PCE may also include the original constraint so as to indicate the 352 reason for an unsuccessful computation in the NO-PATH object. Based 353 on the available service parameters proposed by a PCE, the PCC MAY 354 decide to resend the path requests. These parameters ensure that the 355 applications are guaranteed the network resources they need, despite 356 varying traffic load. 358 The format of the QoS object is as follows: 360 0 1 2 3 361 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 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Object Class | OT |Res|P|I| Object Length | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | | 366 // SDH-ASON QoS // 367 | Parameters TLV | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 // LSP Protection Information // 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 Object Class (8-bits) - Specifies the class of the object (Value = 373 25). 375 OT - Object Type (4-bits) - Specifies the type of the object (Value = 376 1). 378 Object Length (16-bits) - Specifies the length of the object (Value = 379 16). 381 Res - Reserved (2-bits). It MUST be set to zero on transmission and 382 MUST be ignored on receipt. 384 P - Processing Rule (1-bit). The P flag allows a PCC to specify in a 385 PCReq message sent to a PCE whether the object must be taken into 386 account by the PCE during path computation or is just optional. When 387 the P flag is set, the object MUST be taken into account by the PCE. 388 Conversely, when the P flag is cleared, the object is optional and 389 the PCE can ignore it. 391 I - Ignore (1-bit). The I flag is used by a PCE in a PCRep message to 392 indicate to a PCC whether an optional object is processed or not. The 393 PCE MAY include the ignored optional object in its reply and set the 394 I flag to indicate that the optional object was ignored during path 395 computation. When the I flag is cleared, the PCE indicates that the 396 optional object was processed during the path computation. The 397 setting of the I flag for optional objects are purely indicative and 398 optional. The I flag has no meaning in a PCRep message when the P 399 flag has been set in the corresponding PCReq message. 401 4.4.1. SDH-ASON QoS Parameters TLV 403 The SDH-ASON QoS Parameters TLV is a new OPTIONAL TLV. It MUST only 404 appear inside QoS object. The receiver SHOULD ignore the SDH-ASON QoS 405 Parameters TLV if it appears in any other object other than QoS 406 object. Only one instance of this TLV MUST be present inside QoS 407 object. This TLV contains the parameters such as signal-type, 408 Requested Contiguous Concatenation (RCC), multiplier, Number of 409 Virtual Components (NVC), Number of Contiguous Concatenation (NCC), 410 transparency, and profile. 412 The format of the SDH-ASON QoS Parameters TLV is as follows: 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | Type = 34 | Length = 16 | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Signal Type | RCC | Multiplier (MT) | 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | NVC | NCC | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Transparency (T) | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Profile (P) | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 428 Type (16-bits) - Specifies the type of the TLV (Value = 34). 430 Length (16-bits) - Specifies the length of the value field (Value = 431 16). 433 ST - Signal Type (8-bits). Specifies the type of elementary signal 434 that comprises the requested LSP. Several transforms can be applied 435 successively on the elementary signal to build the final signal being 436 actually requested for the LSP. 438 Each transform application is optional and must be ignored if zero, 439 except the Multiplier (MT) that cannot be zero and is ignored if 440 equal to one. 442 Transforms must be applied strictly in the following order: 444 o First, contiguous concatenation (by using the RCC and NCC fields) 445 can be optionally applied on the elementary signal, resulting in 446 a contiguously concatenated signal. 448 o Second, virtual concatenation (by using the NVC field) can be 449 optionally applied on the elementary signal resulting in 450 virtually concatenated signal. 452 o Third, some transparency (by using the Transparency field) can be 453 optionally specified when requesting a frame as signal rather 454 than an SPE or VC based signal. 456 o Fourth, a multiplication (by using the MT field) can be optionally 457 applied either directly on the elementary signal, or on the 458 contiguously concatenated signal obtained from the first phase, 459 or on the virtually concatenated signal obtained from the second 460 phase, or on these signals combined with some transparency. 462 The permitted values for SDH-ASON are as follows: 464 Bit Type (Elementary Signal) 465 1 VT1.5 SPE / VC-11 466 2 VT2 SPE / VC-12 467 4 VT6 SPE / VC-2 468 5 STS-1 SPE / VC-3 469 6 STS-3c SPE / VC-4 470 7 STS-1 / STM-0 (only when requesting transparency) 471 8 STS-3 / STM-1 (only when requesting transparency) 472 9 STS-12 / STM-4 (only when requesting transparency) 473 10 STS-48 / STM-16(only when requesting transparency) 474 11 STS-192 / STM-64(only when requesting transparency) 475 12 STS-768 / STM-256(only when requesting transparency) 477 RCC - Requested Contiguous Concatenation (8 bits). This field is used 478 to request the optional SDH contiguous concatenation of the 479 elementary signal. This field is a vector of flags. Each flag 480 indicates the support of a particular type of contiguous 481 concatenation. Several flags can be set at the same time to indicate 482 a choice. 484 All the bits should be cleared if contiguous concatenation is not 485 requested. A non-zero field indicates that some contiguous 486 concatenation is requested. 488 NCC - Number of Contiguous Components (16 bits). Specifies the number 489 of identical SDH VCs (for example, elementary signal) that are 490 requested to be concatenated, as specified in the RCC field. 492 When requesting a transparent STS-N/STM-N signal limited to a single 493 contiguously concatenated STS-Nc_SPE/VC-4-Nc, the signal type must be 494 STS-N/STM-N, RCC with flag 1 and NCC set to 1. The NCC value must be 495 consistent with the type of contiguous concatenation being requested 496 in the RCC field. In particular, this field is irrelevant if no 497 contiguous concatenation is requested (RCC = 0), in that case it must 498 be set to zero when sent, and should be ignored when received. A RCC 499 value different from 0 must imply a number of contiguous components 500 greater than 1. 502 NVC - Number of Virtual Components (16 bits). Specifies the number of 503 signals that are requested to be virtually concatenated. These 504 signals are all of the same type by definition. They are elementary 505 signal SPEs/VCs for which signal types are VT1.5_SPE/VC-11, VT2_SPE/ 506 VC-12, VT3_SPE, VT6_SPE/VC-2, STS-1_SPE/VC-3 or STS-3c_SPE/VC-4. 508 This field is set to 0 (default value) to indicate that no virtual 509 concatenation is requested. 511 MT - Multiplier (16 bits). Specifies the number of identical signals 512 that are requested for the LSP to form the final signal. These 513 signals can be either identical elementary signals, or identical 514 contiguous concatenated signals, or identical virtual concatenated 515 signals. Note that all these signals belong to the same LSP. 517 This field is set to one (default value) to indicate that exactly one 518 instance of a signal is being requested. 520 T - Transparency (32 bits). Specifies a vector of flags that 521 indicates the type of transparency being requested. Several flags can 522 be combined to provide different types of transparency. Not all 523 combinations are necessarily valid. The default value for this field 524 is zero, which means no transparency is requested. 526 Note as well that transparency is only applicable when using the 527 following signal types: STS-1/STM-0, STS-3/STM-1, STS-12/STM-4, STS- 528 48/STM-16, STS-192/STM-64 and STS-768/STM-256. At least one 529 transparency type must be specified when requesting such a signal 530 type. 532 The different transparency flags are the following: 534 o Flag 1 (bit 1): Section/Regenerator Section layer 535 o Flag 2 (bit 2): Line/Multiplex Section layer 537 Where bit 1 is the low order bit. Other flags are reserved, they 538 should be set to zero when sent, and should be ignored when received. 539 A flag is set to one to indicate that the corresponding transparency 540 is requested. 542 P - Profile (32 bits). This field is intended to indicate particular 543 capabilities that must be supported for the LSP, for example 544 monitoring capabilities. 546 No standard profile is currently defined and this field SHOULD be set 547 to zero when transmitted and SHOULD be ignored when received. In the 548 future TLV based extensions may be created. 550 4.4.2. LSP Protection Information TLV 552 This is a new OPTIONAL TLV and MUST only appear inside QoS object. 553 This TLV contains the constraints related to protection which 554 includes SLA, protection scheme, segment recovery, and so on. 556 The format of the LSP Protection Information TLV is as follows: 558 0 1 2 3 559 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 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | Type = 40 | Length = 8 | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 |E|U|S|D|D|L|R| Reserved |R|I|O|N|W|E|P| 564 |T|P|H|T|P|E|R| | |P| | |P|P|S| 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 | Protection | Segment | Associated | 567 | Scheme | Recovery | LSP ID | 568 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 570 Type (16-bits) - Specifies the type of the TLV (Value = 40). 572 Length (16-bits) - Specifies the length of the value field (Value = 573 8). 575 Protection Flags 577 o ET - Extra Traffic Flag (1-bit). Specifies the extra traffic flag. 578 It basically stands for the iron traffic that is preemptible. The 579 LSP should use links that are protecting other (primary) traffic. 580 Such LSPs may be preempted when the links carrying the (primary) 581 traffic fails. 583 o UP - Unprotected Flag (1-bit). Specifies the unprotected traffic, 584 copper. The LSP will not use any link layer protection. 586 o SH - Shared Flag (1-bit). Specifies the shared traffic, silver. A 587 shared link layer protection scheme, such as 1:N protection, 588 should be used to support the LSP. 590 o DT - Dedicated 1:1 Flag (1-bit). Specifies the dedicated 1:1 591 service, gold. A dedicated link layer protection scheme (1:1 592 protection) should be used to support the LSP. 594 o DP - Dedicated 1+1 Flag (1-bit). Specifies the dedicated 1+1 595 service, diamond. A dedicated link layer protection scheme (1+1 596 protection) should be used to support the LSP. 598 o LE - Link Enhanced Flag (1 bit). Specifies the enhanced features 599 for a link, where a protection scheme that is more reliable than 600 dedicated 1+1 should be used, such as 4 fiber BLSR/MS-SPRING. 602 o RR - Reroute Flag (1-bit). Specifies the reroute flag. If set the 603 service is rerouted. 605 Reserved (18 bits) - Reserved for future. This field MUST be set to 606 zero on transmission and MUST be ignored on receipt. 608 Additional Protection Flags 610 o R - Required Flag (1-bit). 612 o IP - In Place Flag (1-bit). 614 o O - Operational Flag (1 bit). 616 o N - Change Notification Flag (1-bit). Specifies the change in the 617 protection flags. 619 o WP - Working or Protection Flag (1-bit). Specifies the working 620 LSP (bit value = 0) or protection LSP (bit value = 1). 622 o EP - Extended Protection Flag (1-bit). 624 o PS - Primary or Secondary Flag (1-bit). Specifies whether to 625 signal and reserve the resources of the primary LSP (bit value = 626 0) or secondary LSP (bit value = 1). 628 Protection Scheme (8-bits) - Specifies the protection scheme of the 629 LSP. It can carry the following values based on the requested 630 protection type: 632 Value Protection Scheme Type 634 0x00 No end-to-end protection (iron service) 636 0x01 Reroute protection (silver service) 638 0x02 1:1 protection without extra traffic (gold service) 640 0x03 1+1 protection and is uni-directional (diamond service) 641 0x04 1+1 protection, and is bi-directional (diamond service) 643 0x05 Reserved for new protection schemes 645 0xFE Reserved for new protection schemes 647 0xFF Reserved for future 649 Segment Recovery (8-bits) - Specifies the recovered segment of the 650 LSP. 652 Associated LSP ID (16-bits) - Specifies the LSP ID of the associated 653 service. During re-routing or optimization, the traffic prevents the 654 route of the associated one. 656 4.4.3. QoS Object in PCReq and PCRep 658 As mentioned earlier the QoS object MAY be included in the PCReq 659 message specifying the traffic parameters. This object is OPTIONAL, 660 and if present only one instance of SDH-ASON QoS parameters TLV or 661 LSP protection TLV must be included. If multiple instances of TLV or 662 some other TLV is present, then the complete message has to be 663 discarded without performing any further processing. 665 The format of the PCReq message including the QoS object is as 666 follows: 668 ::= 669 [] 670 672 where: 674 ::= [] 676 ::= [] 678 ::= 679 680 [] 681 [] 682 [] 683 [] 684 [[]] 685 [] 686 [] 688 The format of the PCRep message is as follows: 690 ::= 691 693 where: 695 ::= [] 697 ::= 698 [] 699 [] 700 [] 702 ::= [] 704 ::= 706 where: 708 ::= [] 709 [] 710 [] 711 [] 712 [] 714 ::= [] 716 4.5. Additional Error Type and Error Values Defined 718 A PCEP-ERROR object is used to report a PCEP error and is 719 characterized by an Error-Type that specifies the type of error and 720 an Error-value that provides additional information about the error 721 type. An additional error type and few error values are defined to 722 represent some of the errors related to the newly identified objects 723 related to SDH networks. 725 For each PCEP error, an Error-Type and an Error-value are defined. 726 Error-Type 1 to 10 are already defined in RFC5440. Additional Error- 727 values are defined for Error-Type 10 and a new Error-Type 14 is 728 introduced. 730 Error-Type Error-value 732 10 Reception of an invalid object 733 Error-value=2: Requested GMPLS Label information TLV 734 missing in RP object. 736 Error-value=3: LSP Protection Information TLV missing 737 in QoS object. 739 Error-value=4: TLV missing in QoS object. 741 Error-value=5: Multiple instance of TLV present in 742 QoS object. 744 Error-value=6: Unsupported TLV present in QoS object. 746 Error-value=7: SONET/SDH QoS parameters TLV missing 747 in QoS object. 749 14 Path computation failure 751 Error-value=1: Unacceptable response message. 753 Error-value=2: QoS object missing in request message. 755 5. Manageability Considerations 757 Liveness Detection and Monitoring 759 This document makes no change to the basic operation of PCEP and so 760 there are no changes to the requirements for liveness detection and 761 monitoring set out in RFC4657 and RFC5440. 763 6. IANA Considerations 765 IANA assigns values to the PCEP protocol objects and TLVs. IANA is 766 requested to make some allocations for the newly defined objects and 767 TLVs introduced in this document. Also, IANA is requested to manage 768 the space of flags that are newly added in the TLVs. 770 6.1. New PCEP Object 772 IANA is requested to make some allocations for the QoS object: 774 Object-Class Value Name Reference 775 25 QoS Object-Type-1 This document (section 4.4) 777 6.2. New PCEP TLVs 779 IANA is requested to create a registry for the following TLVs: 781 Value Meaning Reference 783 13 Requested GMPLS Label This document (section 4.1.1) 785 20 Destination Prefix Information This document (section 4.3.1) 787 34 SDH-ASON QoS Parameters This document (section 4.4.1) 789 40 LSP Protection Information This document (section 4.4.2) 791 6.3. PCEP RP Object Flag Field 793 IANA is requested to create a registry to manage the Flag field of 794 the RP object. 796 New bit numbers may be allocated only by an IETF Consensus action. 797 Each bit should be tracked with the following qualities: 799 o Bit number (counting from bit 0 as the most significant bit) 801 o Name Flag 803 o Reference 805 Code space of the Flag field (RP object). 807 Bit Number Name Reference 809 0,1,2 Network Type (NT) This document (section 4.1) 811 6.4. PCEP NO-PATH-VECTOR TLV Flag Field 813 IANA is requested to create a registry to manage the Flag field of 814 the NO-PATH-VECTOR TLV. 816 New bit numbers may be allocated only by an IETF Consensus action. 817 Each bit should be tracked with the following qualities: 819 o Bit number (counting from bit 0 as the most significant bit) 821 o Name Flag 823 o Reference 824 Code space of the Flag field (NO-PATH-VECTOR TLV). 826 Bit Number Name Reference 828 27 No Resource (NR) This document (section 4.2.1) 830 28 Protection Mismatch (PM) This document (section 4.2.1) 832 6.5. New PCEP Error Codes 834 As descried in Section 4.5, new PCEP Error-Type and Error Values are 835 defined. IANA is requested to manage the code space of the Error 836 object. 838 Error-Type Error-value 840 10 Reception of an invalid object 842 Error-value=2: Requested GMPLS Label information TLV 843 missing in RP object. 845 Error-value=3: LSP Protection Information TLV missing 846 in QoS object. 848 Error-value=4: TLV missing in QoS object. 850 Error-value=5: Multiple instance of TLV present in QoS 851 object. 853 Error-value=6: Unsupported TLV present in QoS object. 855 Error-value=7: SONET/SDH QoS parameters TLV missing in 856 QoS object. 858 14 Path computation failure 860 Error-value=1: Unacceptable response message. 862 Error-value=2: QoS object missing in request message. 864 7. Security Considerations 866 The protocol extensions defined in this document do not substantially 867 change the nature of PCEP. Therefore, the security considerations set 868 out in RFC5440 apply unchanged. 870 8. References 872 8.1. Normative References 874 [GMPLS-REQ] Otani, Ogaki, Caviglia, and Fatai Zhang, "Requirements 875 for GMPLS applications of PCE", July 2009. 877 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 878 Requirement Levels", March 1997. 880 [RFC3209] Bradner, S., "RSVP-TE: Extensions to RSVP for LSP 881 Tunnels", March 1997. 883 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 884 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 885 Engineering (RSVP-TE) Extensions", January 2003. 887 [RFC3477] Kompella, K. and Y. Rekhter, "Signaling Unnumbered Links 888 in Resource Reservation Protocol - Traffic Engineering 889 (RSVP-TE)", January 2003. 891 [RFC4090] Pan, P., Swallow, G., and A. Atlas, "Fast Reroute 892 Extensions to RSVP-TE for LSP Tunnels", May 2005. 894 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 895 IANA Considerations Section in RFCs", May 2008. 897 8.2. Informative References 899 [RFC4606] Mannie, E. and D. Papadimitriou, "Generalized Multi- 900 Protocol Label Switching (GMPLS) Extensions for 901 Synchronous Optical Network (SONET) and Synchronous 902 Digital Hierarchy (SDH) Control", February 2003. 904 [RFC4655] Vasseur, J. and J. Ash, "A Path Computation Element 905 (PCE)-Based Architecture", August 2006. 907 [RFC4657] Ash, J. and J. Roux, "Path Computation Element (PCE) 908 Communication Protocol Generic Requirements", September 909 2006. 911 [RFC4674] Roux, J., "Requirements for Path Computation Element 912 (PCE) Discovery", October 2006. 914 [RFC5088] Roux, J., "OSPF Protocol Extensions for PCE Discovery", 915 January 2008. 917 [RFC5440] Ash, J. and J. Roux, "Path Computation Element (PCE) 918 communication Protocol (PCEP)", March 2009. 920 9. Authors' Addresses 922 Fatai Zhang 923 Huawei Technologies 924 F3-5-B R&D Center, Huawei Base 925 Bantian, Longgang District 926 Shenzhen 518129 P.R.China 927 Email: zhangfatai@huawei.com 929 Suresh BR 930 Huawei Technologies 931 Shenzhen 932 China 933 Email: sureshbr@huawei.com 935 SenthilKumar S 936 Huawei Technologies 937 Shenzhen 938 China 939 Email: senthilkumars@huawei.com 941 Jun Sun 942 Huawei Technologies 943 Shenzhen 944 China 945 Email: sunjun@huawei.com 947 Intellectual Property 949 The IETF Trust takes no position regarding the validity or scope of 950 any Intellectual Property Rights or other rights that might be 951 claimed to pertain to the implementation or use of the technology 952 described in any IETF Document or the extent to which any license 953 under such rights might or might not be available; nor does it 954 represent that it has made any independent effort to identify any 955 such rights. 957 Copies of Intellectual Property disclosures made to the IETF 958 Secretariat and any assurances of licenses to be made available, or 959 the result of an attempt made to obtain a general license or 960 permission for the use of such proprietary rights by implementers or 961 users of this specification can be obtained from the IETF on-line IPR 962 repository at http://www.ietf.org/ipr 964 The IETF invites any interested party to bring to its attention any 965 copyrights, patents or patent applications, or other proprietary 966 rights that may cover technology that may be required to implement 967 any standard or specification contained in an IETF Document. Please 968 address the information to the IETF at ietf-ipr@ietf.org. 970 The definitive version of an IETF Document is that published by, or 971 under the auspices of, the IETF. Versions of IETF Documents that are 972 published by third parties, including those that are translated into 973 other languages, should not be considered to be definitive versions 974 of IETF Documents. The definitive version of these Legal Provisions 975 is that published by, or under the auspices of, the IETF. Versions of 976 these Legal Provisions that are published by third parties, including 977 those that are translated into other languages, should not be 978 considered to be definitive versions of these Legal Provisions. 980 For the avoidance of doubt, each Contributor to the IETF Standards 981 Process licenses each Contribution that he or she makes as part of 982 the IETF Standards Process to the IETF Trust pursuant to the 983 provisions of RFC 5378. No language to the contrary, or terms, 984 conditions or rights that differ from or are inconsistent with the 985 rights and licenses granted under RFC 5378, shall have any effect and 986 shall be null and void, whether published or posted by such 987 Contributor, or included with or in such Contribution. 989 Disclaimer of Validity 991 All IETF Documents and the information contained therein are provided 992 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 993 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 994 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 995 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 996 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 997 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 998 FOR A PARTICULAR PURPOSE. 1000 Full Copyright Statement 1002 Copyright (c) 2009 IETF Trust and the persons identified as the 1003 document authors. All rights reserved. 1005 This document is subject to BCP 78 and the IETF Trust's Legal 1006 Provisions Relating to IETF Documents in effect on the date of 1007 publication of this document (http://trustee.ietf.org/license-info). 1008 Please review these documents carefully, as they describe your rights 1009 and restrictions with respect to this document.