idnits 2.17.1 draft-li-pce-pcep-flowspec-03.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 (December 29, 2017) is 2308 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) == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-08 ** Downref: Normative reference to an Experimental draft: draft-dhodylee-pce-pcep-ls (ref. 'I-D.dhodylee-pce-pcep-ls') == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-09 ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-16) exists of draft-ietf-pce-segment-routing-11 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Dhody, Ed. 3 Internet-Draft Huawei Technologies 4 Intended status: Standards Track A. Farrel, Ed. 5 Expires: July 2, 2018 Juniper Networks 6 Z. Li 7 Huawei Technologies 8 December 29, 2017 10 PCEP Extension for Flow Specification 11 draft-li-pce-pcep-flowspec-03 13 Abstract 15 The Path Computation Element (PCE) is a functional component capable 16 of selecting the paths through a traffic engineered network. These 17 paths may be supplied in response to requests for computation, or may 18 be unsolicited directions issued by the PCE to network elements. 19 Both approaches use the PCE Communication Protocol (PCEP) to convey 20 the details of the computed path. 22 Traffic flows may be categorized and described using "Flow 23 Specifications". RFC 5575 defines the Flow Specification and 24 describes how it may be distributed in BGP to allow specific traffic 25 flows to be associated with routes. 27 This document specifies a set of extensions to PCEP to support 28 dissemination of Flow Specifications. This allows a PCE to indicate 29 what traffic should be placed on each path that it is aware of. 31 Requirements Language 33 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 34 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 35 "OPTIONAL" in this document are to be interpreted as described in BCP 36 14 [RFC2119] [RFC8174] when, and only when, they appear in all 37 capitals, as shown here. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at https://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on July 2, 2018. 56 Copyright Notice 58 Copyright (c) 2017 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (https://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 3. Procedures for PCE Use of Flow Specifications . . . . . . . . 4 76 3.1. Capability Advertisement . . . . . . . . . . . . . . . . 5 77 3.1.1. PCEP OPEN Message . . . . . . . . . . . . . . . . . . 5 78 3.1.2. IGP PCE Capabilities Advertisement . . . . . . . . . 5 79 3.2. Dissemination Procedures . . . . . . . . . . . . . . . . 6 80 3.3. Flow Specification Synchronization . . . . . . . . . . . 7 81 4. PCE FlowSpec Capability TLV . . . . . . . . . . . . . . . . . 7 82 5. PCEP Flow Spec Object . . . . . . . . . . . . . . . . . . . . 8 83 6. Flow Filter TLV . . . . . . . . . . . . . . . . . . . . . . . 9 84 7. Flow Specification TLVs . . . . . . . . . . . . . . . . . . . 9 85 8. Detailed Procedures . . . . . . . . . . . . . . . . . . . . . 12 86 8.1. Default Behavior and Backward Compatibility . . . . . . . 13 87 8.2. Composite Flow Specifications . . . . . . . . . . . . . . 13 88 8.3. Modifying Flow Specifications . . . . . . . . . . . . . . 13 89 8.4. Multiple Flow Specifications . . . . . . . . . . . . . . 13 90 8.5. Adding and Removing Flow Specifications . . . . . . . . . 14 91 8.6. VPN Identifiers . . . . . . . . . . . . . . . . . . . . . 14 92 8.7. Priorities and Overlapping Flow Specifications . . . . . 14 93 9. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 15 94 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 95 10.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 18 96 10.2. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 18 97 10.3. Flow Specification TLV Type Indicators . . . . . . . . . 18 98 10.4. PCEP Error Codes . . . . . . . . . . . . . . . . . . . . 19 99 10.5. PCE Capability Flag . . . . . . . . . . . . . . . . . . 19 100 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 101 12. Manageability Considerations . . . . . . . . . . . . . . . . 20 102 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 103 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 14.1. Normative References . . . . . . . . . . . . . . . . . . 21 105 14.2. Informative References . . . . . . . . . . . . . . . . . 22 106 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 23 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 109 1. Introduction 111 [RFC4655] defines the Path Computation Element (PCE), a functional 112 component capable of computing paths for use in traffic engineering 113 networks. PCE was originally conceived for use in Multiprotocol 114 Label Switching (MPLS) for Traffic Engineering (TE) networks to 115 derive the routes of Label Switched Paths (LSPs). However, the scope 116 of PCE was quickly extended to make it applicable to Generalized MPLS 117 (GMPLS) networks, and more recent work has brought other traffic 118 engineering technologies and planning applications into scope (for 119 example, Segment Routing (SR) [I-D.ietf-pce-segment-routing]). 121 [RFC5440] describes the Path Computation Element Communication 122 Protocol (PCEP). PCEP defines the communication between a Path 123 Computation Client (PCC) and a PCE, or between PCE and PCE, enabling 124 computation of path for MPLS-TE LSPs. 126 Stateful PCE [RFC8231] specifies a set of extensions to PCEP to 127 enable control of TE-LSPs by a PCE that retains state about the the 128 LSPs provisioned in the network (a stateful PCE). [RFC8281] 129 describes the setup, maintenance, and teardown of LSPs initiated by a 130 stateful PCE without the need for local configuration on the PCC, 131 thus allowing for a dynamic network that is centrally controlled. 132 [RFC8283] introduces the architecture for PCE as a central controller 133 and describes how PCE can be viewed as a component that performs 134 computation to place 'flows' within the network and decide how these 135 flows are routed. 137 Dissemination of traffic flow specifications (Flow Specifications) 138 was introduced for BGP in [RFC5575]. A Flow Specification is 139 comprised of traffic filtering rules and actions. The routers that 140 receive a Flow Specification can classify received packets according 141 to the traffic filtering rules and can direct packets based on the 142 actions. 144 When a PCE is used to initiate tunnels (such as TE-LSPs or SR paths) 145 using PCEP, it is important that the head end of the tunnels 146 understands what traffic to place on each tunnel. The data flows 147 intended for a tunnel can be described using Flow Specifications, and 148 when PCEP is in use for tunnel initiation it makes sense for that 149 same protocol to be used to distribute the Flow Specifications that 150 describe what data is to flow on those tunnels. 152 This document specifies a set of extensions to PCEP to support 153 dissemination of Flow Specifications. The extensions include the 154 creation, update, and withdrawal of Flow Specifications via PCEP and 155 can be applied to tunnels initiated by the PCE or to tunnels where 156 control is delegated to the PCE by the PCC. Furthermore, a PCC 157 requesting a new path can include Flow Specifications in the request 158 to indicate the purpose of the tunnel allowing the PCE to factor this 159 in during the path computation. 161 Flow Specifications are carried in TLVs within a new Flow Spec Object 162 defined in this document. The flow filtering rules indicated by the 163 Flow Specifications are mainly defined by BGP Flow Specifications. 165 2. Terminology 167 This document uses the following terms defined in [RFC5440]: PCC, 168 PCE, PCEP Peer. 170 The following term from [RFC5575] is used frequently throughout this 171 document: 173 Flow Specification (FlowSpec): A Flow Specification is an n-tuple 174 consisting of several matching criteria that can be applied to IP 175 traffic, including filters and actions. Each FlowSpec consists of 176 a set of filters and a set of actions. 178 This document uses the terms "stateful PCE" and "active PCE" as 179 advocated in [RFC7399]. 181 3. Procedures for PCE Use of Flow Specifications 183 There are three elements of procedure: 185 o A PCE and a PCC must be able to indicate whether or not they 186 support the use of Flow Specifications. 188 o A PCE or PCC must be able to include Flow Specifications in PCEP 189 messages with clear understanding of the applicability of those 190 Flow Specifications in each case including whether the use of such 191 information is mandatory, constrained, or optional, and how 192 overlapping Flow Specifications will be resolved.. 194 o Flow Specification information/state must be synchronized between 195 PCEP peers so that, on recovery, the peers have the same 196 understanding of which Flow Specifications apply. 198 The following subsections describe these points. 200 3.1. Capability Advertisement 202 3.1.1. PCEP OPEN Message 204 During PCEP session establishment, a PCC or PCE that supports the 205 procedures described in this document announces this fact by 206 including the "PCE FlowSpec Capability" TLV (described in Section 4) 207 in the OPEN Object carried in the PCEP Open message. 209 The presence of the PCE FlowSpec Capability TLV in the OPEN Object in 210 a PCE's OPEN message indicates that the PCE can support distribute 211 the FlowSpec to PCCs and can receive FlowSpecs in messages from the 212 PCCs. 214 The presence of the PCE FlowSpec Capability TLV in the OPEN Object in 215 a PCC's OPEN message indicates that the PCC supports the FlowSpec 216 functionality described in this document. 218 If either one of a pair of PCEP peers does not indicate support of 219 the functionality described in this document by not including the PCE 220 FlowSpec Capability TLV in the OPEN Object in its OPEN message, then 221 the other peer MUST NOT include a FlowSpec object in any PCEP message 222 sent to the peer that does not support the procedures. If a FlowSpec 223 object is received even though support has not been indicated, the 224 receiver will respond with a PCErr message reporting the objects 225 containing the FlowSpec as described in [RFC5440]: that is, it will 226 use 'Unknown Object' if it does not support this specification, and 227 'Not supported object' if it supports this specification but has not 228 chosen to support FlowSpec objects on this PCEP session. 230 3.1.2. IGP PCE Capabilities Advertisement 232 The ability to advertise support for PCEP and PCE features in IGP 233 advertisements is provided for OSPF in [RFC5088] and for IS-IS in 234 [RFC5089]. The mechanism uses the PCE Discovery TLV which has a PCE- 235 CAP-FLAGS sub-TLV containing bit-flags each of which indicates 236 support for a different feature. 238 This document defines a new PCE-CAP-FLAGS sub-TLV bit, the FlowSpec 239 Capable flag (bit number TBD1). Setting the bit indicates that an 240 advertising PCE supports the procedures defined in this document. 242 Note that while PCE FlowSpec Capability may be advertised during 243 discovery, PCEP speakers that wish to use Flow Specification in PCEP 244 MUST negotiate PCE FlowSpec Capability during PCEP session setup, as 245 specified in Section 3.1.1. A PCC MAY initiate PCE FlowSpec 246 Capability negotiation at PCEP session setup even if it did not 247 receive any IGP PCE capability advertisement. 249 3.2. Dissemination Procedures 251 This section describes the procedures to support Flow Specifications 252 in PCEP messages. 254 The primary purpose of distributing Flow Specification information is 255 to allow a PCE to indicate to a PCC what traffic it should place on a 256 path (such as an LSP or an SR path). This means that the Flow 257 Specification may be included in: 259 o PCInitiate messages so that an active PCE can indicate the traffic 260 to place on a path at the time that the PCE instantiates the path. 262 o PCUpd messages so that an active PCE can indicate or change the 263 traffic to place on a path that has already been set up. 265 o PCRpt messages so that a PCC can report the traffic that the PCC 266 plans to place on the path. 268 o PCReq messages so that a PCC can indicate what traffic it plans to 269 place on a path at the time it requests the PCE to perform a 270 computation in case that information aids the PCE in its work. 272 o PCRep messages so that a PCE that has been asked to compute a path 273 can suggest which traffic could be placed on a path that a PCC may 274 be about to set up. 276 o PCErr messages so that issues related to paths and the traffic 277 they carry can be reported to the PCE by the PCC, and so that 278 problems with other PCEP messages that carry Flow Specifications 279 can be reported. 281 To carry Flow Specifications in PCEP messages, this document defines 282 a new PCEP object called the PCEP Flow Spec Object. The object is 283 OPTIONAL in the messages described above and MAY appear more than 284 once in each message. 286 The PCEP Flow Spec Object carries zero or one Flow Filter TLV which 287 describes a traffic flow. 289 The inclusion of multiple PCEP Flow Spec Objects allows multiple 290 traffic flows to be placed on a single path. 292 Once a PCE and PCC have established that they can both support the 293 use of Flow Specifications in PCEP messages, such information may be 294 exchanged at any time for new or existing paths. 296 The application and prioritization of Flow Specifications is 297 described in Section 8.7. 299 3.3. Flow Specification Synchronization 301 The Flow Specifications are carried along with the LSP State 302 information as per [RFC8231] making the Flow Specifications part of 303 the LSP database (LSP-DB). Thus, the synchronization of the Flow 304 Specification information is done as part of LSP-DB synchronization. 305 This may be achieved using normal state synchronization procedures as 306 described in [RFC8231] or enhanced state synchronization procedures 307 as defined in [RFC8232]. 309 The approach selected will be implementation and deployment specific 310 and will depend on issues such as how the databases are constructed 311 and what level of synchronization support is needed. 313 4. PCE FlowSpec Capability TLV 315 The PCE-FLOWSPEC-CAPABILITY TLV is an optional TLV that can be 316 carried in the OPEN Object [RFC5440] to exchange PCE FlowSpec 317 capabilities of PCEP speakers. 319 The format of the PCE-FLOWSPEC-CAPABILITY TLV follows the format of 320 all PCEP TLVs as defined in [RFC5440] and is shown in Figure 1. 322 0 1 2 3 323 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 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | Type=TBD2 | Length=2 | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 | Value=0 | Padding | 328 +---------------------------------------------------------------+ 330 Figure 1: PCE-FLOWSPEC-CAPABILITY TLV format 332 The type of the PCE-FLOWSPEC-CAPABILITY TLV is TBD2 and it has a 333 fixed length of 2 octets. The Value field is set to default value 0. 334 The two bytes of padding MUST be set to zero and ignored on receipt. 336 The inclusion of this TLV in an OPEN object indicates that the sender 337 can perform FlowSpec handling as defined in this document. 339 5. PCEP Flow Spec Object 341 The PCEP Flow Spec object defined in this document is compliant with 342 the PCEP object format defined in [RFC5440]. It is OPTIONAL in the 343 PCReq, PCRep, PCErr, PCInitiate, PCRpt, and PCUpd messages and MAY be 344 present zero, one, or more times. Each instance of the object 345 specifies a traffic flow. 347 The PCEP Flow Spec object carries a FlowSpec filter rule encoded in a 348 TLV (as defined in Section 6. 350 The FLOW SPEC Object-Class is TBD3 (to be assigned by IANA). 352 The FLOW SPEC Object-Type is 1. 354 The format of the body of the PCEP Flow Spec object is shown in 355 Figure 2 357 0 1 2 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | FS-ID | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Reserved |R| 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | | 365 | Flow Filter TLV (variable) | 366 | | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 Figure 2: PCEP Flow Spec Object Body Format 371 FS-ID (32-bits): A PCEP-specific identifier for the FlowSpec 372 information. A PCE creates an FS-ID for each FlowSpec, the value is 373 unique within the scope of the PCE and is constant for the lifetime 374 of a PCEP session. All subsequent PCEP messages can identify the 375 FlowSpec using the FS-ID. The values 0 and 0xFFFFFFFF are reserved 376 and MUST NOT be used. 378 Reserved bits: MUST be set to zero on transmission and ignored on 379 receipt. 381 R bit: The Remove bit is set when a PCEP Flow Spec Object is included 382 in a PCEP message to indicate removal of the Flow Specification from 383 the associated tunnel. If the bit is clear, the Flow Specification 384 is being added or modified. 386 Flow Filter TLV (variable): One TLV MAY be included. 388 The Flow Filter TLV is OPTIONAL when the R bit is set. The TLV MUST 389 be present when the R bit is clear. If the TLV is missing when the R 390 bit is clear, the PCEP peer MUST respond with a PCErr message with 391 error-type TBD8 (FlowSpec Error), error-value 2 (Malformed FlowSpec). 393 6. Flow Filter TLV 395 A new PCEP TLV is defined to convey Flow Specification filtering 396 rules that specify what traffic is carried on a path. The TLV 397 follows the format of all PCEP TLVs as defined in [RFC5440]. The 398 Type field values come from the codepoint space for PCEP TLVs and has 399 the value TBD4. 401 The Value field contains one or more sub-TLVs (the Flow Specification 402 TLVs) as defined in Section 7. Only one Flow Filter TLV can be 403 present and represents the complete definition of a Flow 404 Specification for traffic to be placed on the tunnel indicated by the 405 PCEP message in which the PCEP Flow Spec Object is carried. The set 406 of Flow Specification TLVs in a single instance of a Flow Filter TLV 407 are combined to indicate the specific Flow Specification. 409 Further Flow Specifications can be included in a PCEP message by 410 including additional Flow Spec objects. 412 7. Flow Specification TLVs 414 Flow Filter TLV carries one or more Flow Specification sub-TLV. The 415 Flow Specification TLV also follows the format of all PCEP TLVs as 416 defined in [RFC5440], however, the Type values are selected from a 417 separate IANA registry (see Section 10) rather than from the common 418 PCEP TLV registry. 420 Type values are chosen so that there can be commonality with Flow 421 Specifications defined for use with BGP. This is possible because 422 the BGP Flow Spec encoding uses a single octet to encode the type 423 where PCEP uses two octets. Thus the space of values for the Type 424 field is partitioned as shown in Figure 3. 426 Range | 427 ---------------+--------------------------------------------------- 428 0 | Reserved - must not be allocated. 429 | 430 1 .. 255 | Per BGP registry defined by [RFC5575]. 431 | Not to be allocated in this registry. 432 | 433 256 .. 65535 | New PCEP Flow Specs allocated according to the 434 | registry defined in this document. 436 Figure 3: Flow Specification TLV Type Ranges 438 The content of the Value field Flow in each TLV is specific to the 439 type and describes the parameters of the Flow Specification. The 440 definition of the format of many of these Value fields is inherited 441 from BGP specifications as shown in Figure 4. Specifically, the 442 inheritance is from [RFC5575] and [I-D.ietf-idr-flow-spec-v6], but 443 may also be inherited from future BGP specifications. 445 When multiple Flow Specification TLVs are present in a single Flow 446 Filter TLV they are combined to produce a more detailed description 447 of a flow. For examples and rules about how this is achieved, see 448 [RFC5575]. 450 An implementation that receives a PCEP message carrying a Flow 451 Specification TLV with a type value that it does not recognize or 452 does not support MUST respond with a PCErr message with error-type 453 TBD8 (FlowSpec Error), error-value 1 (Unsupported FlowSpec) and MUST 454 NOT install the Flow Specification. 456 When used in other protocols (such as BGP) these Flow Specifications 457 are also associated with actions to indicate how traffic matching the 458 Flow Specification should be treated. In PCEP, however, the only 459 action is to associate the traffic with a tunnel and to forward 460 matching traffic on to that path, so no encoding of an action is 461 needed. 463 Section 8.7 describes how overlapping Flow Specifications are 464 prioritized and handled. 466 +-------+-------------------------+-----------------------------+ 467 | Type | Description | Value defined in | 468 | | | | 469 +-------+-------------------------+-----------------------------+ 470 | * | Destination IPv4 Prefix | [RFC5575] | 471 +-------+-------------------------+-----------------------------+ 472 | * | Source IPv4 Prefix | [RFC5575] | 473 +-------+-------------------------+-----------------------------+ 474 | * | IP Protocol | [RFC5575] | 475 +-------+-------------------------+-----------------------------+ 476 | * | Port | [RFC5575] | 477 +-------+-------------------------+-----------------------------+ 478 | * | Destination port | [RFC5575] | 479 +-------+-------------------------+-----------------------------+ 480 | * | Source port | [RFC5575] | 481 +-------+-------------------------+-----------------------------+ 482 | * | ICMP type | [RFC5575] | 483 +-------+-------------------------+-----------------------------+ 484 | * | ICMP code | [RFC5575] | 485 +-------+-------------------------+-----------------------------+ 486 | * | TCP flags | [RFC5575] | 487 +-------+-------------------------+-----------------------------+ 488 | * | Packet length | [RFC5575] | 489 +-------+-------------------------+-----------------------------+ 490 | * | DSCP | [RFC5575] | 491 +-------+-------------------------+-----------------------------+ 492 | * | Fragment | [RFC5575] | 493 +-------+-------------------------+-----------------------------+ 494 | * | Flow Label | [I-D.ietf-idr-flow-spec-v6] | 495 +-------+-------------------------+-----------------------------+ 496 | * | Destination IPv6 Prefix | [I-D.ietf-idr-flow-spec-v6] | 497 +-------+-------------------------+-----------------------------+ 498 | * | Source IPv6 Prefix | [I-D.ietf-idr-flow-spec-v6] | 499 +-------+-------------------------+-----------------------------+ 500 | * | Next Header | [I-D.ietf-idr-flow-spec-v6] | 501 +-------+-------------------------+-----------------------------+ 502 | TBD5 | Route Distinguisher | [I-D.dhodylee-pce-pcep-ls] | 503 +-------+-------------------------+-----------------------------+ 504 | TBD6 | IPv4 Multicast Flow | [This.I-D] | 505 +-------+-------------------------+-----------------------------+ 506 | TBD7 | IPv6 Multicast Flow | [This.I-D] | 507 +-------+-------------------------+-----------------------------+ 509 * Indicates that the TLV Type value comes from the value used 510 in BGP. 512 Figure 4: Table of Flow Specification TLV Types 514 All Flow Specification TLVs with Types in the range 1 to 255 have 515 Values defined for use in BGP (for example in [RFC5575] and 516 [I-D.ietf-idr-flow-spec-v6]) and are set using the BGP encoding, but 517 without the type or length octets (the relevant information is in the 518 Type and Length fields of the TLV). The Value field is padded with 519 trailing zeros to achieve 4-byte alignment if necessary. 521 [I-D.dhodylee-pce-pcep-ls] defines a way to convey identification of 522 a VPN in PCEP via a Route Distinguisher (RD) [RFC4364] and encoded in 523 ROUTE-DISTINGUISHER TLV. A Flow Specification TLV with Type TBD5 524 carries a Value field matching that in the ROUTE-DISTINGUISHER TLV 525 and is used to identify that other flow filter information (for 526 example, an IPv4 destination prefix) is associated with a specific 527 VPN identified by the RD. See Section 8.6 for further discussion of 528 VPN identification. 530 Although it may be possible to describe a multicast Flow 531 Specification from the combination of other Flow Specification TLVs 532 with specific values, it is more convenient to use a dedicated Flow 533 Specification TLV. Flow Specification TLVs with Type values TBD6 and 534 TBD7 are used to identify a multicast flow for IPv4 and IPv6 535 respectively. The Value field is encoded as shown in Figure 5. 537 0 1 2 3 538 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 539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 | Rsvd |S|W|R| Rsvd |B|Z| Src Mask Len | Grp Mask Len | 541 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 542 ~ Source Address ~ 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 ~ Group multicast Address ~ 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 Figure 5: Multicast Flow Specification TLV Encoding 549 The fields of the two Multicast Flow Specification TLVs are as 550 described in Section 4.9.1 of [RFC7761] noting that the two address 551 fields are 32 bits for the IPv4 Multicast Flow and 128 bits for the 552 IPv6 Multicast Flow. Reserved fields MUST be set to zero and ignored 553 on receipt. 555 8. Detailed Procedures 557 This section outlines some specific detailed procedures for using the 558 protocol extensions defined in this document. 560 8.1. Default Behavior and Backward Compatibility 562 The default behavior is that no Flow Specification is applied to a 563 tunnel. That is, the default is that the Flow Spec object is not 564 used as is the case in all systems before the implementation of this 565 specification. 567 In this case it is a local matter (such as through configuration) how 568 tunnel head ends are instructed what traffic to place on a tunnel. 570 [RFC5440]describes how receivers respond when they see unknown PCEP 571 objects. 573 8.2. Composite Flow Specifications 575 Flow Specifications may be represented by a single Flow Specification 576 TLV or may require a more complex description using multiple Flow 577 Specification TLVs. For example, a flow indicated by a source- 578 destination pair of IPv6 addresses would be described by the 579 combination of Destination IPv6 Prefix and Source IPv6 Prefix Flow 580 Specification TLVs. 582 8.3. Modifying Flow Specifications 584 A PCE may want to modify a Flow Specification associated with a 585 tunnel, or a PCC may want to report a change to the Flow 586 Specification it is using with a tunnel. 588 It is important that the specific Flow Specification is identified so 589 that it is clear that this is a modification of an existing flow and 590 not the addition of a new flow as described in Section 8.4. The FS- 591 ID field of the PCEP Flow Spec Object is used to identify a specific 592 Flow Specification. 594 When modifying a Flow Specification, all Flow Specification TLVs for 595 the intended specification of the flow MUST be included in the PCEP 596 Flow Spec Object and the FS-ID MUST be retained from the previous 597 description of the flow. 599 8.4. Multiple Flow Specifications 601 It is possible that multiple flows will be place on a single tunnel. 602 In some cases it is possible to to define these within a single PCEP 603 Flow Spec Object: for example, two Destination IPv4 Prefix TLVs could 604 be included to indicate that packets matching either prefix are 605 acceptable. PCEP would consider this as a single Flow Specification 606 identified by a single FS-ID. 608 In other scenarios the use of multiple Flow Specification TLVs would 609 be confusing. For example, if flows from A to B and from C to D are 610 to be included then using two Source IPv4 Prefix TLVs and two 611 Destination IPv4 Prefix TLVs would be confusing (are flows from A to 612 D included?). In these cases, each Flow Specification is carried in 613 its own PCEP Flow Spec Object with multiple objects present on a 614 single PCEP message. Use of separate objects also allows easier 615 removal and modification of Flow Specifications. 617 8.5. Adding and Removing Flow Specifications 619 The Remove bit in the the PCEP Flow Spec Object is left clear when a 620 Flow Specification is being added or modified. 622 To remove a Flow Specification, a PCEP Flow Spec Object is included 623 with the FS-ID matching the one being removed, and the R bit set to 624 indicate removal. In this case it is not necessary to include any 625 Flow Specification TLVs. 627 If the R bit is set and Flow Specification TLVs are present an 628 implementation MAY ignore them. If the implementation checks the 629 Flow Specification TLVs against those recorded for the FS-ID of the 630 Flow Specification being removed and finds a mismatch, the Flow 631 Specification MUST still be removed and the implementation SHOULD 632 record a local exception or log. 634 8.6. VPN Identifiers 636 VPN instances are identified in BGP using Route Distinguishers (RDs) 637 [RFC4364]. These values are not normally considered to have any 638 meaning outside of the network, and they are not encoded in data 639 packets belonging to the VPNs. However, RDs provide a useful way of 640 identifying VPN instances and are often manually or automatically 641 assigned to VPNs as they are provisioned. 643 Thus the RD provides a useful way to indicate that traffic for a 644 particular VPN should be placed on a given tunnel. The tunnel head 645 end will need to interpret this Flow Specification not as a filter on 646 the fields of data packets, but using the other mechanisms that it 647 uses to identify VPN traffic. This could be based on the incoming 648 port (for port-based VPNs) or may leverage knowledge of the VRF that 649 is in use for the taffic. 651 8.7. Priorities and Overlapping Flow Specifications 653 TBD 654 An implementation that receives a PCEP message carrying a Flow 655 Specification that it cannot resolve against other Flow 656 Specifications already installed MUST respond with a PCErr message 657 with error-type TBD8 (FlowSpec Error), error-value 3 (Unresolvable 658 conflict) and MUST NOT install the Flow Specification. 660 9. PCEP Messages 662 The figures below use the notation defined in [RFC5511]. 664 The FLOW SPEC Object is OPTIONAL and MAY be carried in the PCEP 665 messages. 667 The PCInitiate message is defined in [RFC8281] and updated as below: 669 ::= 670 672 Where: 673 ::= 674 [] 676 ::= 677 ( | 678 ) 680 ::= 681 682 [] 683 684 [] 685 [] 687 Where: 688 ::= [] 690 The PCUpd message is defined in [RFC8231] and updated as below: 692 ::= 693 695 Where: 696 ::= 697 [] 699 ::= 700 701 702 [] 704 Where: 705 ::= 707 ::= [] 709 The PCRpt message is defined in [RFC8231] and updated as below: 711 ::= 712 714 Where: 715 ::= [] 717 ::= [] 718 719 720 [] 722 Where: 723 ::= 724 [] 725 727 ::= [] 729 The PCReq message is defined in [RFC5440] and updated in [RFC8231], 730 it is further updated below for flow specification: 732 ::= 733 [] 734 736 Where: 737 ::= [] 739 ::= [] 741 ::= 742 743 [] 744 [] 745 [] 746 [] 747 [[]] 748 [] 749 [] 750 [] 752 Where: 753 ::= [] 755 The PCRep message is defined in [RFC5440] and updated in [RFC8231], 756 it is further updated below for flow specification: 758 ::= 759 761 Where: 762 ::=[] 764 ::= 765 [] 766 [] 767 [] 768 [] 769 [] 771 Where: 772 ::= [] 774 10. IANA Considerations 776 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 777 registry. This document requests IANA actions to allocate code 778 points for the protocol elements defined in this document. 780 10.1. PCEP Objects 782 Each PCEP object has an Object-Class and an Object-Type. IANA 783 maintains a subregistry called "PCEP Objects". IANA is requested to 784 make an assignment from this subregistry as follows: 786 Object-Class | Value Name | Object-Type | Reference 787 -------------+---------------+----------------------+---------------- 788 TBD3 | FLOW SPEC | 0 (Reserved) | [This.I-D] 789 | 1 | [This.I-D] 791 10.2. PCEP TLV Type Indicators 793 IANA maintains a subregistry called "PCEP TLV Type Indicators". IANA 794 is requested to make an assignment from this subregistry as follows: 796 Value | Meaning | Reference 797 --------+------------------------------+------------- 798 TBD2 | PCE-FLOWSPEC-CAPABILITY TLV | [This.I-D] 799 TBD4 | FLOW FILTER TLV | [This.I-D] 801 10.3. Flow Specification TLV Type Indicators 803 IANA is requested to create a new subregistry call the PCEP Flow 804 Specification TLV Type Indicators registry. 806 Allocations from this registry are to be made according to the 807 following assignment policies [RFC8126]: 809 Range | Assignment policy 810 ---------------+--------------------------------------------------- 811 0 | Reserved - must not be allocated. 812 | 813 1 .. 255 | Reserved - must not be allocated. 814 | Usage mirrors the BGP FlowSpec registry [RFC5575]. 815 | 816 258 .. 64506 | Specification Required 817 | 818 64507 .. 65531 | First Come First Served 819 | 820 65532 .. 65535 | Experimental 822 IANA is requested to pre-populate this registry with values defined 823 in this document as follows: 825 Value | Meaning 826 -------+------------------------ 827 TBD5 | Route Distinguisher 828 TBD6 | IPv4 Multicast 829 TBD7 | IPv6 Multicast 831 10.4. PCEP Error Codes 833 IANA maintains a subregistry called "PCEP-ERROR Object Error Types 834 and Values". Entries in this subregistry are described by Error-Type 835 and Error-value. IANA is requested to make the following assignment 836 from this subregistry: 838 Error-| Meaning | Error-value | Reference 839 Type | | | 840 -------+--------------------+----------------------------+----------- 841 TBD8 | FlowSpec error | 0: Unassigned | [This.I-D] 842 | | 1: Unsupported FlowSpec | [This.I-D] 843 | | 2: Malformed FlowSpec | [This.I-D] 844 | | 3: Unresolvable conflict | [This.I-D] 845 | | 4-255: Unassigned | [This.I-D] 847 10.5. PCE Capability Flag 849 IANA maintains a subregistry called "Open Shortest Path First v2 850 (OSPFv2) Parameters" with a sub-registry called "Path Computation 851 Element (PCE) Capability Flags". IANA is requested to assign a new 852 capability bit from this registry as follows: 854 Bit | Capability Description | Reference 855 -------+-------------------------------+------------ 856 TBD1 | FlowSpec | [This.I-D] 858 11. Security Considerations 860 We may assume that a system that utilizes a remote PCE is subject to 861 a number of vulnerabilities that could allow spurious LSPs or SR 862 paths to be established or that could result in existing paths being 863 modified or torn down. Such systems, therefore, apply security 864 considerations as described in [RFC5440], [RFC6952], and [RFC8253]. 866 The description of Flow Specifications associated with paths set up 867 or controlled by a PCE add an further detail that could be attacked 868 without tearing down LSPs or SR paths but causing traffic to be 869 misrouted within the network. Therefore, the use of the security 870 mechanisms for PCEP referenced above is important. 872 Visibility into the information carried in PCEP does not have direct 873 privacy concerns for end-users' data, however, knowledge of how data 874 is routed in a network may make that data more vulnerable. Of 875 course, the ability to interfere with the way data s routed also 876 makes the data more vulnerable. Furthermore, knowledge of the 877 connected end-points (such as multicast receivers or VPN sites) is 878 usually considered private customer information. Therefore, 879 implementations or deployments concerned to protect privacy MUST 880 apply the mechanisms described in the documents referenced above. 882 Experience with Flow Specifications in BGP systems indicates that 883 they can become complex and that the overlap of Flow Specifications 884 installed in different orders can lead to unexpected results. 885 Although this is not directly a security issue per se, the confusion 886 and unexpected forwarding behavior may be engineered or exploited by 887 an attacker. Therefore, implementers and operators SHOULD pay 888 careful attention to the Manageability Considerations described in 889 Section 12. 891 12. Manageability Considerations 893 TBD 895 13. Acknowledgements 897 Thanks to Julian Lucek and Sudhir Cheruathur for useful discussions. 899 14. References 901 14.1. Normative References 903 [I-D.dhodylee-pce-pcep-ls] 904 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 905 Distribution of Link-State and TE Information.", draft- 906 dhodylee-pce-pcep-ls-08 (work in progress), June 2017. 908 [I-D.ietf-idr-flow-spec-v6] 909 McPherson, D., Raszuk, R., Pithawala, B., 910 akarch@cisco.com, a., and S. Hares, "Dissemination of Flow 911 Specification Rules for IPv6", draft-ietf-idr-flow-spec- 912 v6-09 (work in progress), November 2017. 914 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 915 Requirement Levels", BCP 14, RFC 2119, 916 DOI 10.17487/RFC2119, March 1997, 917 . 919 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 920 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 921 DOI 10.17487/RFC5440, March 2009, 922 . 924 [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax 925 Used to Form Encoding Rules in Various Routing Protocol 926 Specifications", RFC 5511, DOI 10.17487/RFC5511, April 927 2009, . 929 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 930 and D. McPherson, "Dissemination of Flow Specification 931 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 932 . 934 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 935 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 936 May 2017, . 938 [RFC8253] Lopez, D., Gonzalez de Dios, O., Wu, Q., and D. Dhody, 939 "PCEPS: Usage of TLS to Provide a Secure Transport for the 940 Path Computation Element Communication Protocol (PCEP)", 941 RFC 8253, DOI 10.17487/RFC8253, October 2017, 942 . 944 14.2. Informative References 946 [I-D.ietf-pce-segment-routing] 947 Sivabalan, S., Filsfils, C., Tantsura, J., Henderickx, W., 948 and J. Hardwick, "PCEP Extensions for Segment Routing", 949 draft-ietf-pce-segment-routing-11 (work in progress), 950 November 2017. 952 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 953 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 954 2006, . 956 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 957 Element (PCE)-Based Architecture", RFC 4655, 958 DOI 10.17487/RFC4655, August 2006, 959 . 961 [RFC5088] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 962 Zhang, "OSPF Protocol Extensions for Path Computation 963 Element (PCE) Discovery", RFC 5088, DOI 10.17487/RFC5088, 964 January 2008, . 966 [RFC5089] Le Roux, JL., Ed., Vasseur, JP., Ed., Ikejiri, Y., and R. 967 Zhang, "IS-IS Protocol Extensions for Path Computation 968 Element (PCE) Discovery", RFC 5089, DOI 10.17487/RFC5089, 969 January 2008, . 971 [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of 972 BGP, LDP, PCEP, and MSDP Issues According to the Keying 973 and Authentication for Routing Protocols (KARP) Design 974 Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, 975 . 977 [RFC7399] Farrel, A. and D. King, "Unanswered Questions in the Path 978 Computation Element Architecture", RFC 7399, 979 DOI 10.17487/RFC7399, October 2014, 980 . 982 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 983 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 984 Multicast - Sparse Mode (PIM-SM): Protocol Specification 985 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 986 2016, . 988 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for 989 Writing an IANA Considerations Section in RFCs", BCP 26, 990 RFC 8126, DOI 10.17487/RFC8126, June 2017, 991 . 993 [RFC8231] Crabbe, E., Minei, I., Medved, J., and R. Varga, "Path 994 Computation Element Communication Protocol (PCEP) 995 Extensions for Stateful PCE", RFC 8231, 996 DOI 10.17487/RFC8231, September 2017, 997 . 999 [RFC8232] Crabbe, E., Minei, I., Medved, J., Varga, R., Zhang, X., 1000 and D. Dhody, "Optimizations of Label Switched Path State 1001 Synchronization Procedures for a Stateful PCE", RFC 8232, 1002 DOI 10.17487/RFC8232, September 2017, 1003 . 1005 [RFC8281] Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "Path 1006 Computation Element Communication Protocol (PCEP) 1007 Extensions for PCE-Initiated LSP Setup in a Stateful PCE 1008 Model", RFC 8281, DOI 10.17487/RFC8281, December 2017, 1009 . 1011 [RFC8283] Farrel, A., Ed., Zhao, Q., Ed., Li, Z., and C. Zhou, "An 1012 Architecture for Use of PCE and the PCE Communication 1013 Protocol (PCEP) in a Network with Central Control", 1014 RFC 8283, DOI 10.17487/RFC8283, December 2017, 1015 . 1017 Appendix A. Contributors 1019 Shankara 1020 Huawei Technologies 1021 Divyashree Techno Park, 1022 Whitefield Bangalore, 1023 Karnataka 1024 560066 1025 India 1027 Email: shankara@huawei.com 1029 Qiandeng Liang 1030 Huawei Technologies 1031 101 Software Avenue, 1032 Yuhuatai District 1033 Nanjing 1034 210012 1035 China 1037 Email: liangqiandeng@huawei.com 1039 Cyril Margaria 1040 Juniper Networks 1041 200 Somerset Corporate Boulevard, Suite 4001 1042 Bridgewater, NJ 1043 08807 1044 USA 1046 Email: cmargaria@juniper.net 1048 Colby Barth 1049 Juniper Networks 1050 200 Somerset Corporate Boulevard, Suite 4001 1051 Bridgewater, NJ 1052 08807 1053 USA 1055 Email: cbarth@juniper.net 1057 Xia Chen 1058 Huawei Technologies 1059 Huawei Bld., No.156 Beiqing Rd. 1060 Beijing 1061 100095 1062 China 1064 Email: jescia.chenxia@huawei.com 1066 Shunwan Zhuang 1067 Huawei Technologies 1068 Huawei Bld., No.156 Beiqing Rd. 1069 Beijing 1070 100095 1071 China 1073 Email: zhuangshunwan@huawei.com 1075 Authors' Addresses 1077 Dhruv Dhody (editor) 1078 Huawei Technologies 1079 Divyashree Techno Park, Whitefield 1080 Bangalore, Karnataka 560066 1081 India 1083 Email: dhruv.ietf@gmail.com 1084 Adrian Farrel (editor) 1085 Juniper Networks 1087 Email: afarrel@juniper.net 1089 Zhenbin Li 1090 Huawei Technologies 1091 Huawei Bld., No.156 Beiqing Rd. 1092 Beijing 100095 1093 China 1095 Email: lizhenbin@huawei.com