idnits 2.17.1 draft-kumarzheng-bier-ping-00.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 (March 5, 2015) is 3339 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: 'RFC0792' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'RFC6291' is defined on line 821, but no explicit reference was found in the text == Unused Reference: 'RFC6424' is defined on line 825, but no explicit reference was found in the text == Unused Reference: 'RFC6425' is defined on line 829, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-wijnands-bier-architecture-04 ** Obsolete normative reference: RFC 4379 (Obsoleted by RFC 8029) -- Obsolete informational reference (is this intentional?): RFC 6424 (Obsoleted by RFC 8029) Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Work group N. Kumar 3 Internet-Draft C. Pignataro 4 Intended status: Standards Track N. Akiya 5 Expires: September 6, 2015 Cisco Systems, Inc. 6 L. Zheng 7 M. Chen 8 Huawei Technologies 9 G. Mirsky 10 Ericsson 11 March 5, 2015 13 BIER Ping and Trace 14 draft-kumarzheng-bier-ping-00 16 Abstract 18 Bit Index Explicit Replication (BIER) is an architecture that 19 provides optimal multicast forwarding through a "BIER domain" without 20 requiring intermediate routers to maintain any multicast related per- 21 flow state. BIER also does not require any explicit tree-building 22 protocol for its operation. A multicast data packet enters a BIER 23 domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the 24 BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). 25 The BFIR router adds a BIER header to the packet. The BIER header 26 contains a bit-string in which each bit represents exactly one BFER 27 to forward the packet to. The set of BFERs to which the multicast 28 packet needs to be forwarded is expressed by setting the bits that 29 correspond to those routers in the BIER header. 31 This document describes the mechanism and basic BIER OAM packet 32 format that can be used to perform failure detection and isolation on 33 BIER data plane. 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on September 6, 2015. 51 Copyright Notice 53 Copyright (c) 2015 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 69 2. Conventions used in this document . . . . . . . . . . . . . . 3 70 2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 71 2.2. Requirements notation . . . . . . . . . . . . . . . . . . 3 72 3. BIER OAM . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3.1. BIER OAM message format . . . . . . . . . . . . . . . . . 4 74 3.2. Return Code . . . . . . . . . . . . . . . . . . . . . . . 6 75 3.3. BIER OAM TLV . . . . . . . . . . . . . . . . . . . . . . 7 76 3.3.1. Original SI-BitString TLV . . . . . . . . . . . . . . 7 77 3.3.2. Target SI-BitString TLV . . . . . . . . . . . . . . . 8 78 3.3.3. Incoming SI-BitString TLV . . . . . . . . . . . . . . 9 79 3.3.4. Downstream Mapping TLV . . . . . . . . . . . . . . . 10 80 3.3.5. Responder BFER TLV . . . . . . . . . . . . . . . . . 12 81 3.3.6. Responder BFR TLV . . . . . . . . . . . . . . . . . . 13 82 3.3.7. Upstream Interface TLV . . . . . . . . . . . . . . . 14 83 4. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 4.1. BIER OAM processing . . . . . . . . . . . . . . . . . . . 14 85 4.2. Per BFER ECMP Discovery . . . . . . . . . . . . . . . . . 15 86 4.3. Sending BIER Echo Request . . . . . . . . . . . . . . . . 15 87 4.4. Receiving BIER Echo Request . . . . . . . . . . . . . . . 16 88 4.5. Sending Echo Reply . . . . . . . . . . . . . . . . . . . 17 89 4.6. Receiving Echo Reply . . . . . . . . . . . . . . . . . . 17 90 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 91 5.1. Message Types, Reply Modes, Return Codes . . . . . . . . 17 92 5.2. TLVs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 94 7. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . 18 95 8. Contributing Authors . . . . . . . . . . . . . . . . . . . . 18 96 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 97 9.1. Normative References . . . . . . . . . . . . . . . . . . 18 98 9.2. Informative References . . . . . . . . . . . . . . . . . 19 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 101 1. Introduction 103 [I-D.wijnands-bier-architecture] introduces and explains BIER 104 architecture that provides optimal multicast forwarding through a 105 "BIER domain" without requiring intermediate routers to maintain any 106 multicast related per-flow state. BIER also does not require any 107 explicit tree-building protocol for its operation. A multicast data 108 packet enters a BIER domain at a "Bit-Forwarding Ingress Router" 109 (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding 110 Egress Routers" (BFERs). The BFIR router adds a BIER header to the 111 packet. The BIER header contains a bit-string in which each bit 112 represents exactly one BFER to forward the packet to. The set of 113 BFERs to which the multicast packet needs to be forwarded is 114 expressed by setting the bits that correspond to those routers in the 115 BIER header. 117 This document describes the mechanism and basic BIER OAM packet 118 format that can be used to perform failure detection and isolation on 119 BIER data plane without any dependency on other layers like IP layer. 121 2. Conventions used in this document 123 2.1. Terminology 125 BFER - Bit Forwarding Egress Router 127 BFIR - Bit Forwarding Ingress Router 129 BIER - Bit Index Explicit Replication 131 ECMP - Equal Cost Multi-Path 133 OAM - Operation, Administration and Maintenance 135 SI - Set Identifier 137 2.2. Requirements notation 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 140 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 141 document are to be interpreted as described in [RFC2119]. 143 3. BIER OAM 145 BIER OAM is defined in a way that it stays within BIER layer by 146 following directly the BIER header without mandating the need for IP 147 header. [I-D.wijnands-mpls-bier-encapsulation] defines a 4-bit field 148 as "Proto" to identify the payload following BIER header. In order 149 to differentiate the BIER data packet from BIER OAM packet, this 150 document introduces a new value for the Proto field as: 152 Proto: 154 PROTO-TBD1: BIER OAM 156 3.1. BIER OAM message format 158 The BIER OAM packet header format that follows BIER header is as 159 follows: 161 0 1 2 3 162 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 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Ver | Message Type | Proto | Reserved | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 ~ Message Type Dependent Data ~ 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 Type 171 The Message Type is one of the following: 173 Type Value Field 174 -------- --------------- 175 TBD1 BIER Echo Request 176 TBD2 BIER Echo Reply 178 The Echo Request/Reply header format is as follows: 180 0 1 2 3 181 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Ver | Echo Req/Rep | Proto | Reserved | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | QTF | RTF | Reply mode | Return Code | Return Subcode| 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Sender's Handle | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Sequence Number | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | TimeStamp Sent | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | TimeStamp Sent | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | TimeStamp Received | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | TimeStamp Received | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 ~ TLVs ~ 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Proto 204 Set to 0 for Echo Request/Reply header. 206 QTF 208 Querier Timestamp Format. When set to 2, the Timestamp Sent field 209 is (in seconds and microseconds, according to the Initiator's 210 clock) in NTP format [RFC5905]. When set to 3, the timestamp 211 format is in IEEE 1588-2008 (1588v2) Precision Time Protocol 212 format. 214 RTF 216 Responder Timestamp Format. When set to 2, the Timestamp Received 217 field is (in seconds and microseconds, according to the 218 Initiator's clock) in NTP format [RFC5905]. When set to 3, the 219 timestamp format is in IEEE 1588-2008 (1588v2) Precision Time 220 Protocol format. 222 Reply mode 224 The Reply mode is set to one of the below: 226 Value Meaning 227 -------- --------------- 228 1 Do not Reply 229 2 Reply via IPv4/IPv6 UDP packet. 230 3 Reply via BIER packet 232 Return Code 234 Set to zero if Type is TBD1. Set as defined in section 3.2 if 235 Type is TBD2. 237 Return subcode 239 To Be updated. 241 Sender's Handle, Sequence number and Timestamp 243 The Sender's Handle is filled by the Initiator, and returned 244 unchanged by responder BFR. This is used for matching the replies 245 to the request. 247 The Sequence number is assigned by the Initiator and can be used 248 to detect any missed replies. 250 The Timestamp Sent is the time when the echo request is sent. The 251 TimeStamp Received in echo reply is the time (accordingly to 252 responding BFR clock) that the corresponding echo request was 253 received. The format depends on the QTF/RTF value. 255 TLVs 257 Carries the TLVs as defined in Section 3.3. 259 3.2. Return Code 261 Responder uses Return Code field to reply with validity check or 262 other error message to Initiator. It does not carry any meaning in 263 Echo Request and MUST be set to zero. 265 The Return Code can be one of the following: 267 Value Value Meaning 268 -------- --------------- 269 0 No return code (Set by Initiator in Echo Request) 270 1 Malformed echo request received 271 2 One or more of the TLVs was not understood 272 3 Replying BFR is the only BFER in header Bitstring 273 4 Set-Identifier Mismatch 274 5 Packet-Forward-Success 275 6 Invalid Multipath Info Request 276 7 No control plane entry for Multicast Overlay Data 277 8 No matching entry in forwarding table. 278 9 Replying BFR is one of the BFER in header Bitstring 280 3.3. BIER OAM TLV 282 This section defines various TLVs that can be used in BIER OAM 283 packet. The TLVs (Type-Length-Value tuples) have the following 284 format: 286 0 1 2 3 287 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 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Type | Length | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | | 292 ~ Value ~ 293 | | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 TLV Types are defined below; Length is the length of the Value field 297 in octets. The Value field depends on the TLV Type. 299 3.3.1. Original SI-BitString TLV 301 The Original SI-BitString TLV carries the set of BFER and carries the 302 same BitString that Initiator includes in BIER header.This TLV has 303 the following format: 305 0 1 2 3 306 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 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Type = 1 | Length = variable | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Set ID | BitString Len | Reserved | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | BitString (first 32 bits) ~ 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 ~ ~ 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | BitString (last 32 bits) | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 The Length field is set as defined in section 3 of 320 [I-D.wijnands-mpls-bier-encapsulation]. 322 Set ID field is set to the Set Identifier to which the BitString 323 belongs to. This value is derived as defined in section 3 of 324 [I-D.wijnands-bier-architecture] 326 The BitString field carries the set of BFR-IDs that Initiator will 327 include in the BIER header. This TLV MUST be included by Initiator 328 in Echo Request packet 330 3.3.2. Target SI-BitString TLV 332 The Target SI-BitString TLV carries the set of BFER from which the 333 Initiator expects the reply from.This TLV has the following format: 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 | Type = 2 | Length = variable | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Set ID | BitString Len | Reserved | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 | BitString (first 32 bits) ~ 343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 344 ~ ~ 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 | BitString (last 32 bits) | 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 The Length field is set as defined in section 3 of 350 [I-D.wijnands-mpls-bier-encapsulation]. 352 Set ID field is set to the Set Identifier to which the BitString 353 belongs to. This value is derived as defined in section 3 of 354 [I-D.wijnands-bier-architecture] 356 The BitString field carries the set of BFR-IDs of BFER(s) that 357 Initiator expects the response from. The BitString in this TLV may 358 be different from the BitString in BIER header and allows to control 359 the BFER responding to the Echo Request. This TLV MUST be included 360 by Initiator in BIER OAM packet if the Downstream Mapping TLV 361 (section 3.3.4) is included. 363 3.3.3. Incoming SI-BitString TLV 365 The Incoming SI-BitString TLV will be included by Responder BFR in 366 Reply message and copies the BitString from BIER header of incoming 367 Echo Request message. This TLV has the following format: 369 0 1 2 3 370 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 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | Type = 3 | Length = variable | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | Set ID | BitString Len | Reserved | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | BitString (first 32 bits) ~ 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 ~ ~ 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | BitString (last 32 bits) | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 383 The Length field is set as defined in section 3 of 384 [I-D.wijnands-mpls-bier-encapsulation]. 386 Set ID field is set to the Set Identifier of the incoming BIER-MPLS 387 label. This value is derived as defined in section 2.2 of 388 [I-D.psenak-ospf-bier-extensions] 390 The BitString field copies the BitString from BIER header of the 391 incoming Echo Request. A Responder BFR SHOULD include this TLV in 392 Echo Reply if the Echo Request is received with I flag set in 393 Downstream Mapping TLV. 395 An Initiator MUST NOT include this TLV in Echo Request. 397 3.3.4. Downstream Mapping TLV 399 This TLV has the following format: 401 0 1 2 3 402 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 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 | Type = 4 | Length = variable | 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | MTU | Address Type | Flags | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Downstream Address (4 or 16 octets) | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Downstream Interface Address (4 or 16 octets) | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Sub-tlv Length | | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 414 . . 415 . List of Sub-TLVs . 416 . . 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 MTU 421 Set to MTU value of outgoing interface. 423 Address Type 425 The Address Type indicates the address type and length of IP 426 address for downstream interface. The Address type is set to one 427 of the below: 429 Type Addr. Type DA Length DIA Length 430 ------- --------------- ---------- ---------- 431 1 IPv4 Numbered 4 4 432 2 IPv4 Unnumbered 4 4 433 3 IPv6 Numbered 16 16 434 4 IPv6 Unnumbered 16 4 436 DA Length - Downstream Address field Length 437 DIA Length - Downstream Interface Address field Length 439 Flags 440 The Flags field has the following format: 442 0 1 2 3 4 5 6 7 443 +-+-+-+-+-+-+-+-+ 444 | Rsvd |I| 445 +-+-+-+-+-+-+-+-+ 447 When I flag is set, the Responding BFR SHOULD include the Incoming 448 SI-BitString TLV in echo reply message. 450 Downstream Address and Downstream Interface Address 452 If the Address Type is 1, the Downstream Address MUST be set to 453 IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address 454 is set to downstream interface address. 456 If the Address Type is 2, the Downstream Address MUST be set to 457 IPV4 BFR-Prefix of downstream BFR and Downstream Interface Address 458 is set to the index assigned by upstream BFR to the interface. 460 If the Address Type is 3, the Downstream Address MUST be set to 461 IPV6 BFR-Prefix of downstream BFR and Downstream Interface Address 462 is set to downstream interface address. 464 If the Address Type is 4, the Downstream Address MUST be set to 465 IPv6 BFR-Prefix of downstream BFR and Downstream Interface Address 466 is set to index assigned by upstream BFR to the interface. 468 3.3.4.1. Downstream Mapping Sub-TLVs 470 This section defines the optional Sub-TLVs that can be included in 471 Downstream Mapping TLV. 473 Sub-TLV Type Value 474 --------------- -------------- 475 1 Multipath Entropy Data 476 2 Egress BitString 478 3.3.4.1.1. Multipath Entropy Data 479 0 1 2 3 480 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 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 |M| Reserved | | 483 +-+-+-+-+-+-+-+-+-+ | 484 | | 485 | (Multipath Information) | 486 | | 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 M Flag 491 This flag is set to 0 if all packets will be forwarded out through 492 interface defined in Downstream Mapping TLV. When set to 1, 493 Multipath Information will be defined with Bit masked Entropy 494 data. 496 Multipath Information 498 Entropy Data encoded as defined in section x3. 500 3.3.4.1.2. Egress BitString 502 This Sub-TLV MAY be included by Responder BFR with the rewritten 503 BitString in outgoing interface as defined in section 6.1 of 504 [I-D.wijnands-bier-architecture] 506 0 1 2 3 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Set ID | BitString Len | Reserved | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | BitString (first 32 bits) ~ 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 ~ ~ 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | BitString (last 32 bits) | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 3.3.5. Responder BFER TLV 519 The Responder BFER TLV will be included by the BFER replying to the 520 request. This is used to identify the originator of BIER Echo Reply. 521 This TLV have the following format: 523 0 1 2 3 524 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 525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 526 | Type = 5 | Length | 527 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 528 | Reserved | BFR-ID | 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 BFR-ID 533 The BFR-ID field carries the BFR-ID of replying BFER. This TLV 534 MAY be included by Responding BFER in BIER Echo Reply packet. 536 3.3.6. Responder BFR TLV 538 The Responder BFR TLV will be included by the transit BFR replying to 539 the request. This is used to identify the replying BFR without BFR- 540 ID. This TLV have the following format: 542 0 1 2 3 543 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 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | TLV Type = 6 | Length = variable | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Reserved | Address Type | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | | 550 ~ Routable Address (4 or 16 bytes) ~ 551 | | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 Length 556 The Length field varies depending on the Address Type. 558 Address Type 560 Set to 1 for IPv4 or 2 for IPv6. 562 Routable Address 564 Carries any locally routable address of replying BFR. This TLV 565 MAY be included by Responding BFR in BIER Echo Reply packet. 567 3.3.7. Upstream Interface TLV 569 The Upstream Interface TLV will be included by the replying BFR in 570 Echo Reply. This is used to identify the incoming interface and the 571 BIER-MPLS label in the incoming Echo Request. This TLV have the 572 following format: 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | TLV Type = 7 | Length = variable | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 | Reserved | Address Type | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 581 | | 582 ~ Upstream Address (4 or 16 bytes) ~ 583 | | 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 586 Length 588 The Length field varies depending on the Address Type. 590 Address Type 592 Set to 1 for IPv4 or 2 for IPv6. 594 Upstream Address 596 As defined in Section 3.3.4 598 4. Procedures 600 This section describes aspects of Ping and traceroute operations. 601 While this document explains the behavior when Reply mode is "Reply 602 via BIER packet", the future version will be updated with details 603 about the format when the reply mode is "Reply via IP/UDP packet". 605 4.1. BIER OAM processing 607 A BIER OAM packet MUST be sent to BIER control plane for OAM 608 processing if one of the following conditions is true: 610 o The receiving BFR is a BFER. 612 o TTL of BIER-MPLS Label expired. 614 o Presence of Router Alert label in the label stack. 616 4.2. Per BFER ECMP Discovery 618 As defined in [I-D.wijnands-bier-architecture], BIER follows unicast 619 forwarding path and allows load balancing over ECMP paths between 620 BFIR and BFER. BIER OAM MUST support ECMP path discovery between a 621 BFIR and a given BFER and MUST support path validation and failure 622 detection of any particular ECMP path between BFIR and BFER. 624 [I-D.wijnands-mpls-bier-encapsulation] proposes the BIER header with 625 Entropy field that can be leveraged to exercise all ECMP paths. 626 Initiator/BFIR will use traceroute message to query each hop about 627 the Entropy information for each downstream paths. To avoid 628 complexity, it is suggested that the ECMP query is performed per BFER 629 by carrying required information in BIER OAM message. 631 Initiator MUST include Multipath Entropy Data Sub-TLV in Downstream 632 Mapping TLV. It MUST also include the BFER in BitString TLV to which 633 the Multipath query is performed. 635 Any transit BFR will reply back with Bit-masked Entropy for each 636 downstream path as defined in [RFC4379] 638 4.3. Sending BIER Echo Request 640 Initiator MUST set the Message Type as TBD1 and Return Code as 0. 641 Initiator infer the Set Identifier value from the respective 642 BitString that will be appended in BIER header and include in "SI" 643 field. 645 The Proto field in OAM packet MUST be set to 0, if there is no data 646 packet following immediately after OAM packet. In all other cases, 647 the Proto field MUST be set to value as defined in 648 [I-D.wijnands-mpls-bier-encapsulation], same as of the data packet 649 that follows after OAM packet. 651 Initiator MUST include Original SI-BitString TLV. Initiator MUST NOT 652 include more than one Original SI-BitString TLV. In Ping mode, 653 Initiator MAY include Target SI-BitString TLV listing all the BFER 654 from which the Initiator expects a response. In traceroute mode, 655 Initiator SHOULD include Target SI-Bitstring TLV. Initiator on 656 receiving a reply with Return code as "Replying router is one of the 657 BFER in BIER header Bitstring" , SHOULD unset the respective BFR-id 658 from Target SI-Bitstring on any subsequent request. 660 Initiator MAY also include Downstream Mapping TLV (section 3.3.4). 661 In presence of Multipath Entropy Data Sub-TLV, the Target SI- 662 BitString TLV MUST carry only one BFER id. 664 Initiator then encapsulates with BIER header and set the Proto as 665 TBD1 and further encapsulates with BIER-MPLS label. In ping mode, 666 the BIER-MPLS Label TTL MUST be set to 255. In traceroute mode, the 667 BIER-MPLS Label TTL is set successively starting from 1 and MUST stop 668 sending the Echo Request if it receives a reply with Return code as 669 "Replying router is the only BFER in BIER header Bitstring" from all 670 BFER listed in BitString TLV. 672 4.4. Receiving BIER Echo Request 674 Sending a BIER OAM Echo Request to control plane for payload 675 processing is triggered as mentioned in section 4.1. 677 Any BFR on receiving Echo Request MUST send Echo Reply with Return 678 Code set to 1, if the packet fails sanity check. If the packet 679 sanity check is fine, it initiates a variable as "Best-return-code" 680 and further processes it as below: 682 1. Set the Best-return-code to "SI Mismatch", if the received BIER- 683 MPLS Label is not assigned to the Set ID value in Original SI- 684 BitString TLV. Go to section 4.5. 686 2. Set the Best-return-code to "One or more of the TLVs was not 687 understood", if any of the TLVs in echo request message is not 688 understood. Go to section 4.5. 690 3. Set the Best-return-code to "Invalid Multipath Info Request", if 691 the Echo Request is received with more than 1 BFER id in Target 692 SI-BitString TLV AND Multipath Entropy Data Sub-TLV. Go to 693 section 4.5. 695 4. Set the Best-return-code to "Replying router is the only BFER in 696 BIER header Bitstring", and go to section 4.5 if the responder is 697 BFER and there is no more bits in BIER header Bitstring left for 698 forwarding. 700 5. Set the Best-return-code to "Replying router is one of the BFER 701 in BIER header Bitstring", and include Downstream Mapping TLV, if 702 the responder is BFER and there is more bits in BitString left 703 for forwarding. In addition, include the Multipath information 704 as defined in Section 4.2 if the received Echo Request carries 705 Multipath Entropy Data Sub-TLV. Go to section 4.5. 707 6. Set the Best-return-code to "No matching entry in forwarding 708 table", if the forwarding lookup defined in section 6.5 of 709 [I-D.wijnands-bier-architecture] does not match any entry for the 710 received BitString in BIER header. 712 7. Set the Best-return-code to "Packet-Forward-OK", and include 713 Downstream Mapping TLV. Go to section 4.5 715 4.5. Sending Echo Reply 717 Responder MUST include DDMAP in Echo Reply if the incoming Echo 718 Request carries DDMAP. Responder MUST set the Message Type as TBD2 719 and Return Code as Best-return-code. The SI field MUST be set to 0 720 and Proto field MUST be set to 0. 722 Responder appends BIER header listing the BitString with BFIR ID 723 (from received Echo Request), set the Proto to PROTO-TBD1 and set the 724 BFIR as zero. 726 4.6. Receiving Echo Reply 728 Initiator on receiving echo reply will use the Sender's Handle to 729 match with echo request sent. If no match is found, Initiator MUST 730 ignore the Echo Reply. 732 If receiving echo reply have Downstream Mapping, Initiator SHOULD 733 copy the same to subsequent Echo Request(s). 735 5. IANA Considerations 737 This document request the IANA the creation and management of below 738 registries: 740 5.1. Message Types, Reply Modes, Return Codes 742 This document request to assign the Message Types and Reply mode 743 mentioned in section 3.1, , Return code mentioned in Section 3.2. 745 5.2. TLVs 747 The TLVs and Sub-TLVs requested by this document for IANA 748 consideration are the following: 750 Type Sub-Type Value Field 751 ------- -------- ----------- 752 1 Original SI-BitString 753 2 Target SI-BitString 754 3 Incoming SI-BitString 755 4 Downstream Mapping 756 4 1 Multipath Entropy Data 757 4 2 Egress BitString 758 5 Responder BFER 759 6 Responder BFR 760 7 Upstream Interface 762 6. Security Considerations 764 The security consideration for BIER Ping is similar to ICMP or LSP 765 Ping. AS like ICMP or LSP ping, BFR may be exposed to Denial-of- 766 service attacks and it is RECOMMENDED to regulate the BIER Ping 767 packet flow to control plane. A rate limiter SHOULD be applied to 768 avoid any attack. 770 As like ICMP or LSP Ping, a traceroute can be used to obtain network 771 information. It is RECOMMENDED that the implementation check the 772 integrity of BFIR of the Echo messages against any local secured list 773 before processing the message further 775 7. Acknowledgement 777 TBD 779 8. Contributing Authors 781 TBD 783 9. References 785 9.1. Normative References 787 [I-D.psenak-ospf-bier-extensions] 788 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 789 Przygienda, T., and J. Zhang, "OSPF Extensions For BIER", 790 draft-psenak-ospf-bier-extensions-02 (work in progress), 791 February 2015. 793 [I-D.wijnands-bier-architecture] 794 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 795 S. Aldrin, "Multicast using Bit Index Explicit 796 Replication", draft-wijnands-bier-architecture-04 (work in 797 progress), February 2015. 799 [I-D.wijnands-mpls-bier-encapsulation] 800 Wijnands, I., Rosen, E., Dolganow, A., Tantsura, J., and 801 S. Aldrin, "Encapsulation for Bit Index Explicit 802 Replication in MPLS Networks", draft-wijnands-mpls-bier- 803 encapsulation-02 (work in progress), December 2014. 805 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 806 Requirement Levels", BCP 14, RFC 2119, March 1997. 808 [RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-Protocol 809 Label Switched (MPLS) Data Plane Failures", RFC 4379, 810 February 2006. 812 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 813 Time Protocol Version 4: Protocol and Algorithms 814 Specification", RFC 5905, June 2010. 816 9.2. Informative References 818 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 819 RFC 792, September 1981. 821 [RFC6291] Andersson, L., van Helvoort, H., Bonica, R., Romascanu, 822 D., and S. Mansfield, "Guidelines for the Use of the "OAM" 823 Acronym in the IETF", BCP 161, RFC 6291, June 2011. 825 [RFC6424] Bahadur, N., Kompella, K., and G. Swallow, "Mechanism for 826 Performing Label Switched Path Ping (LSP Ping) over MPLS 827 Tunnels", RFC 6424, November 2011. 829 [RFC6425] Saxena, S., Swallow, G., Ali, Z., Farrel, A., Yasukawa, 830 S., and T. Nadeau, "Detecting Data-Plane Failures in 831 Point-to-Multipoint MPLS - Extensions to LSP Ping", RFC 832 6425, November 2011. 834 Authors' Addresses 836 Nagendra Kumar 837 Cisco Systems, Inc. 838 7200 Kit Creek Road 839 Research Triangle Park, NC 27709 840 US 842 Email: naikumar@cisco.com 843 Carlos Pignataro 844 Cisco Systems, Inc. 845 7200 Kit Creek Road 846 Research Triangle Park, NC 27709-4987 847 US 849 Email: cpignata@cisco.com 851 Nobo Akiya 852 Cisco Systems, Inc. 853 2000 Innovation Drive 854 Kanata, ON K2K 3E8 855 Canada 857 Email: nobo@cisco.com 859 Lianshu Zheng 860 Huawei Technologies 861 China 863 Email: vero.zheng@huawei.com 865 Mach Chen 866 Huawei Technologies 868 Email: mach.chen@huawei.com 870 Greg Mirsky 871 Ericsson 873 Email: gregory.mirsky@ericsson.com