idnits 2.17.1 draft-anish-bier-overlay-pim-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 (July 6, 2015) is 3189 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) == Missing Reference: 'RFC3692' is mentioned on line 228, but not defined == Outdated reference: A later version (-01) exists of draft-anish-pim-stream-discovery-00 == Outdated reference: A later version (-02) exists of draft-anish-reliable-pim-registers-00 == Outdated reference: A later version (-08) exists of draft-ietf-bier-architecture-01 == Outdated reference: A later version (-11) exists of draft-ietf-bier-isis-extensions-00 == Outdated reference: A later version (-18) exists of draft-ietf-bier-ospf-bier-extensions-00 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 bier A. Peter, Ed. 3 Internet-Draft R. Kebler 4 Intended status: Standards Track V. Nagarajan 5 Expires: January 7, 2016 Juniper Networks, Inc. 6 July 6, 2015 8 Overlay for discovery in a BIER network 9 draft-anish-bier-overlay-pim-00 11 Abstract 13 This document introduces an overlay model for signaling egress 14 interest to the ingress BIER router. 16 Requirements Language 18 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 19 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 20 document are to be interpreted as described in RFC2119 [RFC2119]. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 7, 2016. 39 Copyright Notice 41 Copyright (c) 2015 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. BIER Overlay Overview . . . . . . . . . . . . . . . . . . . . 3 58 3. Targeted Hellos . . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Optional Targeted Hello TLV's . . . . . . . . . . . . . . 4 60 3.2. Optional BIER Hello TLV's . . . . . . . . . . . . . . . . 5 61 4. Reliable Connection setup . . . . . . . . . . . . . . . . . . 6 62 4.1. Active BIER edge router . . . . . . . . . . . . . . . . . 6 63 5. Anycast RP's . . . . . . . . . . . . . . . . . . . . . . . . 6 64 5.1. Anycast-RP change . . . . . . . . . . . . . . . . . . . . 6 65 5.1.1. Service Request Message . . . . . . . . . . . . . . . 6 66 5.1.2. Capabilites Message . . . . . . . . . . . . . . . . . 7 67 6. BIER Overlay messages . . . . . . . . . . . . . . . . . . . . 7 68 6.1. PORT Capability message . . . . . . . . . . . . . . . . . 7 69 6.1.1. Capability record for Source, Group . . . . . . . . . 8 70 6.1.2. Capability record for Source . . . . . . . . . . . . 9 71 6.2. Sending and receiving Capability messages . . . . . . . . 10 72 7. PORT Service Request message . . . . . . . . . . . . . . . . 10 73 7.1. Service request record for Source, Group . . . . . . . . 12 74 7.2. Service request record for Group prefix . . . . . . . . . 12 75 7.3. Sending and receiving Service request messages . . . . . 13 76 7.4. Service request messages between RP and First-Hop-Router 13 77 7.5. PORT Keep-Alive Message . . . . . . . . . . . . . . . . . 13 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 79 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 80 9.1. PIM Hello Options TLV . . . . . . . . . . . . . . . . . . 14 81 9.2. PIM PORT Message Type . . . . . . . . . . . . . . . . . . 14 82 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 83 10.1. TCP or SCTP security threats . . . . . . . . . . . . . . 15 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 86 11.2. Informative References . . . . . . . . . . . . . . . . . 16 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 BIER [I-D.ietf-bier-architecture] proposes a new forwarding plane for 92 multicast packet delivery in a network. The major advantage with 93 BIER that it does not need per flow forwarding entry in the network. 94 BIER accomplishes this by addressing each of the targeted egress 95 router in a bit mask based addressing schema. 97 Each BIER Forwarding Router (BFR) is assigned and uniquely identified 98 by a BFR-prefix which is a routable ipv4 or ipv6 address. Each BIER 99 egress (BFER) router needs a BFR-Identifier (1..65535) in addition to 100 BFR-prefix. 102 To accomplish forwarding in a BIER network, ingress router needs to 103 know the list of egress routers to which the flow is supposed be 104 multicasted. For this learning, an overlay signaling is needed. In 105 some of the intended use cases of BIER such as BGP-MVPN, BGP is used 106 for signaling, which could be used to provide the needed overlay 107 service. In other use-cases, BGP may not be used. This opens the 108 need for having an adequate overlay for BIER. 110 PIM Over Reliable Transport (PORT) with its extensions in Reliable 111 PIM Registers [I-D.anish-reliable-pim-registers] and LHR source 112 discovery [I-D.anish-pim-stream-discovery] provides a mechanism for 113 edge routers to share their interests and capabilities to a 114 Rendezvous Point (RP). RP could now facilitate service discovery 115 based on this. (PORT RP could be a router/controller/server as it 116 need not handle the data-traffic) 118 For BIER overlay this PORT-RP based model could talk to edge routers 119 and then consolidate and filter this database and send to ingress, 120 peer specific interest. 122 This version of the documents states the case of First-Hop-Router 123 also being the BFIR and Last-Hop-Router also being the BFER. 125 BIER architecture includes a routing underlay achieved by extensions 126 to OSPF [I-D.ietf-bier-ospf-bier-extensions] and ISIS 127 [I-D.ietf-bier-isis-extensions]. This document assumes that this 128 routing underlay exists and is defined outside of this document 130 2. BIER Overlay Overview 132 Reliable PIM register and PIM source discovery extends PORT [RFC6559] 133 to discover and signal each other by advertising their capabilities 134 and needs. For achieving BIER overlay the basic requirement is for 135 egress to advertise their needs and for ingress routers to advertise 136 their capabilities so that a RP could keep the ingress informed about 137 the set of egress routers interested in its capabilities. 139 To achieve BIER-PORT overlay first, a transport connection is 140 established between an edge router (ingress or egress) and a RP. 141 When a receiver interest is known, egress route would pass that on to 142 the RP. Similarly when ingress router knows about its traffic 143 sourcing capability it would inform the RP about it. This way we 144 have the RP that knows about the sourcing capabilities and the 145 receiver interest in the network. 147 Based on these two databases RP would now inform ingress routers the 148 set of egress routers that would subscribe to its capabilities. 150 3. Targeted Hellos 152 Reliable PIM Registers [I-D.anish-reliable-pim-registers] targeted 153 hellos for PIM. This specification extends them to apply it for the 154 BIER overlay signaling. The only change it introduces is that it 155 uses one bit among the reserved bits for the purpose of a router 156 identifying itself as BIER capable in the targeted-hello optional TLV 157 in hello message 159 3.1. Optional Targeted Hello TLV's 161 Option Type: Targeted hello 163 0 1 2 3 164 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 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Type = H1 (for alloc) | Length = 4 | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 |F|R|L|B| Reserved | Exp | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 Figure 1: PIM Optional Targeted Hello TLV 173 Assigned Hello Type values can be found in IANA PIM registry. 175 Type: As defined in Reliable PIM Registers 176 [I-D.anish-reliable-pim-registers] 178 Length: As defined in Reliable PIM Registers 179 [I-D.anish-reliable-pim-registers] 181 F: As defined in Reliable PIM Registers 182 [I-D.anish-reliable-pim-registers] 184 R: As defined in Reliable PIM Registers 185 [I-D.anish-reliable-pim-registers] 187 L: As defined in Reliable PIM Registers 188 [I-D.anish-pim-stream-discovery] 189 B: Identifies the PIM hellos senders capability of being a BIER edge 190 router 192 Reserved: Set to zero on transmission and ignored on receipt. 194 Exp: As defined in Reliable PIM Registers 195 [I-D.anish-reliable-pim-registers] 197 3.2. Optional BIER Hello TLV's 199 Option Type: BIER capability hello 201 0 1 2 3 202 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 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Type = H2 (for alloc) | Length = 6 | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 |E| Reserved | Exp | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | BIER-Prefix z 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 Figure 2: PIM Optional BIER header TLV 213 Assigned Hello Type values can be found in IANA PIM registry. 215 Type: This is subject to IANA allocation. Its stated as H2 for ease 216 of reference and as a continuation from H1 as defined in Reliable PIM 217 Registers [I-D.anish-reliable-pim-registers]. 219 Length: Length in bytes for the value part of the Type/Length/Value 220 encoding its length would vary based on the prefix being ipv4 or 221 ipv6. 223 E: To be set by a router that has a BIER id so that it could be 224 identified as a egress router in a BIER domain. 226 Reserved: Set to zero on transmission and ignored on receipt. 228 Exp: For experimental use [RFC3692]. One expected use of these bits 229 would be to signal experimental capabilities. For example, if a 230 router supports an experimental feature, it may set a bit to indicate 231 this. The default behavior, unless a router supports a particular 232 experiment, is to keep these bits reset and ignore the bits on 233 receipt. 235 BIER-Prefix: BIER-Prefix of the sender router in the encoded unicast 236 ipv4 or ipv6 address family format as define in [RFC4601]. 238 4. Reliable Connection setup 240 A reliable connection has to be setup between the BIER edge router 241 and RP for message exchanges to happen. 243 4.1. Active BIER edge router 245 Once BIER edge and RP discovery each other with targeted hello 246 neighborhood, BIER edge takes the active role. BIER edge would 247 listen for RP to connect once it forms targeted neighbor-ship with 248 RP. The RP would be expected to use its primary address, which it 249 would have used as the source address in its pim hellos. 251 5. Anycast RP's 253 PIM uses Anycast-RP [RFC4610] as a mechanism for RP redundancy. 254 Reliable PIM Registers [I-D.anish-reliable-pim-registers] introduced 255 procedures to support anycast-RP with reliable connection. This 256 section describes how anycast-RP would work with this specification. 258 5.1. Anycast-RP change 260 In the event of nearest anycast-RP changing over to a different 261 router, BIER edge router would detect that when it starts receiving 262 PIM hellos with a different primary address for the same anycast 263 address. Upon detecting this scenario, the edge router may wait for 264 an interval before setting up connection with the newly found primary 265 address of the RP. Subsequently older connection would get 266 terminated due to neighbor timeout. Once the old connection is 267 terminated, router should clear off the states that were advertised 268 in the old connection and not by the new connection. 270 The edge router should transmit its service requests and capabilites 271 to this new found RP. RP should transmit the service request 272 messages to BFIR routers having capability. 274 In order to accommodate for delays in a new RP discovering and 275 messaging, state cleanup should be done only after a suitable delay. 277 5.1.1. Service Request Message 279 Service Request of BIER should be mirrored among the BIER RP's. The 280 BIER message format allows list of BFER's to be appended to SR 281 message. This message format could be used to reduce messaging. 283 5.1.2. Capabilites Message 285 The capabilites message send by the ingress is NOT mirrored and would 286 be retained only by the first RP. 288 6. BIER Overlay messages 290 BIER overlay is achieved with the help of 2 new messages in [RFC6559] 291 PORT. 293 1, Capability message: Send by a BIER ingress stating its capability 294 (in sourcing traffic) 296 2, Service Request message: Send by a BIER egress router stating the 297 services that it needs. 299 6.1. PORT Capability message 301 0 1 2 3 302 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 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Type = P4 (for alloc) | Message Length | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Reserved | Exp. | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 |W| Reserved-1 |RecType| Record Length | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | | 311 z Record-1 z 312 | | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 Z . . . z 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 |W| Reserved-n |RecType| Record Length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | | 319 z Record-n z 320 | | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 3: PORT Capability advertisement Message 325 Type: This is subject to IANA allocation. It would be next 326 unallocated value, which is referred until allocation as P4. 328 Length: Length in bytes for the value part of the Type/Length/Value 329 Reserved: Set to zero on transmission and ignored on receipt. This 330 reserved bits are for properties that apply to the entire message. 332 Exp: : For experimental use. 334 W: This flag signifies if the Record is getting Withdrawn or added. 335 When cleared, it indicates that the SG is getting added by the 336 Ingress. 338 RecType: This 4 bit value signifies the record type as define in 339 section below. 341 The record types define are 343 1 0x0 Reserved 345 2 0x1 SG capability 347 3 0x2 S/S-prefix capability (For ssm) 349 4 0x3 -> 0xd UNASSIGNED 351 5 0xe -> 0xf For experimental use. 353 Record Length: This 12 bit value is the length of record in bytes 355 Reserved-n: Set to zero on transmission and ignored on receipt. This 356 reserved bits are for properties that apply to any particular sg. 358 6.1.1. Capability record for Source, Group 360 (src, grp)/sg record type is used by the first hop router to inform 361 the src, grp address pair of a traffic it could source. This is 362 analogous to a pim-sm register. 364 Record type 0x1 365 0 1 2 3 366 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 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 z src addr-1 z 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 z grp addr-1 z 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 z . . . z 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 z src addr-n z 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 z grp addr-n z 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 Figure 4: PORT Capability for sg record 381 src addr-x : This is the source address of a stream in the "Encoded- 382 Source-Address" Format as specified in [RFC4601]. 384 grp addr-x : This is the group address of a stream in the "Encoded- 385 Group-Address" Format as specified in [RFC4601]. 387 6.1.2. Capability record for Source 389 Source prefix record type is used by the first hop router to inform 390 one source address or source address subnet from which, could source 391 traffic. This capability record will be mainly of use for migrating 392 a pim ssm network to BIER. 394 Record type 0x2 395 0 1 2 3 396 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 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 z src addr-1 z 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 z . . . z 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 z src addr-n z 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 Figure 5: PORT Capability for src record 407 src addr-x : This is the source address of a stream in the "Encoded- 408 Source-Address" Format as specified in [RFC4601]. 410 6.2. Sending and receiving Capability messages 412 A BIER router capable of being an ingress would send capability 413 message. Based on use-case new capabilities could be added besides 414 the ones stated in previous section. 416 7. PORT Service Request message 418 0 1 2 3 419 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 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 | Type = P5 (for alloc) | Message Length | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 | Reserved | Exp. | 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 |W| Reserved-1 |RecType| Record Length | 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | m-bier-recv | | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 429 z Record-1 z 430 | | 431 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 | BIER-prefix-1,1 z 433 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 434 z . . . z 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 z BIER_prefix-1,m | 437 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 438 z . . . z 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 |W| Reserved-1 | RecType | Record Length | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | n-bier-recv | | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 444 z Record-n z 445 | | 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | BIER-prefix-1,1 z 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 z . . . z 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 z BIER_prefix-1,m | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 Figure 6: PORT Service Request Message 456 Type: This is subject to IANA allocation. It would be next 457 unallocated value, which is referred until allocation as P5. 459 Length: Length in bytes for the value part of the Type/Length/Value 461 W: This flag signifies if the Record is getting Withdrawn or added. 462 When cleared, it indicates that the SG is getting added by the 463 Ingress. 465 RecType: This 8 bit value signifies the record type as define in 466 section below. 468 The record types define are 470 1 0x0 Reserved 472 2 0x1 S,G Join 474 3 0x2 *,G Join 476 4 0x3 -> 0xe UNASSIGNED 478 5 0xf Resv 480 Record Length: Length of record in bytes 482 n-bier-recv: The number of bier receivers bier id that follows the 483 record. For simple service request message send from a BIER egress, 484 this could be 0 as the BIER id of the egress is known to RP via the 485 targeted hellos. This list of BIER id's plays a role when RP mirrors 486 these message to an another RP or when BIER egress is proxying for an 487 another edge router on when the message is send to Ingress router as 488 with list of egress BIER routers for the service. 490 BIER-prefix-x,y: This is the BIER-prefix of egress router in the 491 encoded unicast ipv4 or ipv6 address family format as define in 492 [RFC4601]. 494 Reserved: Set to zero on transmission and ignored on receipt. This 495 reserved bits are for properties that apply to the entire message. 497 Reserved-n: Set to zero on transmission and ignored on receipt. This 498 reserved bits are for properties that apply to any particular sg. 500 Exp: : For experimental use. 502 7.1. Service request record for Source, Group 504 (src, grp)/sg record type is used by the Egress router to inform the 505 src, grp address pair of a traffic it wants. This is analogous to a 506 pim-sg join. 508 Record type 0x1 509 0 1 2 3 510 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 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 z grp addr-1 z 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 z src addr-1 z 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 z . . . z 517 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 518 z grp addr-n z 519 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 520 z src addr-n z 521 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 523 Figure 7: PORT Service Request for a sg record 525 src addr-x : This is the encoded source address of a stream as 526 specified in [RFC4601] 528 grp addr-x : This is the encoded group address of a stream as 529 specified in [RFC4601] 531 7.2. Service request record for Group prefix 533 group prefix record type is used by the Egress router to inform the 534 multicast groups that are of interest to it. This is analogous to a 535 pim-*g join. 537 Record type 0x3 538 0 1 2 3 539 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 540 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 541 z grp addr-1 z 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 z . . . z 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 z grp addr-n z 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 Figure 8: PORT Service Request for *g record 550 grp addr-x : This is the encoded group address of a stream as 551 specified in [RFC4601] 553 7.3. Sending and receiving Service request messages 555 A BIER router capable of being an Egress would send service request 556 messages. This service request does not require the egress routers 557 BIER-prefix as that may be already known from the hello options. If 558 for some reason the BIER-prefix tlv is not seen on the hello message, 559 then the router MAY retain the service requests send but would send 560 it to ingress only when the BIER-prefix is learned. 562 Based on use-cases new capabilities could be added besides the ones 563 stated in previous section. 565 7.4. Service request messages between RP and First-Hop-Router 567 The same Service request message used by LHR to notify RP, could be 568 used for notifying First-Hop-Router with the consolidated list of 569 egress BIER routers. 571 On the First-Hop-Router, the BIER-prefix list for a service is 572 updated incrementally. Hence when two SR message for the identical 573 record is received, RP should add/subtract the new list to the its 574 list of egress 576 7.5. PORT Keep-Alive Message 578 The PORT Keep-alive messages as specified in PIM over Reliable 579 Transport [RFC6559] would be used to check the liveliness of the peer 580 and the reliable session 582 8. Acknowledgements 584 The authors wish to thank Eric Rosen for his thoughts and 585 contributions in this work. 587 9. IANA Considerations 589 This specification introduces new TLV in PIM hello and in PIM PORT 590 messages. Hence the tlv ids for these needs IANA allocation 592 9.1. PIM Hello Options TLV 594 The following Hello TLV types need IANA allocation. Place holder are 595 kept to differentiate the different types. 597 +---------------------+----------+--------------------+-------------+ 598 | Value | Length | Name | Reference | 599 +---------------------+----------+--------------------+-------------+ 600 | H2 (next available | Variable | BIER-Hello-Options | This | 601 | one) | | | document | 602 +---------------------+----------+--------------------+-------------+ 604 Table 1: Place holder values for PIM Hello TLV type for IANA 605 allocation 607 9.2. PIM PORT Message Type 609 The following PIM PORT message TLV types need IANA allocation. Place 610 holder are kept to differentiate the different types. 612 +---------------------+-----------------------------+---------------+ 613 | Value | Name | Reference | 614 +---------------------+-----------------------------+---------------+ 615 | P4 (Next available) | BIER Capability Message | This document | 616 | P5 (Next available) | BIER Service Request | This document | 617 | | Message | | 618 +---------------------+-----------------------------+---------------+ 620 Table 2: Place holder values for PIM PORT TLV type for IANA 621 allocation 623 10. Security Considerations 625 TBW 627 10.1. TCP or SCTP security threats 629 The security perception for this is stated in [RFC6559]. 631 11. References 633 11.1. Normative References 635 [I-D.anish-pim-stream-discovery] 636 Peter, A., Kebler, R., and V. Nagarajan, "PIM source 637 discovery in Last-Hop-Router", draft-anish-pim-stream- 638 discovery-00 (work in progress), March 2015. 640 [I-D.anish-reliable-pim-registers] 641 Peter, A., Kebler, R., and V. Nagarajan, "Reliable 642 Transport For PIM Register States", draft-anish-reliable- 643 pim-registers-00 (work in progress), March 2015. 645 [I-D.ietf-bier-architecture] 646 Wijnands, I., Rosen, E., Dolganow, A., Przygienda, T., and 647 S. Aldrin, "Multicast using Bit Index Explicit 648 Replication", draft-ietf-bier-architecture-01 (work in 649 progress), June 2015. 651 [I-D.ietf-bier-isis-extensions] 652 Ginsberg, L., Aldrin, S., Zhang, J., and T. Przygienda, 653 "BIER support via ISIS", draft-ietf-bier-isis- 654 extensions-00 (work in progress), April 2015. 656 [I-D.ietf-bier-ospf-bier-extensions] 657 Psenak, P., Kumar, N., Wijnands, I., Dolganow, A., 658 Przygienda, T., Zhang, J., and S. Aldrin, "OSPF Extensions 659 For BIER", draft-ietf-bier-ospf-bier-extensions-00 (work 660 in progress), April 2015. 662 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 663 Requirement Levels", BCP 14, RFC 2119, March 1997. 665 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 666 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 667 Protocol Specification (Revised)", RFC 4601, August 2006. 669 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 670 Independent Multicast (PIM)", RFC 4610, August 2006. 672 11.2. Informative References 674 [RFC6559] Farinacci, D., Wijnands, IJ., Venaas, S., and M. 675 Napierala, "A Reliable Transport Mechanism for PIM", RFC 676 6559, March 2012. 678 Authors' Addresses 680 Anish Peter (editor) 681 Juniper Networks, Inc. 682 Electra, Exora Business Park 683 Bangalore, KA 560103 684 India 686 Email: anishp@juniper.net 688 Robert Kebler 689 Juniper Networks, Inc. 690 1194 N. Mathilda Ave. 691 Sunnyvale, CA 94089 692 US 694 Email: rkebler@juniper.net 696 Vikram Nagarajan 697 Juniper Networks, Inc. 698 Electra, Exora Business Park 699 Bangalore, KA 560103 700 India 702 Email: vikramna@juniper.net