idnits 2.17.1 draft-chen-bier-pce-bier-04.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 : ---------------------------------------------------------------------------- ** There are 16 instances of too long lines in the document, the longest one being 21 characters in excess of 72. ** The abstract seems to contain references ([I-D.ietf-bier-architecture]), 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 (February 6, 2018) is 2243 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 369, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-pce-lsp-setup-type-08 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Networking Working Group Ran. Chen 3 Internet-Draft Zheng. Zhang 4 Intended status: Standards Track ZTE Corporation 5 Expires: August 10, 2018 February 6, 2018 7 PCEP Extensions for BIER 8 draft-chen-bier-pce-bier-04 10 Abstract 12 Bit Index Explicit Replication (BIER)-TE shares architecture and 13 packet formats with BIER as described in 14 [I-D.ietf-bier-architecture]. BIER-TE forwards and replicates 15 packets based on a BitString in the packet header, but every 16 BitPosition of the BitString of a BIER-TE packet indicates one or 17 more adjacencies.BIER-TE Path can be derived from a Path Computation 18 Element (PCE). 20 This document specifies extensions to the Path Computation Element 21 Protocol (PCEP) to handle requests and responses for the computation 22 of paths for BIER-TE. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on August 10, 2018. 41 Copyright Notice 43 Copyright (c) 2018 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Conventions used in this document . . . . . . . . . . . . . . 3 60 3. Overview of PCEP Operation in BIER Networks . . . . . . . . . 3 61 4. BIER PCEP Message Extensions . . . . . . . . . . . . . . . . 3 62 4.1. BIER Capability Advertisement . . . . . . . . . . . . . . 3 63 4.1.1. The OPEN Object . . . . . . . . . . . . . . . . . . . 3 64 4.1.1.1. The BIER PCE Capability TLV . . . . . . . . . . . 3 65 4.2. Path Computation Request/Reply Message Extensions . . . . 4 66 4.2.1. The RP/SPR Object . . . . . . . . . . . . . . . . . . 4 67 4.2.2. The New BIER END-POINT Object . . . . . . . . . . . . 5 68 4.2.3. ERO Object . . . . . . . . . . . . . . . . . . . . . 5 69 4.2.3.1. BIER-ERO Subobject . . . . . . . . . . . . . . . 6 70 4.2.4. RRO Object . . . . . . . . . . . . . . . . . . . . . 7 71 4.2.4.1. RRO Processing . . . . . . . . . . . . . . . . . 7 72 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 74 6.1. PCEP Objects . . . . . . . . . . . . . . . . . . . . . . 7 75 6.2. PCEP-Error Objects and Types . . . . . . . . . . . . . . 8 76 6.3. PCEP TLV Type Indicators . . . . . . . . . . . . . . . . 8 77 6.4. New Path Setup Type . . . . . . . . . . . . . . . . . . . 8 78 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 79 7.1. Normative references . . . . . . . . . . . . . . . . . . 9 80 7.2. Informative references . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 Bit Index Explicit Replication (BIER)-TE shares architecture and 86 packet formats with BIER as described in 87 [I-D.ietf-bier-architecture]. BIER-TE forwards and replicates 88 packets based on a BitString in the packet header, but every 89 BitPosition of the BitString of a BIER-TE packet indicates one or 90 more adjacencies.BIER-TE Path can be derived from a Path Computation 91 Element (PCE). 93 This document specifies extensions to the Path Computation Element 94 Protocol (PCEP) to handle requests and responses for the computation 95 of paths for BIER-TE. 97 2. Conventions used in this document 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 3. Overview of PCEP Operation in BIER Networks 105 BIER-TE forwards and replicates packets based on a BitString in the 106 packet header. In a PCEP session, An ERO object specified in 107 [RFC5440] can be extended to carry a BIER-TE path consists of one or 108 more BIER-ERO subobject(s). BIER-TE computed by a PCE can be 109 represented in the following forms: 111 o An ordered set of adjacencies BitString(s) in which each bit 112 represents that the adjacencies to which the BFR should replicate 113 packets to in the domain. 115 In this document, we define a set of PCEP protocol extensions, 116 including a new PCEP capability,a new Path Setup Type (PST) ,a new 117 BIER END-POINT Object, new ERO subobjects, new RRO subobjects, new 118 PCEP error codes and procedures. 120 4. BIER PCEP Message Extensions 122 The following section describes the protocol extensions required to 123 support BIER-TE path. 125 4.1. BIER Capability Advertisement 127 4.1.1. The OPEN Object 129 This document defines a new optional TLV for use in the OPEN Object. 131 4.1.1.1. The BIER PCE Capability TLV 133 The BIER-PCE-CAPABILITY TLV is an optional TLV associated with the 134 OPEN Object to exchange BIER capability of PCEP speakers. The format 135 of the BIER-PCE-CAPABILITY TLV is shown in the following figure: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Type | Length | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Reserved | Flags | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 Figure 1 147 The code point for the TLV type is to be defined by IANA. 149 Length: 4 bytes. 151 The "Reserved" (2 octet) and "Flags" (2 octet) fields are currently 152 unused, and MUST be set to zero on transmission and ignored on 153 reception. 155 4.1.1.1.1. Exchanging BIER Capability 157 This document defines a new optional BIER-PCE-CAPABILITY TLV for use 158 in the OPEN object to negotiate the BIER capability. The inclusion 159 of this TLV in the OPEN message destined to a PCC indicates the PCE's 160 capability to perform BIER-TE path computations, and the inclusion of 161 this TLV in the OPEN message destined to a PCE indicates the PCC's 162 capability to support BIER-TE Path. 164 A PCE that is able to support the BIER extensions defined in this 165 document SHOULD include the BIER-PCE-CAPABILITY TLV on the OPEN 166 message. If the PCE does not include the BIER-PCE-CAPABILITY TLV in 167 the OPEN message and PCC does include the TLV, it is RECOMMENDED that 168 the PCC indicates a mismatch of capabilities. 170 4.2. Path Computation Request/Reply Message Extensions 172 4.2.1. The RP/SPR Object 174 In order to setup an BIER-TE, a new PATH-SETUP-TYPE 175 TLV[I-D.ietf-pce-lsp-setup-type] MUST be contained in RP or SRP 176 object. This document defines a new Path Setup Type (PST) for BIER 177 as follows: 179 o PST = 2: Path is setup using BIER Traffic Engineering technique. 181 If a PCEP speaker does not recognize the PATH-SETUP-TYPE TLV, it MUST 182 ignore the TLV in accordance with [RFC5440]. If a PCEP speaker 183 recognizes the TLV but does not support the TLV, it MUST send PCErr 184 with Error-Type = 2 (Capability not supported). 186 4.2.2. The New BIER END-POINT Object 188 The END-POINTS object is used in a PCReq message to specify the BIER 189 information of the path for which a path computation is requested. 190 To represent the end points for a BIER path efficiently, we define a 191 new END-POINT Object for the BIER path: 193 The format of the new END-POINTS Object is as follows: 195 0 1 196 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 |Subdomain-ID | BS Length | Source BFR-id | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Destination BFR-id ~ ... ~ 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 ~ ... ~ Destination BFR-id | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Figure 2 207 Subdomain-id: Unique value identifying the BIER sub-domain. 1 octet 209 BS Length: A 1 octet field encoding the supported BitString length. 211 Source BFR-id:A 2 octet field encoding the source BFR-id. 213 Destniation BFR-id:A 2 octet field encoding the destniation BFR-id. 215 4.2.3. ERO Object 217 BIER-TE consists of one or more adjacencies BitStrings where every 218 BitPosition of the BitString indicates one or more adjacencies, as 219 described in([I-D.eckert-bier-te-arch]). 221 The ERO object specified in [RFC5440] is used to encode the path of a 222 TE LSP through the network.The ERO is carried within a PCRep message 223 to provide the computed TE LSP if the path computation was 224 successful.In order to carry BIER-TE explicit paths, this document 225 defines a new ERO subobjects referred to as "BIER-ERO subobjects" 226 whose formats are specified in the following section. An BIER-ERO 227 subobjects carrying a adjacencies BitStrings consists of one or more 228 BIER-ERO subobject(s). 230 4.2.3.1. BIER-ERO Subobject 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Type | Length | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | BS Length | Reserved | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Adjacency BitString | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 3 244 Type: TBD 246 Length: 4 bytes 248 BS Length: A 1 octet field encoding the supported BitString length. 250 The "Reserved" (1 octets) fields are currently unused, and MUST be 251 set to zero on transmission and ignored on reception. 253 Adjacency BitString: A 4 octet field encoding the Adjacency BitString 254 where every BitPosition of the BitString indicates one or more 255 adjacencies. 257 4.2.3.1.1. BIER-ERO Processing 259 If a PCC finds a non-recognize the BIER-ERO subobject, the PCC MUST 260 respond with a PCErr message with Error-Type=3 ("Unknown Object") and 261 Error-Value=2 ("Unrecognized object Type") or Error-Type=4 ("Not 262 supported object") and Error-Value=2 ("Not supported object Type") as 263 described in [RFC5440] . 265 If a PCC receives an BIER-ERO subobject in which either 266 BitStringLength or Adjacency BitString is absent, it MUST consider 267 the entire BIER-ERO subobject invalid and send a PCErr message with 268 Error-Type = 10 ("Reception of an invalid object") and Error-Value = 269 TBD ("BitStringLength is absent ") and Error-Value = TBD ("Adjacency 270 BitString is absent ") 272 If a PCC detects that all subobjects of BIER-ERO are not identical, 273 it MUST send a PCErr message with Error-Type = 10 ("Reception of an 274 invalid object") and Error-Value = TBD ("Non-identical BIER-ERO 275 subobjects"). 277 If a PCC receives an BIER-ERO subobject in which BitStringLength 278 values are not chosen from: 64, 128, 256, 512, 1024, 2048, and 4096, 279 as it described in ([I-D.ietf-bier-architecture]). The PCC MUST send 280 a PCErr message with Error-Type = 10 ("Reception of an invalid 281 object") and Error-Value = TBD ("Invalid BitStringLength"). 283 4.2.4. RRO Object 285 A PCC can record BIER-ERO explicit paths and report the paths to a 286 PCE via RRO. An RRO object contains one or more subobjects called 287 "BIER-RRO subobjects" whose formats are the same as that of BIER-ERO 288 subobject. 290 4.2.4.1. RRO Processing 292 Processing rules of BIER-RRO subobject are identical to those of 293 BIER-ERO subobject defined in section 4.2.3.1 in this document. 295 5. Security Considerations 297 TBD. 299 6. IANA Considerations 301 6.1. PCEP Objects 303 As discussed in Section 4.2.2, a new END-POINTS Object-Type is 304 defined. IANA has made the following Object-Type allocations from 305 the "PCEP Objects" sub-registry: 307 Object Object-Class Value 308 --------------------- -------------------------- 309 BIER END-POINT Object TBD 311 As discussed in Section 4.2.3 and 4.2.4, a new sub-object type for 312 the PCEP explicit route object (ERO), and a new sub-object type for 313 the PCEP record route object (RRO) are defined. 315 IANA has made the following sub-objects allocation from the RSVP 316 Parameters registry: 318 Object Sub-Object Sub-Object Type 319 --------------------- -------------------------- -------------------------- 320 EXPLICIT_ROUTE BIER-ERO (PCEP-specific) TBD 321 ROUTE_RECORD BIER-RRO (PCEP-specific) TBD 323 6.2. PCEP-Error Objects and Types 325 As described in Section 4.2.3.1.1, a number of new PCEP-ERROR Object 326 Error Values have been defined. 328 Error-Type Meaning Reference 329 ---------- ----------------------------------- --------------------------------- 330 10 Reception of an invalid object. RFC5540 331 Error-value = TBD: BitStringLength is absent This document 332 Error-value = TBD: BitString is absent This document 333 Error-value = TBD: Invalid BitStringLength This document 335 6.3. PCEP TLV Type Indicators 337 IANA is requested to allocate a new code point in the PCEP TLV Type 338 Indicators registry, as follows: 340 Value Meaning Reference 341 -------------------- ---------------------------- ----------------------------------- 342 TBD BIER-PCE-CAPABILITY TLV This document 344 6.4. New Path Setup Type 346 IANA is requested to allocate a new code point in the PCEP 347 PATH_SETUP_TYPE TLV PST field registry, as follows: 349 Value Description Reference 350 ---------------- ------------------------------------ ---------------------------- 351 2 Path is setup using BIER Traffic This document 352 Engineering technique 354 7. References 355 7.1. Normative references 357 [I-D.ietf-bier-architecture] 358 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 359 S. Aldrin, "Multicast using Bit Index Explicit 360 Replication", draft-ietf-bier-architecture-08 (work in 361 progress), September 2017. 363 [I-D.ietf-pce-lsp-setup-type] 364 Sivabalan, S., Tantsura, J., Minei, I., Varga, R., and J. 365 Hardwick, "Conveying path setup type in PCEP messages", 366 draft-ietf-pce-lsp-setup-type-08 (work in progress), 367 January 2018. 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, 371 DOI 10.17487/RFC2119, March 1997, 372 . 374 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 375 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 376 DOI 10.17487/RFC5440, March 2009, 377 . 379 7.2. Informative references 381 [I-D.eckert-bier-te-arch] 382 Eckert, T., Cauchie, G., Braun, W., and M. Menth, "Traffic 383 Engineering for Bit Index Explicit Replication BIER-TE", 384 draft-eckert-bier-te-arch-06 (work in progress), November 385 2017. 387 Authors' Addresses 389 Ran Chen 390 ZTE Corporation 391 No.50 Software Avenue,Yuhuatai District 392 Nanjing, Jiangsu Province 210012 393 China 395 Phone: +86 025 88014636 396 Email: chen.ran@zte.com.cn 397 Zheng Zhang 398 ZTE Corporation 399 No.50 Software Avenue,Yuhuatai District 400 Nanjing, Jiangsu Province 210012 401 China 403 Email: zhang.zheng@zte.com.cn