idnits 2.17.1 draft-li-pce-pcep-flowspec-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 8, 2016) is 2842 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'This I-D' is mentioned on line 555, but not defined ** Obsolete normative reference: RFC 5575 (Obsoleted by RFC 8955) == Outdated reference: A later version (-22) exists of draft-ietf-idr-flow-spec-v6-07 == Outdated reference: A later version (-27) exists of draft-dhodylee-pce-pcep-ls-04 ** Downref: Normative reference to an Experimental draft: draft-dhodylee-pce-pcep-ls (ref. 'I-D.dhodylee-pce-pcep-ls') == Outdated reference: A later version (-21) exists of draft-ietf-pce-stateful-pce-14 == Outdated reference: A later version (-11) exists of draft-ietf-pce-pce-initiated-lsp-06 == Outdated reference: A later version (-15) exists of draft-ietf-idr-bgp-flowspec-oid-03 Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Z. Li 3 Internet-Draft D. Dhody 4 Intended status: Standards Track Huawei Technologies 5 Expires: January 9, 2017 C. Margaria 6 C. Barth 7 Juniper 8 X. Chen 9 S. Zhuang 10 Huawei Technologies 11 July 8, 2016 13 PCEP Extension for Flow Specification 14 draft-li-pce-pcep-flowspec-01 16 Abstract 18 Dissemination of the traffic flow specifications was first introduced 19 in the BGP protocol via RFC 5575. In order to distribute the flow 20 specifications from PCE controller to network device without BGP 21 protocol it is desirable to extend PCEP with flow specification 22 information. 24 This document specifies a set of extensions to PCEP to support 25 dissemination of flow specifications. The extensions include the 26 instantiation, updation and deletion of flow specifications. 28 Requirements Language 30 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 31 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 32 document are to be interpreted as described in RFC 2119 [RFC2119]. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 9, 2017. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Procedures for Dissemination of FlowSpec . . . . . . . . . . 4 70 3.1. Overview of Procedures . . . . . . . . . . . . . . . . . 4 71 3.2. Capability Advertisement . . . . . . . . . . . . . . . . 5 72 3.3. Operations . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.4. Flowspec Synronization . . . . . . . . . . . . . . . . . 6 74 4. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . . . 6 75 4.1. PCEP FlowSpec Message . . . . . . . . . . . . . . . . . . 6 76 5. Objects and TLVs . . . . . . . . . . . . . . . . . . . . . . 7 77 5.1. OPEN Object . . . . . . . . . . . . . . . . . . . . . . . 8 78 5.1.1. PCE FlowSpec Capability TLV . . . . . . . . . . . . . 8 79 5.2. FLOW Object . . . . . . . . . . . . . . . . . . . . . . . 8 80 5.3. ACTION Object . . . . . . . . . . . . . . . . . . . . . . 11 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 82 6.1. PCEP Messages . . . . . . . . . . . . . . . . . . . . . . 12 83 6.2. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 12 84 6.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 12 85 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 87 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 9.1. Normative References . . . . . . . . . . . . . . . . . . 13 89 9.2. Informative References . . . . . . . . . . . . . . . . . 14 90 Appendix A. Contributor Addresses . . . . . . . . . . . . . . . 15 91 Appendix B. Example Usage . . . . . . . . . . . . . . . . . . . 15 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 Dissemination of the traffic flow specifications was first introduced 97 in the BGP protocol [RFC5575]. The traffic flow specification is 98 comprised of traffic filtering rules and actions. The routers which 99 received the flow specification can take advantage of the ACL (Access 100 Control List) or firewall capabilities in the router's forwarding 101 path. The routers can classify the packets according to the traffic 102 filtering rules and shape, rate limit, filter, or redirect packets 103 based on the actions. The flow specification carried by BGP can be 104 used to automate inter-domain coordination of traffic filtering to 105 mitigate (distributed) denial-of-service attacks and can also be used 106 to provide traffic filtering in the context of a BGP/MPLS VPN 107 service. 109 [RFC5575] also defines that a flow specification received from an 110 external autonomous system will need to be validated against unicast 111 routing before being accepted. [I-D.ietf-idr-bgp-flowspec-oid] 112 describes a modification to the validation procedure defined in 113 [I-D.ietf-idr-bgp-flowspec-oid] for the dissemination of BGP flow 114 specifications. The modification proposed enables flow 115 specifications to be originated from a centralized BGP route 116 controller. 118 [I-D.ietf-ospf-flowspec-extensions] defines the extensions to OSPF to 119 distribute flow specifications in the networks that only deploy an 120 IGP (Interior Gateway Protocol) (e.g., OSPF). It also defines the 121 validation procedures for imposing the filtering information on the 122 routers. 124 [RFC5440] describes the Path Computation Element Protocol (PCEP). 125 PCEP defines the communication between a Path Computation Client 126 (PCC) and a Path Control Element (PCE), or between PCE and PCE, 127 enabling computation of Multiprotocol Label Switching (MPLS) for 128 Traffic Engineering Label Switched Path (TE LSP) characteristics. 130 Stateful pce [I-D.ietf-pce-stateful-pce] specifies a set of 131 extensions to PCEP to enable stateful control of TE LSPs between and 132 across PCEP sessions in compliance with [RFC4657]. It includes 133 mechanisms to effect LSP state synchronization between PCCs and PCEs, 134 delegation of control of LSPs to PCEs, and PCE control of timing and 135 sequence of path computations within and across PCEP sessions and 136 focuses on a model where LSPs are configured on the PCC and control 137 over them is delegated to the PCE. [I-D.ietf-pce-pce-initiated-lsp] 138 describes the setup, maintenance and teardown of PCE- initiated LSPs 139 under the stateful PCE model, without the need for local 140 configuration on the PCC, thus allowing for a dynamic network that is 141 centrally controlled and deployed. 143 In case PCE is used to initiate tunnels via PCEP, it is desirable to 144 use the same protocol to also distribute the flow specifications to 145 describe what data flows on those tunnels. Thus, in order to 146 distribute the flow specifications from PCE controller to network 147 device, PCEP is extended with flow specification information in this 148 document. 150 [I-D.zhao-teas-pce-control-function] introduces the architecture for 151 PCE as a central controller and describes how PCE can be viewed as a 152 component that perfor computation to place 'flows' within the network 153 and decide how these flows are routed. 155 This document specifies a set of extensions to PCEP to support 156 dissemination of flow specifications. The flow specifications can be 157 disseminated between PCEP peers such as from PCE to PCC or between 158 PCEs . The extensions include the creation, updation and withdrawal 159 of flow specifications via PCEP. 161 The values of flow filtering rules and actions mainly refer to the 162 BGP flow specification and IGP specification. This document extends 163 new actions which are redirecting to LSP (refered by Symbolic Path 164 Name, IPv4 LSP, or IPv6 LSP). 166 2. Terminology 168 This document uses the terms defined in [RFC5440] and [RFC5575]. 170 This document uses the terms defined in [RFC5440]: PCC, PCE, PCEP 171 Peer. 173 The following term is from [RFC5575]. It is used frequently 174 throughout this document: 176 Flow Specification (FlowSpec): A flow specification is an n-tuple 177 consisting of several matching criteria that can be applied to IP 178 traffic, including filters and actions. Each FlowSpec consists of a 179 set of filters and a set of actions. 181 3. Procedures for Dissemination of FlowSpec 183 3.1. Overview of Procedures 185 A PCC or PCE indicates its ability to support PCE FlowSpec during the 186 PCEP Initialization Phase via "PCE FlowSpec Capability" TLV (see 187 details in Section 5.1.1). 189 This section introduces the procedure to support PCE FlowSpec as 190 follows: 192 Firstly both the PCE and PCC advertise the PCE FlowSpec Capability 193 during the PCE session initiation phase. 195 On the PCEP session with PCE FlowSpec Capability PCE communicates 196 with PCC to create, update and withdraw PCE FlowSpec. 198 [Editor's Note - The procedure about PCE FlowSpec synchronization, 199 the session failure process, etc. will be specified in the future 200 version.] 202 3.2. Capability Advertisement 204 During PCEP session establishment, both the PCC and the PCE must 205 announce their support of PCEP extensions for FlowSpec defined in 206 this document. 208 A PCEP Speaker (PCE or PCC) includes the "PCE FlowSpec Capability" 209 TLV, described in Section 5.1.1, in the OPEN Object to advertise its 210 support for PCEP extensions for PCE FlowSpec Capability. 212 The presence of the PCE FlowSpec Capability TLV in PCE's OPEN message 213 indicates that the PCE can support distribute the FlowSpec to PCC. 215 The presence of such Capability TLV in PCC's OPEN Object indicates 216 that the PCC can be in support of Flowspec functionality to 217 instantiate the FlowSpec according to the PCE's indication and can 218 apply the FlowSpec to the incoming packets. 220 If PCE has such capability TLV and PCC has no such capability TLV PCE 221 MUST NOT send the PCE messages with FlowSpec information. And if PCC 222 receives such messages it should send PCErr message to PCE. 224 [Editor's Note - PCE discovery via IGP should also be extended for 225 this.] 227 3.3. Operations 229 To instantiate a FlowSpec which is comprised of a set of FlowSpec 230 filter rules and actions, the PCE sends a new PCEP message (called 231 FlowSpec message) to the PCC. The FlowSpec message MUST include the 232 SRP object[I-D.ietf-pce-stateful-pce], a new FLOW object (see details 233 in Section 5.2) and a new ACTION object (see details in Section 5.3). 234 FLOW object carries a set of FlowSpec filter rules. A list of ACTION 235 objects specify a set of FlowSpec actions. 237 To update the FlowSpec actions of a specified FlowSpec which has been 238 created, the same PCEP message "FlowSpec" is used. The PCE sends a 239 FlowSpec message to the PCC. The FlowSpec message MUST include the 240 SRP object, FLOW object and ACTION object. 242 To delete the specified FlowSpec which has been created, the PCE 243 sends a FlowSpec message to the PCC with a flag indicating the 244 removal action. The FlowSpec message MUST include the SRP object 245 (with R flag set) and FLOW object. 247 3.4. Flowspec Synronization 249 [I-D.kuppani-pce-pcep-flowspec-sync] specify the flow specification 250 synchronization mechanism for managing of flow specification 251 (FLOWSPEC-DB) at node (PCC) aligning with FLOWSPEC-DB at PCE on 252 initial session UP or session flap and specifies the required Path 253 Computation Element Communication Protocol (PCEP) extensions. This 254 includes full synchronization as well as optimizations such as 255 synchronization avoidance and incremental synchronization. 257 4. PCEP Messages 259 As defined in [RFC5440], a PCEP message consists of a common header 260 followed by a variable-length body made of a set of objects that can 261 be either mandatory or optional. An object is said to be mandatory 262 in a PCEP message when the object must be included for the message to 263 be considered valid. For each PCEP message type, a set of rules is 264 defined that specify the set of objects that the message can carry. 265 An implementation MUST form the PCEP messages using the object 266 ordering specified in this document. 268 To support the PCEP FlowSpec functionality one new PCEP messages is 269 introduced. 271 4.1. PCEP FlowSpec Message 273 A FlowSpec message which is also referred to as FlowSpec message is a 274 PCEP message sent by a PCE to a PCC to trigger creation, modification 275 or deletion of a FlowSpec. 277 The Message-Type field of the PCEP common header for the FlowSpec 278 message is TBD17 (to be assigned by IANA). The FlowSpec message MUST 279 include the SRP and the FLOW objects. 281 If FlowSpec message is used to create or update the FlowSpec, it MUST 282 include the ACTION objects too. 284 If FlowSpec message is used to delete the FlowSpec the ACTION objects 285 SHOULD NOT be carried and the SRP object is set with the R flag. 287 A FlowSpec is identified by a PCEP specific identifier FS-ID. 289 The format of a FlowSpec message for creation or deletion of FlowSpec 290 is as follows: 292 ::= 293 294 Where: 295 ::= [] 297 ::= (| 298 ) 300 ::= 301 302 304 ::= 305 307 Where: 308 ::=[] 310 The SRP object defined in [I-D.ietf-pce-stateful-pce] can be used in 311 this document to correlate FlowSpec requests sent by the PCE with the 312 error reports sent by the PCC. 314 Every FlowSpec requests from the PCE sends a new SRP-ID-NUMBER as 315 described in [I-D.ietf-pce-stateful-pce]. This number is unique per 316 PCEP session and is incremented each time an FlowSpec operation 317 (creation, update, deletion etc) is requested from the PCE. The 318 value of the SRP-ID-NUMBER MAY be echoed back by the PCC in PCErr 319 messages to allow for correlation between requests made by the PCE 320 and errors generated by the PCC. Procedure of dissemination of 321 FlowSpec from PCE share the same number space of the SRP-ID-NUMBER 322 with procedure of stateful PCE. 324 The FLOW and ACTION objects are new objects introduced in this 325 document. 327 5. Objects and TLVs 329 The PCEP objects defined in this document are compliant with the PCEP 330 object format defined in [RFC5440]. 332 New TLVs about FlowSpec filtering rules are defined. The value 333 portion of the new TLVs can reuse the structure defined in [RFC5575] 334 and [I-D.ietf-idr-flow-spec-v6]. New TLVs about FlowSpec actions are 335 also defined. The value portion of the new TLVs can reuse the 336 structure defined in [I-D.ietf-ospf-flowspec-extensions]. This 337 document also defines two new actions: Redirect to IPv4 LSP and 338 Redirect to IPv6 LSP. 340 5.1. OPEN Object 342 5.1.1. PCE FlowSpec Capability TLV 344 The PCE-FLOWSPEC-CAPABILITY TLV is an optional TLV associated with 345 the OPEN Object [RFC5440] to exchange PCE FlowSpec capability of PCEP 346 speakers. 348 Its format is shown in the following figure: 350 0 1 2 3 351 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 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Type=[TBD18] | Length=2 | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Value=0 | padding | 356 +---------------------------------------------------------------+ 358 Figure 1: PCE-FLOWSPEC-CAPABILITY TLV format 360 The type of the TLV is TBD18 (to be assigned by IANA) and it has a 361 fixed length of 2 octets. The value field is set to default value 0. 363 The inclusion of this TLV in an OPEN object indicate that the sender 364 can perform FlowSpec handling in PCEP. 366 5.2. FLOW Object 368 The FLOW object MUST be present within FlowSpec messages. The FLOW 369 object carries a set of FlowSpec filter rules. 371 FLOW Object-Class is TBD19 (to be assigned by IANA). 373 FLOW Object-Type is 1. 375 The format of the FLOW object is as follows: 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | FS-ID | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | | 383 | Flow Filter TLVs(variable) | 384 | | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 Figure 2: FLOW Object Body Format 389 FS-ID(32-bit): A PCEP-specific identifier for the FlowSpec 390 information. A PCE creates an unique FS-ID for each FlowSpec that is 391 constant for the lifetime of a PCEP session. All subsequent PCEP 392 messages then address the FlowSpec by the FS-ID. The values of 0 and 393 0xFFFFFFFF are reserved. 395 Flow Filter TLVs(variable): The FLOW object body has a variable 396 length and may contain one or more additional TLVs. 398 The following flow filter types are supported: 400 +------+------------------------+-------+--------------------------+ 401 | Type | Description |Ref TLV|Value defined in | 402 +------+------------------------+-------+--------------------------+ 403 | TBD1 | Destination IPv4 Prefix| 1 |RFC5575 | 404 +------+------------------------+-------+--------------------------+ 405 | TBD2 | Source IPv4 Prefix | 2 |RFC5575 | 406 +------+------------------------+-------+--------------------------+ 407 | TBD3 | IP Protocol | 3 |RFC5575 | 408 +------+------------------------+-------+--------------------------+ 409 | TBD4 | Port | 4 |RFC5575 | 410 +------+------------------------+-------+--------------------------+ 411 | TBD5 | Destination port | 5 |RFC5575 | 412 +------+------------------------+-------+--------------------------+ 413 | TBD6 | Source port | 6 |RFC5575 | 414 +------+------------------------+-------+--------------------------+ 415 | TBD7 | ICMP type | 7 |RFC5575 | 416 +------+------------------------+-------+--------------------------+ 417 | TBD8 | ICMP code | 8 |RFC5575 | 418 +------+------------------------+-------+--------------------------+ 419 | TBD9 | TCP flags | 9 |RFC5575 | 420 +------+------------------------+-------+--------------------------+ 421 | TBD10| Packet length | 10 |RFC5575 | 422 +------+------------------------+-------+--------------------------+ 423 | TBD11| DSCP | 11 |RFC5575 | 424 +------+------------------------+-------+--------------------------+ 425 | TBD12| Fragment | 12 |RFC5575 | 426 +------+------------------------+-------+--------------------------+ 427 | TBD13| Flow Label | 13 |I-D.ietf-idr-flow-spec-v6 | 428 +------+------------------------+-------+--------------------------+ 429 | TBD14| Destination IPv6 Prefix| 1 |I-D.ietf-idr-flow-spec-v6 | 430 +------+------------------------+-------+--------------------------+ 431 | TBD15| Source IPv6 Prefix | 2 |I-D.ietf-idr-flow-spec-v6 | 432 +------+------------------------+-------+--------------------------+ 433 | TBD16| Next Header | 3 |I-D.ietf-idr-flow-spec-v6 | 434 +------+------------------------+-------+--------------------------+ 435 | * | ROUTE-DISTINGUISHER | - |I-D.dhodylee-pce-pcep-ls | 436 +------+------------------------+-------+--------------------------+ 438 (*) - TLV is defined in another PCEP document. 440 Figure 3: Table of Flow Filter Types 442 [RFC5575] and [I-D.ietf-idr-flow-spec-v6] specify the above types for 443 BGP. The encoding for "Destination Prefix" is described in [RFC5575] 444 as - 446 Encoding: 447 In PCEP, the type of flow filter is identified by the type field in 448 the TLV header, TBD1 in case of Destination Prefix. The length field 449 in the TLV header (as per [RFC5440]) is the length of the value 450 portion in octets without padding. The value portion for 451 "Destination IPv4 Prefix" is made up of 1 octet of prefix length 452 followed by the prefix, padded to 4-byte alignment for the TLV. 454 Similarly for all encoding defined in [RFC5575] and 455 [I-D.ietf-idr-flow-spec-v6], the value portion of the PCEP TLV uses 456 the BGP encoding but without the type octet and pad it to 4-byte 457 alignment. 459 [I-D.dhodylee-pce-pcep-ls] allow identificatiion of a VPN information 460 in PCEP via a Route Distinguisher (RD) [RFC4364] and encoded in 461 ROUTE-DISTINGUISHER TLV. This TLV MAY be included in the FLOW object 462 to identify the flow filter infomration, say a IPv4 destination 463 prefix, is a VPNv4 destination prefix belonging to the VPN identified 464 by the RD. 466 5.3. ACTION Object 468 The ACTION object MUST be present within FlowSpec messages when 469 creating or updating the FlowSpec. The ACTION object carries a set 470 of FlowSpec actions. 472 ACTION Object-Class is TBD20 (to be assigned by IANA). 474 ACTION Object-Type is 1. 476 The format of the ACTION object body is: 478 0 1 2 3 479 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 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | | 482 | ACTION TLVs(variable) | 483 | | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 Figure 4: ACTION Object Body Format 488 The ACTION object body has a variable length and may contain one or 489 more additional TLVs. 491 The following FlowSpec action types are supported: 493 +------+---------------------+-------------------------+ 494 | Type | Description |Defined in | 495 +------+---------------------+-------------------------+ 496 | 18(*)| IPV4-LSP-IDENTIFIERS|I-D.ietf-pce-stateful-pce| 497 +------+---------------------+-------------------------+ 498 | 19(*)| IPV6-LSP-IDENTIFIERS|I-D.ietf-pce-stateful-pce| 499 +------+---------------------+-------------------------+ 500 | 17(*)| Symbolic-Path-Name |I-D.ietf-pce-stateful-pce| 501 +------+---------------------+-------------------------+ 503 (*) The type is defined in [I-D.ietf-pce-stateful-pce] 505 Figure 5: Flow Action Types 507 6. IANA Considerations 509 IANA maintains the "Path Computation Element Protocol (PCEP) Numbers" 510 registry at . This document 511 requests IANA actions to allocate code points for the protocol 512 elements defined in this document. 514 6.1. PCEP Messages 516 IANA maintains a subregistry for PCEP messages called "PCEP 517 Messages". Each PCEP message has a message type value. This 518 document defines a new PCEP message type value. 520 Value Meaning Reference 521 TBD17 FlowSpec [This I-D] 523 6.2. PCEP Objects 525 Each PCEP object has an Object-Class and an Object-Type. IANA 526 maintains a subregistry called "PCEP Objects". This document defines 527 the following new PCEP Object-classes and Object-values: 529 Object-Class Value Name Object-Type Reference 530 TBD19 FLOW 1 [This I-D] 531 TBD20 ACTION 1 [This I-D] 533 6.3. PCEP TLV Type Indicators 535 IANA maintains a subregistry called "PCEP TLV Type Indicators". This 536 document defines the following new PCEP TLVs. 538 Value Meaning Reference 539 TBD18 PCE-FLOWSPEC-CAPABILITY TLV [This I-D] 540 TBD1 Destination IPv4 Prefix [This I-D] 541 TBD2 Source IPv4 Prefix [This I-D] 542 TBD3 IP Protocol [This I-D] 543 TBD4 Port [This I-D] 544 TBD5 Destination port [This I-D] 545 TBD6 Source port [This I-D] 546 TBD7 ICMP type [This I-D] 547 TBD8 ICMP code [This I-D] 548 TBD9 TCP flags [This I-D] 549 TBD10 Packet length [This I-D] 550 TBD11 DSCP [This I-D] 551 TBD12 Fragment [This I-D] 552 TBD13 Flow Label [This I-D] 553 TBD14 Destination IPv6 Prefix [This I-D] 554 TBD15 Source IPv6 Prefix [This I-D] 555 TBD16 Next Header [This I-D] 557 7. Security Considerations 559 TBD. 561 8. Acknowledgements 563 TBD. 565 9. References 567 9.1. Normative References 569 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 570 Requirement Levels", BCP 14, RFC 2119, 571 DOI 10.17487/RFC2119, March 1997, 572 . 574 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 575 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 576 DOI 10.17487/RFC5440, March 2009, 577 . 579 [RFC5575] Marques, P., Sheth, N., Raszuk, R., Greene, B., Mauch, J., 580 and D. McPherson, "Dissemination of Flow Specification 581 Rules", RFC 5575, DOI 10.17487/RFC5575, August 2009, 582 . 584 [I-D.ietf-idr-flow-spec-v6] 585 McPherson, D., Raszuk, R., Pithawala, B., 586 akarch@cisco.com, a., and S. Hares, "Dissemination of Flow 587 Specification Rules for IPv6", draft-ietf-idr-flow-spec- 588 v6-07 (work in progress), March 2016. 590 [I-D.dhodylee-pce-pcep-ls] 591 Dhody, D., Lee, Y., and D. Ceccarelli, "PCEP Extension for 592 Distribution of Link-State and TE Information.", draft- 593 dhodylee-pce-pcep-ls-04 (work in progress), July 2016. 595 9.2. Informative References 597 [RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private 598 Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 599 2006, . 601 [RFC4657] Ash, J., Ed. and J. Le Roux, Ed., "Path Computation 602 Element (PCE) Communication Protocol Generic 603 Requirements", RFC 4657, DOI 10.17487/RFC4657, September 604 2006, . 606 [I-D.ietf-pce-stateful-pce] 607 Crabbe, E., Minei, I., Medved, J., and R. Varga, "PCEP 608 Extensions for Stateful PCE", draft-ietf-pce-stateful- 609 pce-14 (work in progress), March 2016. 611 [I-D.ietf-pce-pce-initiated-lsp] 612 Crabbe, E., Minei, I., Sivabalan, S., and R. Varga, "PCEP 613 Extensions for PCE-initiated LSP Setup in a Stateful PCE 614 Model", draft-ietf-pce-pce-initiated-lsp-06 (work in 615 progress), July 2016. 617 [I-D.ietf-idr-bgp-flowspec-oid] 618 Uttaro, J., Filsfils, C., Smith, D., Alcaide, J., and P. 619 Mohapatra, "Revised Validation Procedure for BGP Flow 620 Specifications", draft-ietf-idr-bgp-flowspec-oid-03 (work 621 in progress), March 2016. 623 [I-D.ietf-ospf-flowspec-extensions] 624 liangqiandeng, l., You, J., Wu, N., Fan, P., Patel, K., 625 and A. Lindem, "OSPF Extensions for Flow Specification", 626 draft-ietf-ospf-flowspec-extensions-01 (work in progress), 627 April 2016. 629 [I-D.kuppani-pce-pcep-flowspec-sync] 630 Kuppani, S. and A. Sinha, "PCEP Flowspec Synchronization 631 Procedures.", draft-kuppani-pce-pcep-flowspec-sync-00 632 (work in progress), May 2016. 634 [I-D.zhao-teas-pce-control-function] 635 Farrel, A., Zhao, Q., Li, Z., and C. Zhou, "An 636 Architecture for Use of PCE and PCEP in a Network with 637 Central Control", draft-zhao-teas-pce-control-function-01 638 (work in progress), May 2016. 640 Appendix A. Contributor Addresses 642 Shankara 643 Huawei Technologies 644 Divyashree Techno Park, Whitefield 645 Bangalore, Karnataka 560066 646 India 647 Email: shankara@huawei.com 648 Qiandeng Liang 649 Huawei Technologies 650 101 Software Avenue, Yuhuatai District 651 Nanjing 210012 652 China 653 Email: liangqiandeng@huawei.com 655 Appendix B. Example Usage 657 Once PCE initiate tunnels, it needs to further decide what data needs 658 to flow on the newly created tunnel, a flow specification can be 659 created at the ingress to redirect the flow to the LSP as shown 660 below. 662 ***** 663 *PCE* 664 /***** 665 / 666 / 667 / 668 / 669 / 670 / 1. PCInitiate 671 / Message to 672 / initiate LSP 673 / (RTA-RTD) 674 / 675 / 676 / 677 V 678 +----+ +----+ +----+ +----+ 679 |RTA |----------|RTB |----------|RTC |----------|RTD | 680 | | | | | | | | 681 +----+ +----+ +----+ +----+ 682 PCC 683 Ingress 685 ***** 686 *PCE* 687 /***** 688 / 689 / 690 / 691 / 692 / 693 / 2. FlowSpec 694 / Message to add flow 695 / (source - x.x.x.x, port - y) 696 / to redirect to LSP 697 / (RTA-RTD) 698 / 699 / 700 V 701 +----+ +----+ +----+ +----+ 702 |RTA |----------|RTB |----------|RTC |----------|RTD | 703 | | | | | | | | 704 +----+ +----+ +----+ +----+ 705 PCC 706 Ingress 708 Authors' Addresses 710 Zhenbin Li 711 Huawei Technologies 712 Huawei Bld., No.156 Beiqing Rd. 713 Beijing 100095 714 China 716 Email: lizhenbin@huawei.com 718 Dhruv Dhody 719 Huawei Technologies 720 Divyashree Techno Park, Whitefield 721 Bangalore, Karnataka 560066 722 India 724 Email: dhruv.ietf@gmail.com 726 Cyril Margaria 727 Juniper 728 200 Somerset Corporate Boulevard, , Suite 4001 729 Bridgewater, NJ 08807 730 USA 732 Email: cmargaria@juniper.net 734 Colby Barth 735 Juniper 736 200 Somerset Corporate Boulevard, , Suite 4001 737 Bridgewater, NJ 08807 738 USA 740 Email: cbarth@juniper.net 742 Xia Chen 743 Huawei Technologies 744 Huawei Bld., No.156 Beiqing Rd. 745 Beijing 100095 746 China 748 Email: jescia.chenxia@huawei.com 749 Shunwan Zhuang 750 Huawei Technologies 751 Huawei Bld., No.156 Beiqing Rd. 752 Beijing 100095 753 China 755 Email: zhuangshunwan@huawei.com