idnits 2.17.1 draft-ietf-pim-port-05.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 15, 2011) is 4819 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-01) exists of draft-gulrajani-pim-hello-intid-00 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 4601 (Obsoleted by RFC 7761) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) -- Duplicate reference: RFC4601, mentioned in 'HELLO-OPT', was also mentioned in 'RFC4601'. -- Obsolete informational reference (is this intentional?): RFC 4601 (ref. 'HELLO-OPT') (Obsoleted by RFC 7761) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Farinacci 3 Internet-Draft IJ. Wijnands 4 Intended status: Experimental S. Venaas 5 Expires: August 19, 2011 cisco Systems 6 M. Napierala 7 AT&T Labs 8 February 15, 2011 10 A Reliable Transport Mechanism for PIM 11 draft-ietf-pim-port-05.txt 13 Abstract 15 This draft describes how a reliable transport mechanism can be used 16 by the PIM protocol to optimize CPU and bandwidth resource 17 utilization by eliminating periodic Join/Prune message transmission. 18 This draft proposes a modular extension to PIM to use either the TCP 19 or SCTP transport protocol. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 19, 2011. 38 Copyright Notice 40 Copyright (c) 2011 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 57 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 58 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 6 59 3. PIM Hello Options . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1. PIM over the TCP Transport Protocol . . . . . . . . . . . 8 61 3.2. PIM over the SCTP Transport Protocol . . . . . . . . . . . 9 62 3.3. Interface ID . . . . . . . . . . . . . . . . . . . . . . . 10 63 4. Establishing Transport Connections . . . . . . . . . . . . . . 11 64 4.1. Connection Security . . . . . . . . . . . . . . . . . . . 12 65 4.2. Connection Maintenance . . . . . . . . . . . . . . . . . . 13 66 4.3. Actions When a Connection Goes Down . . . . . . . . . . . 14 67 4.4. Moving from PORT to Datagram Mode . . . . . . . . . . . . 15 68 4.5. On-demand versus Pre-configured Connections . . . . . . . 15 69 4.6. Possible Hello Suppression Considerations . . . . . . . . 16 70 4.7. Avoiding a Pair of TCP Connections between Neighbors . . . 16 71 5. PORT Message Definition . . . . . . . . . . . . . . . . . . . 18 72 5.1. PORT Join/Prune Message . . . . . . . . . . . . . . . . . 19 73 5.2. PORT Keep-alive Message . . . . . . . . . . . . . . . . . 20 74 5.3. PORT Options . . . . . . . . . . . . . . . . . . . . . . . 21 75 6. Explicit Tracking . . . . . . . . . . . . . . . . . . . . . . 23 76 7. Multiple Address-Family Support . . . . . . . . . . . . . . . 24 77 8. Miscellany . . . . . . . . . . . . . . . . . . . . . . . . . . 25 78 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 79 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 80 10.1. PORT Message Type Registry . . . . . . . . . . . . . . . . 27 81 10.2. PORT Option Type Registry . . . . . . . . . . . . . . . . 27 82 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 28 83 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 84 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 85 13.1. Normative References . . . . . . . . . . . . . . . . . . . 30 86 13.2. Informative References . . . . . . . . . . . . . . . . . . 30 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 89 1. Introduction 91 The goals of this specification are: 93 o To create a simple incremental mechanism to provide reliable PIM 94 message delivery in PIM version 2 for use with PIM Sparse-Mode 95 [RFC4601] (including Source-Specific Multicast) and Bidirectional 96 PIM [RFC5015]. 98 o The reliable transport mechanism will be used for Join-Prune 99 message transmission only. 101 o When a router supports this specification, it need not use the 102 reliable transport mechanism with every neighbor. That is, 103 negotiation on a per neighbor basis will occur. 105 The explicit non-goals of this specification are: 107 o Changes to the PIM message formats as defined in [RFC4601]. 109 o Provide support for automatic switching between the reliable 110 transport mechanism and the regular PIM mechanism defined in 111 [RFC4601]. Two routers that are PIM neighbors on a link will 112 always use the reliable transport mechanism if and only if both 113 have reliable transport enabled. 115 This document will specify how periodic Join/Prune message 116 transmission can be eliminated by using TCP [RFC0793] or SCTP 117 [RFC4960] as the reliable transport mechanism for Join/Prune 118 messages. 120 This specification enables greater scalability in terms of control 121 traffic overhead. However, for routers connected to multi-access 122 links that comes at the price of increased control plane state 123 overhead and the control plane overhead required to maintain this 124 state. 126 In many existing and emerging networks, particularly wireless and 127 mobile satellite systems, link degradation due to weather, 128 interference, and other impairments can result in temporary spikes in 129 the packet loss. In these environments, periodic PIM joining can 130 cause join latency when messages are lost causing a retransmission 131 only 60 seconds later. By applying a reliable transport, a lost join 132 is retransmitted rapidly. Furthermore, when the last user leaves a 133 multicast group, any lost prune is similarly repaired and the 134 multicast stream is quickly removed from the wireless/satellite link. 135 Without a reliable transport, the multicast transmission could 136 otherwise continue until it timed out, roughly 3 minutes later. As 137 network resources are at a premium in many of these environments, 138 rapid termination of the multicast stream is critical for maintaining 139 efficient use of bandwidth. 141 1.1. Requirements Notation 143 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 144 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 145 document are to be interpreted as described in [RFC2119]. 147 1.2. Definitions 149 PORT: Stands for PIM Over Reliable Transport. Which is the short 150 form for describing the mechanism in this specification where PIM 151 can use the TCP or SCTP transport protocol. 153 Periodic Join/Prune message: A Join/Prune message sent periodically 154 to refresh state. 156 Incremental Join/Prune message: A Join/Prune message sent as a 157 result of state creation or deletion events. Also known as a 158 triggered message. 160 Native Join/Prune message: A Join/Prune message which is carried 161 with an IP protocol type of PIM. 163 PORT Join/Prune message: A Join/Prune message using TCP or SCTP for 164 transport. 166 Datagram Mode: The current procedures PIM uses by encapsulating 167 Join/Prune messages in IP packets sent either triggered or 168 periodically. 170 PORT Mode: Procedures used by PIM defined in this specification for 171 sending Join/Prune messages over the TCP or SCTP transport layer. 173 2. Protocol Overview 175 PIM Over Reliable Transport (PORT) is a simple extension to PIMv2 for 176 refresh reduction of PIM Join/Prune messages. It involves sending 177 incremental rather than periodic Join/Prune messages over a TCP/SCTP 178 connection between PIM neighbors. 180 PORT only applies to PIM Sparse-Mode [RFC4601] and Bidirectional PIM 181 [RFC5015] Join/Prune messages. 183 This document does not restrict PORT to any specific link types. 184 However, the use of PORT on e.g. multi-access LANs with many PIM 185 neighbors should be carefully evaluated. This due to the fact that 186 there may be a full mesh of PORT connections, and that explicit 187 tracking of all PIM PORT routers is required. 189 PORT can be incrementally used on a link between PORT capable 190 neighbors. Routers which are not PORT capable can continue to use 191 PIM in Datagram Mode. PORT capability is detected using new PORT 192 Capable PIM Hello Options. 194 Once PORT is enabled on an interface and a PIM neighbor also 195 announces that it is PORT enabled, only PORT Join/Prune messages will 196 be used. That is, only PORT Join/Prune messages are accepted from, 197 and sent to, that particular neighbor. Native Join/Prune messages 198 are still used for PIM neighbors that are not PORT enabled. 200 PORT Join/Prune messages are sent using a TCP/SCTP connection. When 201 two PIM neighbors are PORT enabled, both for TCP or both for SCTP, 202 they will immediately, or on-demand, establish a connection. If the 203 connection goes down, they will again immediately, or on-demand, try 204 to reestablish the connection. No Join/Prune messages (neither 205 Native nor PORT) are sent while there is no connection. Also, any 206 received native Join/Prune messages from that neighbor are discarded, 207 even when the connection is down. 209 When PORT is used, only incremental Join/Prune messages are sent from 210 downstream routers to upstream routers. As such, downstream routers 211 do not generate periodic Join/Prune messages for state for which the 212 RPF neighbor is PORT-capable. 214 For Joins and Prunes, which are received over a TCP/SCTP connection, 215 the upstream router does not start or maintain timers on the outgoing 216 interface entry. Instead, it keeps track of which downstream routers 217 have expressed interest. An interface is deleted from the outgoing 218 interface list only when all downstream routers on the interface, no 219 longer wish to receive traffic. If there also are native joins/ 220 prunes from non-PORT neighbor, then one can maintain timers on the 221 outgoing interface entry as usual, while at the same time keep track 222 of each of the downstream PORT joins/prunes. 224 There is no change proposed for the PIM Join/Prune packet format. 225 However, for Join/Prune messages sent over TCP/SCTP connections, no 226 IP Header is included. Each message is contained in a PORT message. 227 See section Section 5 for details on the PORT message. 229 3. PIM Hello Options 231 3.1. PIM over the TCP Transport Protocol 233 Option Type: PIM-over-TCP Capable 235 0 1 2 3 236 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 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Type = 27 | Length = 4 + X | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | TCP Connection ID AFI | Reserved | Exp | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | TCP Connection ID | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Allocated Hello Type values can be found in [HELLO-OPT]. 247 When a router is configured to use PIM over TCP on a given interface, 248 it MUST include the PIM-over-TCP Capable hello option in its Hello 249 messages for that interface. If a router is explicitly disabled from 250 using PIM over TCP, it MUST NOT include the PIM-over-TCP Capable 251 hello option in its Hello messages. 253 All Hello messages containing the PIM-over-TCP Capable hello option, 254 MUST also contain the Interface ID hello option, see section . 256 Implementations MAY provide a configuration option to enable or 257 disable PORT functionality. We RECOMMEND that this capability be 258 disabled by default. 260 Length: Length in bytes for the value part of the Type/Length/Value 261 encoding; where X is the number of bytes that make up the 262 Connection ID field. X is 4 when AFI of value 1 (IPv4) is used, 263 16 when AFI of value 2 (IPv6) is used, and 0 if AFI of value 0 is 264 used [AFI]. 266 TCP Connection ID AFI: The AFI value to describe the address-family 267 of the address of the TCP Connection ID field. When this field is 268 0, a mechanism outside the scope of this document is used to 269 obtain the addresses used to establish the TCP connection. 271 Reserved: Set to zero on transmission and ignored on receipt. 273 Exp: For experimental use [RFC3692]. 275 TCP Connection ID: An IPv4 or IPv6 address used to establish the 276 TCP connection. This field is omitted (length 0) for the 277 Connection ID AFI 0. 279 3.2. PIM over the SCTP Transport Protocol 281 Option Type: PIM-over-SCTP Capable 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Type = 28 | Length = 4 + X | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | SCTP Connection ID AFI | Reserved | Exp | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | SCTP Connection ID | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 Allocated Hello Type values can be found in [HELLO-OPT]. 295 When a router is configured to use PIM over SCTP on a given 296 interface, it MUST include the PIM-over-SCTP Capable hello option in 297 its Hello messages for that interface. If a router is explicitly 298 disabled from using PIM over SCTP, it MUST NOT include the PIM-over- 299 SCTP Capable hello option in its Hello messages. 301 All Hello messages containing the PIM-over-SCTP Capable hello option, 302 MUST also contain the Interface ID hello option, see section . 304 Implementations MAY provide a configuration option to enable or 305 disable PORT functionality. We RECOMMEND that this capability be 306 disabled by default. 308 Length: Length in bytes for the value part of the Type/Length/Value 309 encoding; where X is the number of bytes that make up the 310 Connection ID field. X is 4 when AFI of value 1 (IPv4) is used, 311 16 when AFI of value 2 (IPv6) is used, and 0 if AFI of value 0 is 312 used [AFI]. 314 SCTP Connection ID AFI: The AFI value to describe the address- 315 family of the address of the SCTP Connection ID field. When this 316 field is 0, a mechanism outside the scope of this document is used 317 to obtain the addresses used to establish the SCTP connection. 319 Reserved: Set to zero on transmission and ignored on receipt. 321 Exp: For experimental use [RFC3692]. 323 SCTP Connection ID: An IPv4 or IPv6 address used to establish the 324 SCTP connection. This field is omitted (length 0) for the 325 Connection ID AFI 0. 327 3.3. Interface ID 329 All Hello messages containing PIM-over-TCP Capable or PIM-over-SCTP 330 Capable hello options, MUST also contain the Interface ID hello 331 option [I-D.gulrajani-pim-hello-intid]. 333 The Interface ID is used to associate the connection a Join/Prune 334 message is received over, with an interface which is added or removed 335 from an oif-list. When unnumbered interfaces are used or when a 336 single Transport connection is used for sending and receiving Join/ 337 Prune messages over multiple interfaces, the Interface ID is used to 338 convey the interface from Join/Prune message sender to Join/Prune 339 message receiver. The value of the Interface ID hello option in 340 Hellos sent on an interface, must be the same as the Interface ID 341 value in all PORT Join/Prune messages sent to a PIM neighbor on that 342 interface. 344 The Interface ID need only uniquely identify an interface of a 345 router, it does not need to identify which router the interface 346 belongs to. This means that the Router ID part of the Interface ID 347 MAY be 0. For details on the Router ID and the value 0, see 348 [I-D.gulrajani-pim-hello-intid]. 350 4. Establishing Transport Connections 352 While a router interface is PORT enabled, a PIM-over-TCP or a PIM- 353 over-SCTP option is included in the PIM Hello messages sent on that 354 interface. When a router on a PORT-enabled interface receives a 355 Hello message containing a PIM-over-TCP/PIM-over-SCTP Option from a 356 new neighbor, or an existing neighbor that did not previously include 357 the option, it switches to PORT mode for that particular neighbor. 359 When a router switches to PORT mode for a neighbor, it stops sending 360 and accepting Native Join/Prune messages for that neighbor. Any 361 state from previous Native Join/Prune messages is left to expire as 362 normal. It will also attempt to establish a Transport connection 363 (TCP or SCTP) with the neighbor. If both the router and its neighbor 364 have announced both PIM-over-TCP and PIM-over-SCTP options, SCTP MUST 365 be used. 367 When the router is using TCP, it will compare the TCP Connection ID 368 it announced in the PIM-over-TCP Capable Option with the TCP 369 Connection ID in the Hello received from the neighbor. The router 370 with the lower Connection ID will do an active Transport open to the 371 neighbor Connection ID. The router with the higher Connection ID 372 will do a passive Transport open. An implementation may open 373 connections only on-demand, in that case it may be that the neighbor 374 with the higher Connection ID does the active open, see Section 4.5. 375 Note that the source address of the active open must be the announced 376 Connection ID. 378 When the router is using SCTP, the IP address comparison need not be 379 done since the SCTP protocol can handle call collision. 381 If PORT is used both for IPv4 and IPv6, both IPv4 and IPv6 PIM Hello 382 messages are sent, both containing PORT Hello options. If two 383 neighbors announce the same transport (TCP or SCTP) and the same 384 Connection ID in the IPv4 and IPv6 Hello messages, then only one 385 connection is established and is shared. Otherwise, two connections 386 are established and are used separately. 388 The PIM router that performs the active open initiates the connection 389 with a locally generated source transport port number and a well- 390 known destination transport port number. The PIM router that 391 performs the passive open listens on the well-known local transport 392 port number and does not qualify the remote transport port number. 393 See Section 5 for well-known port number assignment for PORT. 395 When a Transport connection is established (or reestablished), the 396 two routers MUST both send a full set of Join/Prune messages for 397 state for which the other router is the upstream neighbor. This is 398 needed to ensure that the upstream neighbor has the correct state. 399 When moving from Datagram mode, or when the connection has gone down, 400 the router cannot be sure that all the previous Join/Prune state was 401 received by the neighbor. Any state received while in Datagram mode 402 that is not refreshed, will be left to expire. 404 It is possible that a router starts sending Hello messages with a new 405 Connection ID, e.g. due to configuration changes. One MUST always 406 use the last announced and last seen Connection IDs. When a 407 Connection ID changes, if the previously used connection is not 408 needed (there are no other PIM neighborships using the same pair of 409 Connection IDs), both peers MUST attempt a graceful shutdown of the 410 connection. Next (even if the old connection is still needed), they 411 MUST, unless a connection already exists with the new Connection IDs, 412 immediately or on-demand attempt to establish a new connection with 413 the new Connection IDs. 415 Normally the Interface ID would not change while a connection is up. 416 However, if it does, it should not affect the connection. It just 417 means that when subsequent PORT join/prune messages are received, 418 they should be matched against the last seen Interface ID. 420 Note that, a Join sent over a Transport connection will only be seen 421 by the upstream router, and thus will not cause routers on the link 422 that do not use PIM PORT with the upstream router to possibly delay 423 the refresh of Join state for the same state. Similarly, a Prune 424 sent over a Transport connection will only be seen by the upstream 425 router, and will thus never cause routers on the link that do not use 426 PIM PORT with the upstream router, to send a Join to override this 427 Prune. 429 Note also, that a datagram PIM Join/Prune message for a said (S,G) or 430 (*,G) sent by some router on a link will not cause routers on the 431 same link that use a Transport connection with the upstream router 432 for that state, to suppress the refresh of that state to the upstream 433 router (because they don't need to periodically refresh this state) 434 or to send a Join to override a Prune (as the upstream router will 435 only stop forwarding the traffic when all joined routers that use a 436 Transport connection have explicitly sent a Prune for this state, as 437 explained in Section 6). 439 4.1. Connection Security 441 TCP/SCTP packets MUST be sent with a TTL/Hop Limit of 255 to 442 facilitate enabling of the Generalized TTL Security Mechanism (GTSM) 443 [RFC5082]. Implementations SHOULD provide a configuration option to 444 enable the GTSM check. This means checking that inbound packets from 445 directly connected neighbors have a TTL/Hop Limit of 255, but MAY 446 also allow for a different TTL/Hop Limit threshold to check that the 447 sender is within a certain number of router hops. The GTSM check 448 SHOULD be disabled by default. 450 Implementations SHOULD support the TCP Authentication Option (TCP-AO) 451 [RFC5925]. 453 4.2. Connection Maintenance 455 TCP is designed to keep connections up indefinitely during a period 456 of network disconnection. If a PIM-over-TCP router fails, the TCP 457 connection may stay up until the neighbor actually reboots, and even 458 then it may continue to stay up until you actually try to send the 459 neighbor some information. This is particularly relevant to PIM, 460 since the flow of Join/Prune messages might be in only one direction, 461 and the downstream neighbor might never get any indication via TCP 462 that the other end of the connection is not really there. 464 One can quicker detect that a PORT connection is not working by 465 regularly sending PORT messages. PORT in itself does not require any 466 periodic signaling. PORT Join/Prune messages are only sent when 467 there is a state change. If the state changes are not frequent 468 enough, a PORT Keep-Alive message can be sent instead. E.g. if an 469 implementation wants to send a PORT message, to check that the 470 connection is working, at least every 60 seconds, then whenever there 471 is 60 seconds since the the previous message, a Keep-Alive message 472 could be sent. If there were less than 60 seconds between each Join/ 473 Prune, no Keep-Alive messages would be needed. Implementations 474 SHOULD support the use of PORT Keep-Alive messages. We RECOMMEND 475 this to be optional, allowing network administrators to use it as 476 needed. Note that Keep-Alives can be used by a peer, independently 477 of whether the other peer supports it. 479 As described in the previous paragraph, an implementation can make 480 use of Keep-Alives to regularly send messages and detect when a 481 connection is not working. For TCP the connection will be reset if 482 no TCP ACKs are received. A quicker and more reliable way of 483 detecting that a connection is not working, is to send regular PORT 484 messages, and have our peer take down the connection if it doesn't 485 receive them. This can be done by sending Keep-alive messages with a 486 non-zero holdtime value. If the last received Keep-alive message had 487 a non-zero holdtime, one tears down the connection if the time 488 measured in seconds since the last processed PORT message exceeds the 489 specified holdtime. 491 Implementations SHOULD support Keep-Alive messages. An 492 implementation that supports Keep-Alive messages acts as follows when 493 processing a received PORT message. When processing a Keep-Alive 494 message with a non-zero Holdtime value, it MUST set a timer to the 495 value. We call this timer Connection Expiry Timer (CET). If the CET 496 is already running, it MUST be reset to the new value. When 497 processing a Keep-Alive message with a zero Holdtime value, the CET 498 MUST be stopped if running. When processing a PORT message other 499 than Keep-Alive, the CET MUST be reset to the last received Holdtime 500 value if running. If the CET is not running, no action is taken. If 501 the CET expires, the connection SHOULD be shut down. 503 It is possible that a router receives Join/Prune messages for an 504 interface/link that is down. As long as the neighbor has not 505 expired, we RECOMMEND processing those messages as usual. If they 506 are ignored, then the router SHOULD ensure it gets a full update for 507 that interface when it comes back up. This can be done by changing 508 the GenID, or by terminating and reestablishing the connection. 510 If a PORT neighbor changes its GenID and a connection is established 511 or attempting to be established, the local side should generally tear 512 down the connection and do as described in Section 4.3. However, if 513 the connection is shared by multiple interfaces and the GenID changes 514 only for one of them, then there was not a full restart, and one may 515 simply send a full update similar to other cases when a GenID changes 516 for an upstream neighbor. 518 4.3. Actions When a Connection Goes Down 520 A connection may go down for a variety of reasons. It may be due to 521 an error condition, or a configuration change. A connection SHOULD 522 be shut down as soon as there are no more PIM neighborships using it. 523 That is, for the connection we have associated local and remote 524 Connection IDs. When there is no PIM neighbor with that particular 525 remote connection ID on any interface where we announce the local 526 connection ID, the connection SHOULD be shut down. This may happen 527 when a new connection ID is configured, PORT is disabled, or a PIM 528 neighbor expires. 530 If a PIM neighbor expires, one should free connection state and 531 downstream oif-list state for the neighbor. A downstream router, 532 when an upstream neighboring router has expired, will simply update 533 the RPF for the corresponding state to a new neighbor where it would 534 trigger Join/Prune messages like it would in [RFC4601]. It is 535 required of a PIM router to clear its neighbor table for a neighbor 536 who has timed out due to neighbor holdtime expiration. 538 When a connection is no longer available between two PORT enabled PIM 539 neighbors, they MUST immediately, or on-demand, try to reestablish 540 the connection following the normal rules for connestion 541 establishment. The neighbors MUST also start expiry timers so that 542 all oif-list state for the neighbor using the connection, gets 543 expired after JP_HOLDTIME, unless it later gets refreshed by 544 receiving new Join/Prunes. 546 The value of JP_HOLDTIME is 215 seconds. This value is based on 547 section 4.11 of [RFC4601] which says that J/P_HoldTime should be 3.5 548 * t_periodic where the default for t_periodic is 60 seconds. 550 4.4. Moving from PORT to Datagram Mode 552 There may be situations where an administrator decides to stop using 553 PORT. If PORT is disabled on a router interface, or a previously 554 PORT enabled neighbor no longer announces any of the PORT Hello 555 options, one follows the rules in Section 4.3 for taking down 556 connections and starting timers. Next, one should trigger a full 557 state update similar to what would be done if the GenID changed in 558 Datagram Mode. This means sending joins for any state where we 559 switched from PORT to Datagram Mode for the upstream neighbor. 561 4.5. On-demand versus Pre-configured Connections 563 Transport connections could be established when they are needed or 564 when a router interface to other PIM neighbors has come up. The 565 advantage of on-demand Transport connection establishment is the 566 reduction of router resources. Especially in the case where there is 567 no need for a full mesh of connections on a network interface. The 568 disadvantage is additional delay and queueing when a Join/Prune 569 message needs to be sent and a Transport connection is not 570 established yet. 572 If a router interface has become operational and PIM neighbors are 573 learned from Hello messages, at that time, Transport connections may 574 be established. The advantage is that a connection is ready to 575 transport data by the time a Join/Prune message needs to be sent. 576 The disadvantage is there can be more connections established than 577 needed. This can occur when there is a small set of RPF neighbors 578 for the active distribution trees compared to the total number of 579 neighbors. Even when Transport connections are pre-established 580 before they are needed, a connection can go down and an 581 implementation will have to deal with an on-demand situation. 583 Note that for TCP, it is the router with the lower Connection ID that 584 decides whether to open a connection immediately, or on-demand. The 585 router with the higher Connection ID should only initiate a 586 connection on-demand. That is, if it needs to send a Join/Prune 587 message and there is no currently established connection. 589 Therefore, this specification recommends but does not mandate the use 590 of on-demand Transport connection establishment. 592 4.6. Possible Hello Suppression Considerations 594 This specification indicates that a Transport connection cannot be 595 established until a Hello message is received. One reason for this 596 is to determine if the PIM neighbor supports this specification and 597 the other is to determine the remote address to use to establish the 598 Transport connection. 600 There are cases where it is desirable to suppress entirely the 601 transmission of Hello messages. In this case, it is outside the 602 scope of this document on how to determine if the PIM neighbor 603 supports this specification as well as an out-of-band (outside of the 604 PIM protocol) method to determine the remote address to establish the 605 Transport connection. 607 4.7. Avoiding a Pair of TCP Connections between Neighbors 609 To ensure that there is only one TCP connection between a pair of PIM 610 neighbors, the following set of rules must be followed. Note that 611 this section applies only to TCP, for SCTP this is not an issue. Let 612 A and B be two PIM neighbors where A's Connection ID is numerically 613 smaller than B's Connection ID, and each is known to the other as 614 having a potential PIM adjacency relationship. 616 At node A: 618 o If there is already an established TCP connection to B, on the 619 PIM-over-TCP port, then A MUST NOT attempt to establish a new 620 connection to B. Rather it uses the established connection to send 621 Join/Prune messages to B. (This is independent of which node 622 initiated the connection.) 624 o If A has initiated a connection to B, but the connection is still 625 in the process of being established, then A MUST refuse any 626 connection on the PIM-over-TCP port from B. 628 o At any time when A does not have a connection to B which is either 629 established or in the process of being established, A MUST accept 630 connections from B. 632 At node B: 634 o If there is already an established TCP connection to A, on the 635 PIM-over-TCP port, then B MUST NOT attempt to establish a new 636 connection to A. Rather it uses the established connection to send 637 Join/Prune messages to A. (This is independent of which node 638 initiated the connection.) 640 o If B has initiated a connection to A, but the connection is still 641 in the process of being established, then if A initiates a 642 connection too, B MUST accept the connection initiated by A and 643 must release the connection which it (B) initiated. 645 5. PORT Message Definition 647 It may be desirable for scaling purposes to allow Join/Prune messages 648 from different PIM protocol families to be sent over the same 649 Transport connection. Also, it may be desirable to have a set of 650 Join/Prune messages for one address-family sent over a Transport 651 connection that is established over a different address-family 652 network layer. 654 To be able to do this we need a common PORT message message format. 655 This will provide both record boundary and demux points when sending 656 over a stream protocol like TCP/SCTP. 658 A PORT message may contain PORT options, see Section 5.3. We will 659 define two PORT options for carrying PIM Join/Prune messages. One 660 for IPv4 and one for IPv6. For each PIM Join/Prune message to be 661 sent over the Transport connection, we send a PORT Join/Prune message 662 containing exactly one such option. 664 Each PORT message will have the below Type/Length/Value format. 665 Multiple different TLV types can be sent over the same Transport 666 connection. 668 To make sure PIM Join/Prune messages are delivered as soon as the TCP 669 transport layer receives the Join/Prune buffer, the TCP Push flag 670 will be set in all outgoing Join/Prune messages sent over a TCP 671 transport connection. 673 PORT messages will be sent using destination TCP port number 8471. 674 When using SCTP as the reliable transport, destination port number 675 8471 will be used. See Section 10 for IANA considerations. 677 PORT messages are error checked. This includes a bad PIM checksum, 678 illegal type fields, illegal addresses or a truncated message. If 679 any parsing errors occur in a Join/Prune message, it is skipped, and 680 we proceed processing any following PORT messages. 682 The TLV type field is 16 bits. The range 61440 - 65535 is for 683 experimental use [RFC3692]. 685 This document defines two message types. 687 5.1. PORT Join/Prune Message 689 PORT Join/Prune Message 691 0 1 2 3 692 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 693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 | Type = 1 | Message Length | 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Reserved | Exp | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Interface | 699 | ID | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | PORT Option Type | Option Value Length | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Value | 704 | . | 705 | . | 706 | . | 707 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 708 \ . \ 709 / . / 710 \ . \ 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | PORT Option Type | Option Value Length | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Value | 715 | . | 716 | . | 717 | . | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 The PORT Join/Prune Message is used for sending a PIM Join/Prune. 722 Message Length: Length in bytes for the value part of the Type/ 723 Length/Value encoding. If no PORT Options were included, the 724 length would be 12. If n PORT Options with Option Value lengths 725 L1, L2, ..., Ln are included, the message length will be 12 + 4*n 726 + L1 + L2 + ... + Ln. 728 Reserved: Set to zero on transmission and ignored on receipt. 730 Exp: For experimental use [RFC3692]. 732 Interface ID: This is the Interface ID of the Interface ID Hello 733 option contained in the PIM Hello messages the PIM router is 734 sending to the PIM neighbor. It indicates to the PIM neighbor 735 what interface to associate the Join/Prune with. 737 PORT Options: The message MUST contain exactly one PIM Join/Prune 738 Port Option, either one PIM IPv4 Join/Prune or one PIM IPv6 Join/ 739 Prune. It MUST NOT contain both. It MAY contain additional 740 options not defined in this document. A router receiving a PORT 741 Join/Prune message containing unknown options MUST ignore the 742 entire PORT message. See Section 5.3 for option definitions. 744 As can be seen from the packet format diagram, multiple Join/Prune 745 messages can go into one TCP/SCTP stream from the same or different 746 Interface IDs. 748 5.2. PORT Keep-alive Message 750 PORT Keep-alive Message 752 0 1 2 3 753 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 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Type = 2 | Message Length | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Reserved | Exp | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | Holdtime | PORT Option Type | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | Option Value Length | Value | 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . + 763 | . | 764 | . | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 \ . \ 767 / . / 768 \ . \ 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | PORT Option Type | Option Value Length | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Value | 773 | . | 774 | . | 775 | . | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 The PORT Keep-alive Message is used to regularly send PORT messages 779 to verify that a connection is alive. They are used when other PORT 780 messages are not sent of the desired frequency. 782 Message Length: Length in bytes for the value part of the Type/ 783 Length/Value encoding. If no PORT Options were included, the 784 length would be 6. If n PORT Options with Option Value lengths 785 L1, L2, ..., Ln are included, the message length will be 6 + 4*n + 786 L1 + L2 + ... + Ln. 788 Reserved: Set to zero on transmission and ignored on receipt. 790 Exp: For experimental use [RFC3692]. 792 Holdtime: This specifies a holdtime in seconds for the connection. 793 A non-zero value means that the connection SHOULD be gracefully 794 shut down if no further PORT messages are received within the 795 specified time. This is measured on the receiving side by 796 measuring the time from one PORT message has been processed until 797 the next has been processed. Note that this is done for any PORT 798 message, not just keep-alive messages. A hold time of 0 disables 799 the keep-alive mechanism. 801 PORT Options: A keep-alive message MUST NOT contain any of the 802 options defined in this document. It MAY contain other options 803 not defined in this document. See Section 5.3 for option 804 definitions. 806 5.3. PORT Options 808 Each PORT Option is a TLV. The type is 16 bits. PORT Option types 809 are assigned by IANA, except the range 61440 - 65535 which is for 810 experimental use [RFC3692]. The length specifies the length of the 811 value in bytes. Below are the two options defined in this document. 813 PIM IPv4 Join/Prune Option 814 PIM IPv4 Join/Prune Option Format 816 0 1 2 3 817 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 818 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 819 | PORT Option Type = 1 | Option Value Length | 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | PIMv2 Join/Prune Message | 822 | . | 823 | . | 824 | . | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 The IPv4 Join/Prune Option is used to carry a PIMv2 Join/Prune 828 message that has all IPv4 encoded addresses in the PIM payload. 830 Option Value Length: The number of bytes that make up the PIMv2 831 Join/Prune message. 833 PIMv2 Join/Prune Message: PIMv2 Join/Prune message and payload with 834 no IP header in front of it. 836 PIM IPv6 Join/Prune Option 838 PIM IPv6 Join/Prune Option Format 840 0 1 2 3 841 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 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | PORT Option Type = 2 | Option Value Length | 844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 845 | PIMv2 Join/Prune Message | 846 | . | 847 | . | 848 | . | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 The IPv6 Join/Prune Option is used to carry a PIMv2 Join/Prune 852 message that has all IPv6 encoded addresses in the PIM payload. 854 Option Value Length: The number of bytes that make up the PIMv2 855 Join/Prune message. 857 PIMv2 Join/Prune Message: PIMv2 Join/Prune message and payload with 858 no IP header in front of it. 860 6. Explicit Tracking 862 When explicit tracking is used, a router keeps track of join state 863 for individual downstream neighbors on a given interface. This is 864 done for all PORT joins and prunes. It may also be done for native 865 join/prune messages, if all neighbors on the LAN have set the T bit 866 of the LAN Prune Delay option. In the discussion below we will talk 867 about ET (explicit tracking) neighbors, and non-ET neighbors. The 868 set of ET neighbors always includes the PORT neighbors. The set of 869 non-ET neighbors consists of all the non-PORT neighbors unless all 870 neighbors have set the LAN Prune Delay T bit. Then the ET neighbors 871 set contains all neighbors. 873 For some link-types, e.g. point-to-point, tracking neighbors is no 874 different than tracking interfaces. It may also be possible for an 875 implementation to treat different downstream neighbors as being on 876 different logical interfaces, even if they are on the same physical 877 link. Exactly how this is implemented and for which link types, is 878 left to the implementer. 880 For (*,G) and (S,G) state, the router starts forwarding traffic on an 881 interface when a Join is received from a neighbor on such an 882 interface. When a non-ET neighbor sends a Prune, as specified 883 [RFC4601], if no Join is sent to override this Prune before the 884 expiration of the Override Timer, the upstream router concludes that 885 no non-ET neighbor is interested. If no ET neighbors are interested, 886 the interface can be removed from the oif-list. When an ET neighbor 887 sends a Prune, one removes the join state for that neighbor. If no 888 other ET or non-ET neighbors are interested, the interface can be 889 removed from the oif-list. When a PORT neighbor sends a prune, there 890 can be no Prune Override, since the Prune is not visible to other 891 neighbors. 893 For (S,G,rpt) state, the router needs to track Prune state on the 894 shared tree. It needs to know which ET neighbors have sent prunes, 895 and whether any non-ET neighbors have sent prunes. Normally one 896 would forward a packet from a source S to a group G out on an 897 interface if a (*,G)-join is received, but no (S,G,rpt)-prune. With 898 ET one needs to do this check per ET neighbor. That is, the packet 899 should be forwarded unless all ET neighbors that have sent 900 (*,G)-joins have also sent (S,G,rpt)-prunes, and if a non-ET neighbor 901 has sent a (*,G)-join, whether there also is non-ET (S,G,rpt)-prune 902 state. 904 7. Multiple Address-Family Support 906 To allow for efficient use of router resources, one can mux Join/ 907 Prune messages of different address families on the same Transport 908 connections. There are two ways this can be accomplished, one using 909 a common message format over a TCP connection and the other using 910 multiple streams over a single SCTP connection. 912 Using the common message format described previously in this 913 specification, using different PORT options, both IPv4 and IPv6 based 914 Join/Prune messages can be encoded within the same Transport 915 connection. 917 When using SCTP multi-streaming, the common message format is still 918 used to convey address family information but an SCTP association is 919 used, on a per-family basis, to send data concurrently for multiple 920 families. When data is sent concurrently, head of line blocking, 921 which can occur when using TCP, is avoided. 923 8. Miscellany 925 No changes expected in processing of other PIM messages like PIM 926 Asserts, Grafts, Graft-Acks, Registers, and Register-Stops. This 927 goes for BSR and Auto-RP type messages as well. 929 This extension is applicable only to PIM-SM, PIM-SSM and Bidir-PIM. 930 It does not take requirements for PIM-DM into consideration. 932 9. Security Considerations 934 TCP connections can be authenticated using TCP-AO [RFC5925]. When 935 using SCTP, [RFC4895] can be used for authentication on a per SCTP 936 association basis. Also GTSM [RFC5082] can be used to help prevent 937 spoofing. 939 10. IANA Considerations 941 This specification makes use of a TCP port number and a SCTP port 942 number for the use of PIM-Over-Reliable-Transport that has been 943 allocated by IANA. It also makes use of IANA PIM Hello Options 944 allocations that should be made permanent. 946 10.1. PORT Message Type Registry 948 A registry for PORT message types is requested. The message type is 949 a 16-bit integer, with values from 0 to 65535. An RFC is required 950 for assignments in the range 0 - 61439. This document defines one 951 PORT message type. Type 1, PORT Join/Prune Message. The type range 952 61440 - 65535 is for experimental use [RFC3692]. 954 The initial content of the registry should be as follows: 956 Type Name Reference 957 ------------- ------------------------------- --------------- 958 0 Reserved this document 959 1 Join/Prune this document 960 2 Keep-alive Message this document 961 3-61439 Unassigned 962 61440-65535 Experimental this document 964 10.2. PORT Option Type Registry 966 A registry for PORT option types is requested. The option type is a 967 16-bit integer, with values from 0 to 65535. An RFC is required for 968 assignments in the range 0 - 61439. This document defines two PORT 969 option types. Type 1, PIM IPv4 Join/Prune Message; and Type 2, PIM 970 IPv6 Join/Prune Message. The type range 61440 - 65535 is for 971 experimental use [RFC3692]. 973 The initial content of the registry should be as follows: 975 Type Name Reference 976 ------------- ------------------------------- --------------- 977 0 Reserved this document 978 1 PIM IPv4 Join/Prune Message this document 979 2 PIM IPv6 Join/Prune Message this document 980 3-61439 Unassigned 981 61440-65535 Experimental this document 983 11. Contributors 985 In addition to the persons listed as authors, significant 986 contributions were provided by Apoorva Karan and Arjen Boers. 988 12. Acknowledgments 990 The authors would like to give a special thank you and appreciation 991 to Nidhi Bhaskar for her initial design and early prototype of this 992 idea. 994 Appreciation goes to Randall Stewart for his authoritative review and 995 recommendation for using SCTP. 997 Thanks also goes to the following for their ideas and commentary 998 review of this specification, Mike McBride, Toerless Eckert, Yiqun 999 Cai, Albert Tian, Suresh Boddapati, Nataraj Batchu, Daniel Voce, John 1000 Zwiebel, Yakov Rekhter, Lenny Giuliano, Gorry Fairhurst, Sameer 1001 Gulrajani, Thomas Morin, Dimitri Papadimitriou, Bharat Joshi, Rishabh 1002 Parekh, Manav Bhatia and Pekka Savola. 1004 A special thank you goes to Eric Rosen for his very detailed review 1005 and commentary. Many of his comments are reflected as text in this 1006 specification. 1008 13. References 1010 13.1. Normative References 1012 [I-D.gulrajani-pim-hello-intid] 1013 Gulrajani, S. and S. Venaas, "An Interface ID Hello Option 1014 for PIM", draft-gulrajani-pim-hello-intid-00 (work in 1015 progress), February 2011. 1017 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1018 RFC 793, September 1981. 1020 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1021 Requirement Levels", BCP 14, RFC 2119, March 1997. 1023 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1024 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1025 Protocol Specification (Revised)", RFC 4601, August 2006. 1027 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1028 "Authenticated Chunks for the Stream Control Transmission 1029 Protocol (SCTP)", RFC 4895, August 2007. 1031 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1032 RFC 4960, September 2007. 1034 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1035 "Bidirectional Protocol Independent Multicast (BIDIR- 1036 PIM)", RFC 5015, October 2007. 1038 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 1039 Pignataro, "The Generalized TTL Security Mechanism 1040 (GTSM)", RFC 5082, October 2007. 1042 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1043 Authentication Option", RFC 5925, June 2010. 1045 13.2. Informative References 1047 [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY 1048 NUMBERS http://www.iana.org/numbers.html, February 2007. 1050 [HELLO-OPT] 1051 IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per 1052 RFC4601 http://www.iana.org/assignments/pim-hello-options, 1053 March 2007. 1055 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1056 Considered Useful", BCP 82, RFC 3692, January 2004. 1058 Authors' Addresses 1060 Dino Farinacci 1061 cisco Systems 1062 Tasman Drive 1063 San Jose, CA 95134 1064 USA 1066 Email: dino@cisco.com 1068 IJsbrand Wijnands 1069 cisco Systems 1070 Tasman Drive 1071 San Jose, CA 95134 1072 USA 1074 Email: ice@cisco.com 1076 Stig Venaas 1077 cisco Systems 1078 Tasman Drive 1079 San Jose, CA 95134 1080 USA 1082 Email: stig@cisco.com 1084 Maria Napierala 1085 AT&T Labs 1086 200 Laurel Drive 1087 Middletown, New Jersey 07748> 1088 USA 1090 Email: mnapierala@att.com