idnits 2.17.00 (12 Aug 2021) /tmp/idnits43744/draft-anish-reliable-pim-registers-02.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6559]), 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: An RP would maintain a database of multicast streams (src, grp) active along with the peer from which it had learned it. If the receiver RP is an anycast RP, it SHOULD re-transmit this register state message to each of the other anycast RP. An RP SHOULD not re-transmit a register state message it received from an another anycast-RP. -- The document date (March 19, 2018) is 1517 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 223, but not defined ** Downref: Normative reference to an Experimental RFC: RFC 3618 ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Downref: Normative reference to an Informational RFC: RFC 4609 ** Downref: Normative reference to an Experimental RFC: RFC 6559 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Protocol Independent Multicast (pim) A. Peter, Ed. 3 Internet-Draft Individual contributor 4 Intended status: Standards Track R. Kebler 5 Expires: September 20, 2018 V. Nagarajan 6 Juniper Networks, Inc. 7 T. Eckert 8 Huawei USA - Futurewei Technologies Inc. 9 S. Venaas 10 Cisco Systems, Inc. 11 March 19, 2018 13 Reliable Transport For PIM Register States 14 draft-anish-reliable-pim-registers-02 16 Abstract 18 This document introduces a hard-state, reliable transport for the 19 existing PIM-SM registers states. This eliminates the needs for 20 periodic NULL-registers and register-stop in response to each data- 21 register or NULL-registers. 23 This specification uses the existing PIM reliability mechanisms 24 defined by PIM Over Reliable Transport [RFC6559]. This is simply a 25 means to transmit reliable PIM messages and does not require the 26 support for Join/Prune messages over PORT as defined in [RFC6559]. 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 RFC2119 [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 https://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 September 20, 2018. 50 Copyright Notice 52 Copyright (c) 2018 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 (https://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. Reliable Register Overview . . . . . . . . . . . . . . . . . 4 69 3. Targeted Hellos . . . . . . . . . . . . . . . . . . . . . . . 4 70 3.1. New Hello Optional TLV's . . . . . . . . . . . . . . . . 5 71 3.2. Differences from Link-Level hellos . . . . . . . . . . . 5 72 3.3. Address in Hello message . . . . . . . . . . . . . . . . 6 73 3.4. Timer Values . . . . . . . . . . . . . . . . . . . . . . 6 74 3.5. Targeted Neighbor . . . . . . . . . . . . . . . . . . . . 6 75 4. Reliable Connection setup . . . . . . . . . . . . . . . . . . 7 76 4.1. Active FHR . . . . . . . . . . . . . . . . . . . . . . . 7 77 4.2. Connection setup between two RP's . . . . . . . . . . . . 7 78 4.3. Hello Generation ID and reconnect . . . . . . . . . . . . 7 79 4.4. Handling Connection or reachability loss . . . . . . . . 7 80 5. Anycast RP's . . . . . . . . . . . . . . . . . . . . . . . . 8 81 5.1. Targeted Hellos and Neighbors . . . . . . . . . . . . . . 8 82 5.2. Anycast-RP connection setup . . . . . . . . . . . . . . . 8 83 5.3. Anycast-RP state sync . . . . . . . . . . . . . . . . . . 8 84 5.4. Anycast-RP change . . . . . . . . . . . . . . . . . . . . 9 85 5.5. Anycast-RP with MSDP . . . . . . . . . . . . . . . . . . 9 86 6. PIM-registers and Interoperation with legacy PIM nodes . . . 10 87 6.1. Initial packet-loss avoidance with PORT . . . . . . . . . 10 88 6.2. First-Hop-Router does not support PORT . . . . . . . . . 10 89 6.3. RP does not support PORT . . . . . . . . . . . . . . . . 10 90 6.4. Data-Register free operations . . . . . . . . . . . . . . 10 91 7. PORT message . . . . . . . . . . . . . . . . . . . . . . . . 10 92 7.1. PORT register message TLV . . . . . . . . . . . . . . . . 10 93 7.2. Sending and receiving PORT register messages . . . . . . 12 94 7.3. PORT register-stop message TLV . . . . . . . . . . . . . 12 95 7.4. Sending and receiving PORT register stop messages . . . . 13 96 7.5. PORT Keep-Alive Message . . . . . . . . . . . . . . . . . 13 97 8. Management Considerations . . . . . . . . . . . . . . . . . . 13 98 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 99 9.1. PIM Hello Options TLV . . . . . . . . . . . . . . . . . . 14 100 9.2. PIM PORT Message Type . . . . . . . . . . . . . . . . . . 14 101 10. Security Considerations . . . . . . . . . . . . . . . . . . . 14 102 10.1. PIM Register Threats . . . . . . . . . . . . . . . . . . 14 103 10.2. Targeted Hello Threats . . . . . . . . . . . . . . . . . 15 104 10.3. TCP or SCTP security threats . . . . . . . . . . . . . . 15 105 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 106 11.1. Normative References . . . . . . . . . . . . . . . . . . 15 107 11.2. Informative References . . . . . . . . . . . . . . . . . 16 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 110 1. Introduction 112 Protocol Independent Multicast-Sparse Mode Register mechanism serves 113 the following purposes. 115 a, With a register, First-Hop-Router (FHR) informs the RP (that way 116 the network) that a particular multicast stream is active 118 b, A register helps avoid initial packet loss. (Initial packet loss 119 could happen in an anycast-RP deployment even when packet 120 registers are used.) 122 c, Through its periodic refreshes register keeps RP informed about 123 the aliveness of this multicast stream. 125 As it is defined in [RFC4601] , register mechanisms face limitations, 126 when the number of multicast streams on the network is high, 127 especially when one RP is expected to serve a large number of 128 streams. These problems are mainly due to these factors. 130 a, PIM register needs control-plane and data-plane intervention to 131 handle it. 133 b, Due to the nature of PIM register, First-Hop-Router and RP now 134 needs to maintain states and timers for each register state 135 entry. 137 c, PIM register's requirements for periodic refresh and expiry, is 138 quite aggressive and makes them vulnerable when the PIM speaker 139 could not find cycles to meet these needs 141 To take for instance a major multicast application the IPTV. With 142 the streaming servers connected to FHR. A restarting, FHR would 143 result in a burst of register messages at line rate. The RP may get 144 overloaded with packet registers. Which will continue untill RP is 145 able to create states and do a register-stop. In the meantime many 146 flows may go unserviced due to drops. In addition to affecting 147 multicast streams it may lead to starvation for other processing done 148 by the controlplane application. With Anycast RP, this becomes even 149 more tricky due to the control-plane's job to forward the registers 150 to the rp-set. 152 In general: PIM registers have limitation in connections across WAN. 153 It has no flow-control mechanisms, making PIM not compatible with 154 IETF transport/congestion control expectations. It is challenging to 155 deployed it over WAN or other bandwidth limited networks. High 156 amount of state: periodic retransmission creates undesirable 157 processing load. Especially with larger mesh-groups (re-send same 158 (S,G) N-times, periodically). 160 2. Reliable Register Overview 162 Reliable PIM register extends PIM PORT [RFC6559] to have PIM register 163 states to be sent over a reliable transport. 165 This document introduces 'targeted' hellos between any two PIM peers. 166 This helps in capability negotiation and discovery between two PIM 167 speakers (FHR and RP in the context of this document). Once this 168 discovery happens, First-Hop-Router would setup a reliable transport 169 connection based on the negotiated parameters. 171 Over this reliable connection, First-Hop-Router would start sending 172 to RP the source and group addresses of the multicast streams active 173 with it. When any of this stream stops, First-Hop-Router would sent 174 an update to RP about the streams that have stopped. This way once a 175 reliable connection is setup, First-Hop-Router would update RP with 176 its existing active multicast streams. Subsequently it would sent 177 incremental updates about the change to RP. 179 For a multicast application that may demand initial packets or for 180 bursty sources existing data-registers may be used. For them the RP 181 would now respond with a 'reliable'-register-stop, which could 182 persist until the First-Hop-Router withdraws the register-state. 184 3. Targeted Hellos 186 PIM hellos defined in PIM-SM [RFC4601] confines them to link level. 187 This document extends these hellos to support 'targeted' hellos. 189 Targeted hellos are identical to existing hellos messages except that 190 they would have an unicast address as its destination address. It 191 would traverse multiple hops using the unicast routing to reach the 192 targeted hello neighbor. 194 3.1. New Hello Optional TLV's 196 Option Type: Targeted hello 198 0 1 2 3 199 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 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Type = H1 (for alloc) | Length = 4 | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 |F|R| Reserved | Exp | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 Figure 1: PIM Hello Optional TLV 208 Assigned Hello Type values can be found in IANA PIM registry. 210 Type: This is subject to IANA allocation. Its stated as H1 for 211 reference 213 Length: Length in bytes for the value part of the Type/Length/Value 214 encoding fixed as 4. 216 F: To be set by a router that wants to be a First-Hop-Router. 218 R: To be set by a RP that is capable taking the role of an RP as per 219 the current states. 221 Reserved: Set to zero on transmission and ignored on receipt. 223 Exp: For experimental use [RFC3692]. One expected use of these bits 224 would be to signal experimental capabilities. For example, if a 225 router supports an experimental feature, it may set a bit to indicate 226 this. The default behavior, unless a router supports a particular 227 experiment, is to keep these bits reset and ignore the bits on 228 receipt. 230 3.2. Differences from Link-Level hellos 232 The Major differences that Link-Level-Hellos have over Interface 233 hellos are, 235 1. Destination address would be an unicast address unlike ALL-PIM- 236 ROUTER destination address for link-level hellos 238 2. TTL value would be the system default TTL 240 3. Targeted Hellos SHOULD carry Targeted Hello Optional TLV (Defined 241 in this document.) 243 4. Holdtime SHOULD NOT be set as 0xffff by a targeted hello sender, 244 and such hellos should be discarded up on receive. 246 3.3. Address in Hello message 248 When sending targeted hellos, the sender SHOULD send with its primary 249 reachable address (may be its loopback address) as the source address 250 for the hellos. The other addresses that are relevant SHOULD be 251 added in the secondary address list. 253 3.4. Timer Values 255 The timers relevant to this specification are in relation to PIM 256 hello. The recommended timer values are 258 1: PIM Targeted Hello default refresh time : 60s (2 * Default Link- 259 level hello time) 261 2: PIM Targeted Hello default hold time : 210s (3.5 times targeted 262 hello default refresh time) 264 3.5. Targeted Neighbor 266 A Targeted PIM neighbor is a neighbor-ship established by virtue of 267 exchanging targeted hello messages. 269 A First-Hop-Router (The initiator) that learns the RP's address would 270 start sending hellos to the known RP address (could be anycast- 271 address). 273 The RP (The Responder) when it receives this hello, would add sender 274 as a targeted neighbor and would respond to this targeted neighbor 275 from it primary address. The responder SHOULD also include its any- 276 cast address (If available) in the secondary address list. The 277 First-Hop-Router when receiving this hello would form a targeted 278 neighbor with the anycast address. 280 The RP upon hold-time-out for the neighbor would remove this neighbor 281 and its associated states. 283 The initiator or responder upon having a need to terminate a targeted 284 neighbor MAY send hello with hold-time as 0. 286 4. Reliable Connection setup 288 A reliable connection has to be setup between the First-Hop-Router 289 and RP for reliable registers to happen. Targeted hellos works as 290 the medium for discovery and capability-negotiation between the two 291 peers. 293 4.1. Active FHR 295 Once First-Hop-Router and RP discovery each other, First-Hop-Router 296 takes the active role. First-Hop-Router would listen for RP to 297 connect once it forms targeted neighbor-ship with RP. The RP would 298 be expected to use its primary address, which it would have used as 299 the source address in its PIM hellos. 301 4.2. Connection setup between two RP's 303 In a network if there happens to be two RP's which are First-Hop- 304 Router's too, then the mechanism could result in two connections 305 getting established. It's desirable to have just one connection 306 instead of two. First-Hop-Router could detect this condition the 307 when it receives hello with targeted hello header identifying that 308 the RP want to be First-Hop-Router too. 310 In this condition the connection setup could used the procedures 311 stated in PIM over reliable transport [RFC6559] 313 4.3. Hello Generation ID and reconnect 315 If RP or First-Hop-Router gets into a situation needing for 316 capability-renegotiation or reconnect, it would change the hello 317 generation ID (gen-ID) to notify it peer to reset all the states and 318 re-init this peering. The trigger for this could be configuration 319 change or local operating parameter change, restart, etc. . . 321 4.4. Handling Connection or reachability loss 323 Connection loss or reachability loss could happen for one or more of 324 the following reasons 326 1: PORT Keep-alive time out 328 2: Targeted neighbor loss 330 3: Reliable Connection close 332 Upon detecting one of these conditions, the connection with the peer 333 SHOULD be closed immediately and the states created by the peer 334 SHOULD be cleared after a grace-period, long enough for the peer to 335 re-establish connection and re-sync the states. 337 This interval for re-sync would involve the initial time needed for 338 re-establishing the connection, followed by transmission and 339 reception of the states from FHR to RP over the reliable connection. 341 The ideal interval for this re-sync period could not be predicted, 342 hence the this should be a configurable parameter with default value 343 as 300s. 345 5. Anycast RP's 347 PIM uses Anycast-RP [RFC4610] as a mechanism for RP redundancy. This 348 section describes how anycast-RP would work with this specification. 350 5.1. Targeted Hellos and Neighbors 352 An RP that serves an anycast RP address, would know the primary 353 addresses of other RP's serving the anycast address. These anycast- 354 RP's would form a full mesh of targeted hello-neighbor-ships. In its 355 targeted hello options tlv, the R bit MUST be set. The secondary 356 address list in the PIM hello message SHOULD include the anycast- 357 addresses that the sender is servicing. 359 5.2. Anycast-RP connection setup 361 A full mesh of connection is needed among the anycast-RP's of the 362 same anycast address. Once targeted neighbor-ship is established, it 363 would use the PIM PORT [RFC6559] procedures to setup reliable 364 connection among them. 366 5.3. Anycast-RP state sync 368 An anycast-RP that gets the register state from a peer who's address 369 is in the RP-set of address for the given group would update the 370 register state and would retain the state. If the peer address is 371 not in the RP-set address for the RP-group range, then the RP would 372 replicate the state to all the other RP's in the RP-set. This 373 procedure and forwarding rules are similar to the existing forwarding 374 rules in Anycast-rp [RFC4610] register specification. 376 An RP should identify register state as a combinations of (source, 377 group, 'PORT connection'). Where 'PORT connection' is the reliable 378 connection with the PORT peer which had reported this s,g. Following 379 considerations are made for a register-state identity. 381 A. Reconnect: Connection between RP and First-Hop-Router could get 382 re-established for various reasons. The register-states would 383 get retransmitted over the new connection. Then it should be 384 possible for RP to identify and timeout register-states on the 385 old connection and retain the right set of states. 387 B. DR-change: When DR in the First-Hop-LAN changes, a new First-Hop- 388 Router would be retransmitting the same set of SG's that are 389 already known and the old DR would be withdrawing the states 390 advertised by it. 392 C. FHR primary address change: In this case too connection would get 393 re-established and state handling would be similar to case A. 395 D. Multi-homed sources (but not on same LAN): In this case different 396 First-Hop-Routers could be sending the same register-states. 397 Then RP should be capable of identifying register-state along 398 with the peer. 400 5.4. Anycast-RP change 402 In the event of nearest anycast-RP changing over to a different 403 router, First-Hop-Router would detect that when it starts receiving 404 PIM hellos with a different primary address for the same anycast 405 address. This can also happen if the primary address of present 406 anycast-RP has changed. 408 Upon detecting this scenario, the First-Hop-Router would establish 409 connection and transmit its states to the new peer. Subsequently 410 older connection would get terminated due to neighbor timeout. 412 5.5. Anycast-RP with MSDP 414 MSDP [RFC3618] is an alternative mechanism for 'active multicast 415 stream state' synchronization between RP's. When MSDP is used, PIM's 416 anycast synchronization need not be used. An anycast-RP network 417 could use MSDP instead of PIM procedures for state synchronization 418 among anycast-RP's. This document does not state any change in MSDP 419 specification and usage 421 In such deployments, PIM will not have RP-set configured. As RP-set 422 address is not available PIM procedures for Anycast-RP 423 synchronization does not apply. 425 MSDP being a soft-state oriented protocol, it depends on frequent 426 state refreshes over the reliable TCP transport. The support for 427 mesh-groups in MSDP could be advantageous in some case. 429 6. PIM-registers and Interoperation with legacy PIM nodes 431 It may not be possible for PIM node to migrate altogether onto a 432 PORT-registers in one go. Also there could be a few nodes in the 433 network, which may not support PORT register states. This section 434 states how both could interoperate. 436 6.1. Initial packet-loss avoidance with PORT 438 If its found that a few streams in the multicast network has to have 439 initial packets to be delivered to the receiver, the existing PIM 440 register mechanism could be used for them. For these streams a PORT 441 register-stop message would be sent by the RP to First-Hop-Router. 443 6.2. First-Hop-Router does not support PORT 445 If the First-Hop-Router is not capable of doing PORT-register, then 446 it would not establish targeted hello neighbor-ship with the RP. 447 Hence reliable connection also would not be established. To handle 448 such scenarios RP should accept PIM register messages and should 449 respond to them with register-stop messages. 451 6.3. RP does not support PORT 453 If the RP is not capable of doing PORT-register, then it would not 454 respond to the targeted hellos from the RP. Hence reliable 455 connection also would not be established. In this case First-Hop- 456 Router could sent existing packet registers to RP. 458 6.4. Data-Register free operations 460 If initial packet loss is acceptable in a multicast network, then 461 Data-Registers could be avoided altogether in such networks. In such 462 network PORT-Register-state specified in this document alone would be 463 supported. 465 7. PORT message 467 This document defines new PORT register state message and PORT 468 register-stop messages, to the existing messages in PORT 469 specification. 471 7.1. PORT register message TLV 472 0 1 2 3 473 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 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Type = P1 (for alloc) | Message Length | 476 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 | Reserved | Exp. | 478 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 479 |B|N|A| Reserved-1 | 480 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 | src addr-1 z 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 z grp addr-1 | 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 z 2, 3, . . . z 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 |B|N|A| Reserved-n | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 489 | src addr-n z 490 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 491 z grp addr-n | 492 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 Figure 2: PORT Register State Message 496 Type: This is subject to IANA allocation. It would be next 497 unallocated value, which is referred untill allocation as P1. 499 Length: Length in bytes for the value part of the Type/Length/Value 501 B: As specified in [RFC4601] (set as 0 on send and ignore when 502 received) 504 N: As specified in [RFC4601] (set as 1 on send and ignore when 505 received.) 507 A: This flag signifies if the SG is to be Added or Deleted. When 508 cleared, it indicates that the First-Hop-Router is withdrawing the SG 509 . 511 src addr-x : This is the encoded source address of an ipv4/ipv6 512 stream 514 grp addr-x : This is the encoded group address of an ipv4/ipv6 stream 516 Reserved: Set to zero on transmission and ignored on receipt. These 517 reserved bits are for properties that apply to the entire message. 519 Reserved-n: Set to zero on transmission and ignored on receipt. 520 These reserved bits are for properties that apply to any particular 521 sg. 523 Exp: : For experimental use. 525 7.2. Sending and receiving PORT register messages 527 The First-Hop-Router upon learning a new stream would send a register 528 state add message to the corresponding RP. If the reliable 529 connection got setup later, then once the connection becomes 530 established it would send the entire list of streams active with it. 532 When KAT timer for a multicast stream expires, it would send an 533 update to RP to remove that stream from its list. 535 An RP would maintain a database of multicast streams (src, grp) 536 active along with the peer from which it had learned it. If the 537 receiver RP is an anycast RP, it SHOULD re-transmit this register 538 state message to each of the other anycast RP. An RP SHOULD not re- 539 transmit a register state message it received from an another 540 anycast-RP. 542 7.3. PORT register-stop message TLV 544 0 1 2 3 545 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 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 547 | Type = P2(for alloc) | Message Length | 548 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 549 | Reserved | Exp. | 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Reserved-1 | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | src addr-1 z 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 z grp addr-1 | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 z 2, 3, . . . z 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Reserved-n | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | src addr-n z 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 z grp addr-n | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 Figure 3: PORT Register Stop Message 568 Type: This is subject to IANA allocation. It would be next 569 unallocated value, which is referred untill allocation as P2. 571 Length: Length in bytes for the value part of the Type/Length/Value 573 src addr-x : This is the encoded source address of an ipv4/ipv6 574 stream 576 grp addr-x : This is the encoded group address of an ipv4/ipv6 stream 578 Reserved: Set to zero on transmission and ignored on receipt. These 579 reserved bits are for properties that apply to the entire message. 581 Reserved-n: Set to zero on transmission and ignored on receipt. 582 These reserved bits are for properties that apply to any particular 583 sg. 585 Exp: : For experimental use. 587 7.4. Sending and receiving PORT register stop messages 589 PORT register-stop messages are send only as a response to receiving 590 packet registers from a PIM peer, with which a reliable connection 591 has been established. If reliable connection is not available, the 592 RP should consider the peer as a legacy node and should respond to 593 this PIM register-stop message as defined in PIM-SM [RFC4601] 595 The First-Hop-Router up on receiving PORT-Register-Stop message 596 should treat that as an indication from RP that it does not require 597 the packets over the PIM tunnel and should stop sending register 598 messages. 600 7.5. PORT Keep-Alive Message 602 The PORT Keep-alive messages as specified in PIM over Reliable 603 Transport [RFC6559] would be used to check the liveliness of the peer 604 and the reliable session 606 8. Management Considerations 608 PORT-register is capable of configuration free operations. But its 609 recommended to have it as configuration controlled. 611 Implementation should provide knobs needed to stop supporting data- 612 registers on a router. 614 9. IANA Considerations 616 This specification introduces new TLV in PIM hello and in PIM PORT 617 messages. Hence the tlv ids for these needs IANA allocation 619 9.1. PIM Hello Options TLV 621 The following Hello TLV types needs IANA allocation. Place holder 622 are kept to differentiate the different types. 624 +------------------+----------+------------------------+------------+ 625 | Value | Length | Name | Reference | 626 +------------------+----------+------------------------+------------+ 627 | H1 (next- | 4 | Targeted-Hello-Options | This | 628 | available) | (Fixed) | | document | 629 +------------------+----------+------------------------+------------+ 631 Table 1: Place holder values for PIM Hello TLV type until IANA 632 allocation 634 9.2. PIM PORT Message Type 636 The following PIM PORT message TLV types needs IANA allocation. 637 Place holder are kept to differentiate the different types. 639 +---------------------+---------------------+---------------+ 640 | Value | Name | Reference | 641 +---------------------+---------------------+---------------+ 642 | P1 (Next available) | PORT Register-state | This document | 643 | P2 (Next available) | PORT Register-stop | This document | 644 +---------------------+---------------------+---------------+ 646 Table 2: Place holder values for PIM PORT TLV type for IANA 647 allocation 649 10. Security Considerations 651 10.1. PIM Register Threats 653 PIM register is considered as security vulnerability for PIM 654 networks. [RFC4609] The concern arises mainly due to the existing 655 PIM register protocol design where in any remote node could start 656 sending line-rate multicast traffic as PIM registers due to 657 malfunction, mis-configuration or from a malicious remote node. 659 10.2. Targeted Hello Threats 661 This document introduces targeted hellos. This could be a seen as a 662 new security threat. Targeted hellos are part of other IETF protocol 663 implementations, which are widely deployed. In future introduction 664 of a mechanism similar to those stated in RFC 7349 [RFC7349] could be 665 used in PIM. 667 10.3. TCP or SCTP security threats 669 The security perception for this is stated in [RFC6559]. 671 11. References 673 11.1. Normative References 675 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 676 Requirement Levels", BCP 14, RFC 2119, 677 DOI 10.17487/RFC2119, March 1997, 678 . 680 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 681 Discovery Protocol (MSDP)", RFC 3618, 682 DOI 10.17487/RFC3618, October 2003, 683 . 685 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 686 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 687 Protocol Specification (Revised)", RFC 4601, 688 DOI 10.17487/RFC4601, August 2006, 689 . 691 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 692 Independent Multicast - Sparse Mode (PIM-SM) Multicast 693 Routing Security Issues and Enhancements", RFC 4609, 694 DOI 10.17487/RFC4609, October 2006, 695 . 697 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 698 Independent Multicast (PIM)", RFC 4610, 699 DOI 10.17487/RFC4610, August 2006, 700 . 702 [RFC6559] Farinacci, D., Wijnands, IJ., Venaas, S., and M. 703 Napierala, "A Reliable Transport Mechanism for PIM", 704 RFC 6559, DOI 10.17487/RFC6559, March 2012, 705 . 707 11.2. Informative References 709 [RFC7349] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello 710 Cryptographic Authentication", RFC 7349, 711 DOI 10.17487/RFC7349, August 2014, 712 . 714 Authors' Addresses 716 Anish Peter (editor) 717 Individual contributor 718 Brunton Road 719 Bangalore, KA 560001 720 India 722 Email: anish.ietf@gmail.com 724 Robert Kebler 725 Juniper Networks, Inc. 726 1194 N. Mathilda Ave. 727 Sunnyvale, CA 94089 728 US 730 Email: rkebler@juniper.net 732 Vikram Nagarajan 733 Juniper Networks, Inc. 734 Electra, Exora Business Park 735 Bangalore, KA 560103 736 India 738 Email: vikramna@juniper.net 740 Toerless Eckert 741 Huawei USA - Futurewei Technologies Inc. 743 Email: tte+ietf@cs.fau.de 745 Stig Venaas 746 Cisco Systems, Inc. 748 Email: stig@cisco.com