idnits 2.17.1 draft-anish-pim-reliable-registers-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 : ---------------------------------------------------------------------------- ** 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 -- The document date (November 21, 2018) is 1988 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 227, but not defined ** Downref: Normative reference to an Experimental RFC: RFC 3618 ** Downref: Normative reference to an Informational RFC: RFC 4609 ** Downref: Normative reference to an Experimental RFC: RFC 6559 Summary: 4 errors (**), 0 flaws (~~), 2 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 Infinera 4 Intended status: Standards Track R. Kebler 5 Expires: May 25, 2019 V. Nagarajan 6 Juniper Networks, Inc. 7 T. Eckert 8 Huawei USA - Futurewei Technologies Inc. 9 S. Venaas 10 Cisco Systems, Inc. 11 November 21, 2018 13 Reliable Transport For PIM Register States 14 draft-anish-pim-reliable-registers-00 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 May 25, 2019. 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 . . . . . . . . . . . 6 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 . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . 9 84 5.4. Anycast-RP change . . . . . . . . . . . . . . . . . . . . 9 85 5.5. Anycast-RP with MSDP . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . 11 91 7. PORT message . . . . . . . . . . . . . . . . . . . . . . . . 11 92 7.1. PORT register message TLV . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . . . . . . . 14 97 8. Management Considerations . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . 15 102 10.1. PIM Register Threats . . . . . . . . . . . . . . . . . . 15 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 [RFC7761] , 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 [RFC7761] 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|P| 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 P: To be set by a device to indicate that its capable of handling 222 packet registers. Packet registers can be send only if either of the 223 peers have this bit set on their targeted hellos. 225 Reserved: Set to zero on transmission and ignored on receipt. 227 Exp: For experimental use [RFC3692]. One expected use of these bits 228 would be to signal experimental capabilities. For example, if a 229 router supports an experimental feature, it may set a bit to indicate 230 this. The default behavior, unless a router supports a particular 231 experiment, is to keep these bits reset and ignore the bits on 232 receipt. 234 3.2. Differences from Link-Level hellos 236 The Major differences that Link-Level-Hellos have over Interface 237 hellos are, 239 1. Destination address would be an unicast address unlike ALL-PIM- 240 ROUTER destination address for link-level hellos 242 2. TTL value would be the system default TTL 244 3. Targeted Hellos SHOULD carry Targeted Hello Optional TLV (Defined 245 in this document.) 247 4. Holdtime SHOULD NOT be set as 0xffff by a targeted hello sender, 248 and such hellos should be discarded up on receive. 250 3.3. Address in Hello message 252 When sending targeted hellos, the sender SHOULD send with its primary 253 reachable address (may be its loopback address) as the source address 254 for the hellos. The other addresses that are relevant SHOULD be 255 added in the secondary address list. 257 3.4. Timer Values 259 The timers relevant to this specification are in relation to PIM 260 hello. The recommended timer values are 262 1: PIM Targeted Hello default refresh time : 60s (2 * Default Link- 263 level hello time) 265 2: PIM Targeted Hello default hold time : 210s (3.5 times targeted 266 hello default refresh time) 268 3.5. Targeted Neighbor 270 A Targeted PIM neighbor is a neighbor-ship established by virtue of 271 exchanging targeted hello messages. 273 A First-Hop-Router (The initiator) that learns the RP's address would 274 start sending hellos to the known RP address (could be anycast- 275 address). 277 The RP (The Responder) when it receives this hello, would add sender 278 as a targeted neighbor and would respond to this targeted neighbor 279 from it primary address. The responder SHOULD also include its any- 280 cast address (If available) in the secondary address list. The 281 First-Hop-Router when receiving this hello would form a targeted 282 neighbor with the anycast address. 284 The RP upon hold-time-out for the neighbor would remove this neighbor 285 and its associated states. 287 The initiator or responder upon having a need to terminate a targeted 288 neighbor MAY send hello with hold-time as 0. 290 4. Reliable Connection setup 292 A reliable connection has to be setup between the First-Hop-Router 293 and RP for reliable registers to happen. Targeted hellos works as 294 the medium for discovery and capability-negotiation between the two 295 peers. 297 4.1. Active FHR 299 Once First-Hop-Router and RP discovery each other, First-Hop-Router 300 takes the active role. First-Hop-Router would listen for RP to 301 connect once it forms targeted neighbor-ship with RP. The RP would 302 be expected to use its primary address, which it would have used as 303 the source address in its PIM hellos. 305 4.2. Connection setup between two RP's 307 In a network if there happens to be two RP's which are First-Hop- 308 Router's too, then the mechanism could result in two connections 309 getting established. It's desirable to have just one connection 310 instead of two. First-Hop-Router could detect this condition the 311 when it receives hello with targeted hello header identifying that 312 the RP want to be First-Hop-Router too. 314 In this condition the connection setup could used the procedures 315 stated in PIM over reliable transport [RFC6559] 317 4.3. Hello Generation ID and reconnect 319 If RP or First-Hop-Router gets into a situation needing for 320 capability-renegotiation or reconnect, it would change the hello 321 generation ID (gen-ID) to notify it peer to reset all the states and 322 re-init this peering. The trigger for this could be configuration 323 change or local operating parameter change, restart, etc. . . 325 4.4. Handling Connection or reachability loss 327 Connection loss or reachability loss could happen for one or more of 328 the following reasons 330 1: PORT Keep-alive time out 332 2: Targeted neighbor loss 334 3: Reliable Connection close 336 Upon detecting one of these conditions, the connection with the peer 337 SHOULD be closed immediately and the states created by the peer 338 SHOULD be cleared after a grace-period, long enough for the peer to 339 re-establish connection and re-sync the states. 341 This interval for re-sync would involve the initial time needed for 342 re-establishing the connection, followed by transmission and 343 reception of the states from FHR to RP over the reliable connection. 345 The ideal interval for this re-sync period could not be predicted, 346 hence the this should be a configurable parameter with default value 347 as 300s. 349 5. Anycast RP's 351 PIM uses Anycast-RP [RFC4610] as a mechanism for RP redundancy. This 352 section describes how anycast-RP would work with this specification. 354 5.1. Targeted Hellos and Neighbors 356 An RP that serves an anycast RP address, would know the primary 357 addresses of other RP's serving the anycast address. These anycast- 358 RP's would form a full mesh of targeted hello-neighbor-ships. In its 359 targeted hello options tlv, the R bit MUST be set. The secondary 360 address list in the PIM hello message SHOULD include the anycast- 361 addresses that the sender is servicing. 363 5.2. Anycast-RP connection setup 365 A full mesh of connection is needed among the anycast-RP's of the 366 same anycast address. Once targeted neighbor-ship is established, it 367 would use the PIM PORT [RFC6559] procedures to setup reliable 368 connection among them. 370 5.3. Anycast-RP state sync 372 An anycast-RP that gets the register state from a peer who's address 373 is in the RP-set of address for the given group would update the 374 register state and would retain the state. If the peer address is 375 not in the RP-set address for the RP-group range, then the RP would 376 replicate the state to all the other RP's in the RP-set. This 377 procedure and forwarding rules are similar to the existing forwarding 378 rules in Anycast-rp [RFC4610] register specification. 380 An RP should identify register state as a combinations of (source, 381 group, 'PORT connection'). Where 'PORT connection' is the reliable 382 connection with the PORT peer which had reported this s,g. Following 383 considerations are made for a register-state identity. 385 A. Reconnect: Connection between RP and First-Hop-Router could get 386 re-established for various reasons. The register-states would 387 get retransmitted over the new connection. Then it should be 388 possible for RP to identify and timeout register-states on the 389 old connection and retain the right set of states. 391 B. DR-change: When DR in the First-Hop-LAN changes, a new First-Hop- 392 Router would be retransmitting the same set of SG's that are 393 already known and the old DR would be withdrawing the states 394 advertised by it. 396 C. FHR primary address change: In this case too connection would get 397 re-established and state handling would be similar to case A. 399 D. Multi-homed sources (but not on same LAN): In this case different 400 First-Hop-Routers could be sending the same register-states. 401 Then RP should be capable of identifying register-state along 402 with the peer. 404 5.4. Anycast-RP change 406 In the event of nearest anycast-RP changing over to a different 407 router, First-Hop-Router would detect that when it starts receiving 408 PIM hellos with a different primary address for the same anycast 409 address. This can also happen if the primary address of present 410 anycast-RP has changed. 412 Upon detecting this scenario, the First-Hop-Router would establish 413 connection and transmit its states to the new peer. Subsequently 414 older connection would get terminated due to neighbor timeout. 416 5.5. Anycast-RP with MSDP 418 MSDP [RFC3618] is an alternative mechanism for 'active multicast 419 stream state' synchronization between RP's. When MSDP is used, PIM's 420 anycast synchronization need not be used. An anycast-RP network 421 could use MSDP instead of PIM procedures for state synchronization 422 among anycast-RP's. This document does not state any change in MSDP 423 specification and usage 425 In such deployments, PIM will not have RP-set configured. As RP-set 426 address is not available PIM procedures for Anycast-RP 427 synchronization does not apply. 429 MSDP being a soft-state oriented protocol, it depends on frequent 430 state refreshes over the reliable TCP transport. The support for 431 mesh-groups in MSDP could be advantageous in some case. 433 6. PIM-registers and Interoperation with legacy PIM nodes 435 It may not be possible for PIM node to migrate altogether onto a 436 PORT-registers in one go. Also there could be a few nodes in the 437 network, which may not support PORT register states. This section 438 states how both could interoperate. 440 6.1. Initial packet-loss avoidance with PORT 442 If its found that a few streams in the multicast network has to have 443 initial packets to be delivered to the receiver, the existing PIM 444 register mechanism could be used for them. For these streams a PORT 445 register-stop message would be sent by the RP to First-Hop-Router. 447 6.2. First-Hop-Router does not support PORT 449 If the First-Hop-Router is not capable of doing PORT-register, then 450 it would not establish targeted hello neighbor-ship with the RP. 451 Hence reliable connection also would not be established. To handle 452 such scenarios RP should accept PIM register messages and should 453 respond to them with register-stop messages. 455 6.3. RP does not support PORT 457 If the RP is not capable of doing PORT-register, then it would not 458 respond to the targeted hellos from the RP. Hence reliable 459 connection also would not be established. In this case First-Hop- 460 Router could sent existing packet registers to RP. 462 6.4. Data-Register free operations 464 If initial packet loss is acceptable in a multicast network, then 465 Data-Registers could be avoided altogether in such networks. In such 466 network PORT-Register-state specified in this document alone would be 467 supported. 469 7. PORT message 471 This document defines new PORT register state message and PORT 472 register-stop messages, to the existing messages in PORT 473 specification. 475 7.1. PORT register message TLV 477 0 1 2 3 478 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 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | Type = P1 (for alloc) | Message Length | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | Reserved | Exp. | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 |B|N|A| Reserved-1 | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 | src addr-1 z 487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 488 z grp addr-1 | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 z 2, 3, . . . z 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 |B|N|A| Reserved-n | 493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 494 | src addr-n z 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 496 z grp addr-n | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 Figure 2: PORT Register State Message 501 Type: This is subject to IANA allocation. It would be next 502 unallocated value, which is referred untill allocation as P1. 504 Length: Length in bytes for the value part of the Type/Length/Value 506 B: As specified in [RFC7761] (set as 0 on send and ignore when 507 received) 508 N: As specified in [RFC7761] (set as 1 on send and ignore when 509 received.) 511 A: This flag signifies if the SG is to be Added or Deleted. When 512 cleared, it indicates that the First-Hop-Router is withdrawing the SG 513 . 515 src addr-x : This is the encoded source address of an ipv4/ipv6 516 stream 518 grp addr-x : This is the encoded group address of an ipv4/ipv6 stream 520 Reserved: Set to zero on transmission and ignored on receipt. These 521 reserved bits are for properties that apply to the entire message. 523 Reserved-n: Set to zero on transmission and ignored on receipt. 524 These reserved bits are for properties that apply to any particular 525 sg. 527 Exp: : For experimental use. 529 7.2. Sending and receiving PORT register messages 531 The First-Hop-Router upon learning a new stream would send a register 532 state add message to the corresponding RP. If the reliable 533 connection got setup later, then once the connection becomes 534 established it would send the entire list of streams active with it. 536 When KAT timer for a multicast stream expires, it would send an 537 update to RP to remove that stream from its list. 539 An RP would maintain a database of multicast streams (src, grp) 540 active along with the peer from which it had learned it. If the 541 receiver RP is an anycast RP, it SHOULD re-transmit this register 542 state message to each of the other anycast RP. An RP SHOULD NOT re- 543 transmit a register state message it received from an another 544 anycast-RP. 546 7.3. PORT register-stop message TLV 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Type = P2(for alloc) | Message Length | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | Reserved | Exp. | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Reserved-1 | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | src addr-1 z 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 z grp addr-1 | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 z 2, 3, . . . z 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 562 | Reserved-n | 563 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 | src addr-n z 565 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 z grp addr-n | 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 569 Figure 3: PORT Register Stop Message 571 Type: This is subject to IANA allocation. It would be next 572 unallocated value, which is referred untill allocation as P2. 574 Length: Length in bytes for the value part of the Type/Length/Value 576 src addr-x : This is the encoded source address of an ipv4/ipv6 577 stream 579 grp addr-x : This is the encoded group address of an ipv4/ipv6 stream 581 Reserved: Set to zero on transmission and ignored on receipt. These 582 reserved bits are for properties that apply to the entire message. 584 Reserved-n: Set to zero on transmission and ignored on receipt. 585 These reserved bits are for properties that apply to any particular 586 sg. 588 Exp: : For experimental use. 590 7.4. Sending and receiving PORT register stop messages 592 PORT register-stop messages are send only as a response to receiving 593 packet registers from a PIM peer, with which a reliable connection 594 has been established. If reliable connection is not available, the 595 RP should consider the peer as a legacy node and should respond to 596 this PIM register-stop message as defined in PIM-SM [RFC7761] 598 The First-Hop-Router up on receiving PORT-Register-Stop message 599 should treat that as an indication from RP that it does not require 600 the packets over the PIM tunnel and should stop sending register 601 messages. 603 7.5. PORT Keep-Alive Message 605 The PORT Keep-alive messages as specified in PIM over Reliable 606 Transport [RFC6559] would be used to check the liveliness of the peer 607 and the reliable session 609 8. Management Considerations 611 PORT-register is capable of configuration free operations. But its 612 recommended to have it as configuration controlled. 614 Implementation should provide knobs needed to stop supporting data- 615 registers on a router. 617 9. IANA Considerations 619 This specification introduces new TLV in PIM hello and in PIM PORT 620 messages. Hence the tlv ids for these needs IANA allocation 622 9.1. PIM Hello Options TLV 624 The following Hello TLV types needs IANA allocation. Place holder 625 are kept to differentiate the different types. 627 +------------------+----------+------------------------+------------+ 628 | Value | Length | Name | Reference | 629 +------------------+----------+------------------------+------------+ 630 | H1 (next- | 4 | Targeted-Hello-Options | This | 631 | available) | (Fixed) | | document | 632 +------------------+----------+------------------------+------------+ 634 Table 1: Place holder values for PIM Hello TLV type until IANA 635 allocation 637 9.2. PIM PORT Message Type 639 The following PIM PORT message TLV types needs IANA allocation. 640 Place holder are kept to differentiate the different types. 642 +---------------------+---------------------+---------------+ 643 | Value | Name | Reference | 644 +---------------------+---------------------+---------------+ 645 | P1 (Next available) | PORT Register-state | This document | 646 | P2 (Next available) | PORT Register-stop | This document | 647 +---------------------+---------------------+---------------+ 649 Table 2: Place holder values for PIM PORT TLV type for IANA 650 allocation 652 10. Security Considerations 654 10.1. PIM Register Threats 656 PIM register is considered as security vulnerability for PIM 657 networks. [RFC4609] The concern arises mainly due to the existing 658 PIM register protocol design where in any remote node could start 659 sending line-rate multicast traffic as PIM registers due to 660 malfunction, mis-configuration or from a malicious remote node. 662 10.2. Targeted Hello Threats 664 This document introduces targeted hellos. This could be a seen as a 665 new security threat. Targeted hellos are part of other IETF protocol 666 implementations, which are widely deployed. In future introduction 667 of a mechanism similar to those stated in RFC 7349 [RFC7349] could be 668 used in PIM. 670 10.3. TCP or SCTP security threats 672 The security perception for this is stated in [RFC6559]. 674 11. References 676 11.1. Normative References 678 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 679 Requirement Levels", BCP 14, RFC 2119, 680 DOI 10.17487/RFC2119, March 1997, 681 . 683 [RFC3618] Fenner, B., Ed. and D. Meyer, Ed., "Multicast Source 684 Discovery Protocol (MSDP)", RFC 3618, 685 DOI 10.17487/RFC3618, October 2003, 686 . 688 [RFC4609] Savola, P., Lehtonen, R., and D. Meyer, "Protocol 689 Independent Multicast - Sparse Mode (PIM-SM) Multicast 690 Routing Security Issues and Enhancements", RFC 4609, 691 DOI 10.17487/RFC4609, October 2006, 692 . 694 [RFC4610] Farinacci, D. and Y. Cai, "Anycast-RP Using Protocol 695 Independent Multicast (PIM)", RFC 4610, 696 DOI 10.17487/RFC4610, August 2006, 697 . 699 [RFC6559] Farinacci, D., Wijnands, IJ., Venaas, S., and M. 700 Napierala, "A Reliable Transport Mechanism for PIM", 701 RFC 6559, DOI 10.17487/RFC6559, March 2012, 702 . 704 [RFC7761] Fenner, B., Handley, M., Holbrook, H., Kouvelas, I., 705 Parekh, R., Zhang, Z., and L. Zheng, "Protocol Independent 706 Multicast - Sparse Mode (PIM-SM): Protocol Specification 707 (Revised)", STD 83, RFC 7761, DOI 10.17487/RFC7761, March 708 2016, . 710 11.2. Informative References 712 [RFC7349] Zheng, L., Chen, M., and M. Bhatia, "LDP Hello 713 Cryptographic Authentication", RFC 7349, 714 DOI 10.17487/RFC7349, August 2014, 715 . 717 Authors' Addresses 719 Anish Peter (editor) 720 Infinera 721 Brunton Road 722 Bangalore, KA 560025 723 India 725 Email: anish.ietf@gmail.com 727 Robert Kebler 728 Juniper Networks, Inc. 729 1194 N. Mathilda Ave. 730 Sunnyvale, CA 94089 731 US 733 Email: rkebler@juniper.net 734 Vikram Nagarajan 735 Juniper Networks, Inc. 736 Electra, Exora Business Park 737 Bangalore, KA 560103 738 India 740 Email: vikramna@juniper.net 742 Toerless Eckert 743 Huawei USA - Futurewei Technologies Inc. 745 Email: tte+ietf@cs.fau.de 747 Stig Venaas 748 Cisco Systems, Inc. 750 Email: stig@cisco.com