idnits 2.17.1 draft-ietf-pim-port-06.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 == Line 968 has weird spacing: '...Capable thi...' -- 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 (March 4, 2011) is 4774 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 (~~), 3 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: September 5, 2011 cisco Systems 6 M. Napierala 7 AT&T Labs 8 March 4, 2011 10 A Reliable Transport Mechanism for PIM 11 draft-ietf-pim-port-06.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 September 5, 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 . . . . . . . . . . . . . . . . . . . 13 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 Hello Options . . . . . . . . . . . . . . . . . . . . 27 81 10.2. PORT Message Type Registry . . . . . . . . . . . . . . . . 27 82 10.3. PORT Option Type Registry . . . . . . . . . . . . . . . . 27 83 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 29 84 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 85 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 86 13.1. Normative References . . . . . . . . . . . . . . . . . . . 31 87 13.2. Informative References . . . . . . . . . . . . . . . . . . 31 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 90 1. Introduction 92 The goals of this specification are: 94 o To create a simple incremental mechanism to provide reliable PIM 95 message delivery in PIM version 2 for use with PIM Sparse-Mode 96 [RFC4601] (including Source-Specific Multicast) and Bidirectional 97 PIM [RFC5015]. 99 o The reliable transport mechanism will be used for Join-Prune 100 message transmission only. 102 o When a router supports this specification, it need not use the 103 reliable transport mechanism with every neighbor. That is, 104 negotiation on a per neighbor basis will occur. 106 The explicit non-goals of this specification are: 108 o Changes to the PIM message formats as defined in [RFC4601]. 110 o Provide support for automatic switching between the reliable 111 transport mechanism and the regular PIM mechanism defined in 112 [RFC4601]. Two routers that are PIM neighbors on a link will 113 always use the reliable transport mechanism if and only if both 114 have enabled support for the reliable transport mechanism. 116 This document will specify how periodic Join/Prune message 117 transmission can be eliminated by using TCP [RFC0793] or SCTP 118 [RFC4960] as the reliable transport mechanism for Join/Prune 119 messages. 121 This specification enables greater scalability in terms of control 122 traffic overhead. However, for routers connected to multi-access 123 links that comes at the price of increased control plane state 124 overhead and the control plane overhead required to maintain this 125 state. 127 In many existing and emerging networks, particularly wireless and 128 mobile satellite systems, link degradation due to weather, 129 interference, and other impairments can result in temporary spikes in 130 the packet loss. In these environments, periodic PIM joining can 131 cause join latency when messages are lost causing a retransmission 132 only 60 seconds later. By applying a reliable transport, a lost join 133 is retransmitted rapidly. Furthermore, when the last user leaves a 134 multicast group, any lost prune is similarly repaired and the 135 multicast stream is quickly removed from the wireless/satellite link. 136 Without a reliable transport, the multicast transmission could 137 otherwise continue until it timed out, roughly 3 minutes later. As 138 network resources are at a premium in many of these environments, 139 rapid termination of the multicast stream is critical for maintaining 140 efficient use of bandwidth. 142 1.1. Requirements Notation 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 1.2. Definitions 150 PORT: Stands for PIM Over Reliable Transport. Which is the short 151 form for describing the mechanism in this specification where PIM 152 can use the TCP or SCTP transport protocol. 154 Periodic Join/Prune message: A Join/Prune message sent periodically 155 to refresh state. 157 Incremental Join/Prune message: A Join/Prune message sent as a 158 result of state creation or deletion events. Also known as a 159 triggered message. 161 Native Join/Prune message: A Join/Prune message which is carried 162 with an IP protocol type of PIM. 164 PORT Join/Prune message: A Join/Prune message using TCP or SCTP for 165 transport. 167 Datagram Mode: The current procedures PIM uses by encapsulating 168 Join/Prune messages in IP packets sent either triggered or 169 periodically. 171 PORT Mode: Procedures used by PIM defined in this specification for 172 sending Join/Prune messages over the TCP or SCTP transport layer. 174 2. Protocol Overview 176 PIM Over Reliable Transport (PORT) is a simple extension to PIMv2 for 177 refresh reduction of PIM Join/Prune messages. It involves sending 178 incremental rather than periodic Join/Prune messages over a TCP/SCTP 179 connection between PIM neighbors. 181 PORT only applies to PIM Sparse-Mode [RFC4601] and Bidirectional PIM 182 [RFC5015] Join/Prune messages. 184 This document does not restrict PORT to any specific link types. 185 However, the use of PORT on e.g. multi-access LANs with many PIM 186 neighbors should be carefully evaluated. This due to the fact that 187 there may be a full mesh of PORT connections, and that explicit 188 tracking of all PIM PORT routers is required. 190 PORT can be incrementally used on a link between PORT capable 191 neighbors. Routers which are not PORT capable can continue to use 192 PIM in Datagram Mode. PORT capability is detected using new PORT 193 Capable PIM Hello Options. 195 Once PORT is enabled on an interface and a PIM neighbor also 196 announces that it is PORT enabled, only PORT Join/Prune messages will 197 be used. That is, only PORT Join/Prune messages are accepted from, 198 and sent to, that particular neighbor. Native Join/Prune messages 199 are still used for PIM neighbors that are not PORT enabled. 201 PORT Join/Prune messages are sent using a TCP/SCTP connection. When 202 two PIM neighbors are PORT enabled, both for TCP or both for SCTP, 203 they will immediately, or on-demand, establish a connection. If the 204 connection goes down, they will again immediately, or on-demand, try 205 to reestablish the connection. No Join/Prune messages (neither 206 Native nor PORT) are sent while there is no connection. Also, any 207 received native Join/Prune messages from that neighbor are discarded, 208 even when the connection is down. 210 When PORT is used, only incremental Join/Prune messages are sent from 211 downstream routers to upstream routers. As such, downstream routers 212 do not generate periodic Join/Prune messages for state for which the 213 RPF neighbor is PORT-capable. 215 For Joins and Prunes, which are received over a TCP/SCTP connection, 216 the upstream router does not start or maintain timers on the outgoing 217 interface entry. Instead, it keeps track of which downstream routers 218 have expressed interest. An interface is deleted from the outgoing 219 interface list only when all downstream routers on the interface, no 220 longer wish to receive traffic. If there also are native joins/ 221 prunes from non-PORT neighbor, then one can maintain timers on the 222 outgoing interface entry as usual, while at the same time keep track 223 of each of the downstream PORT joins/prunes. 225 There is no change proposed for the PIM Join/Prune packet format. 226 However, for Join/Prune messages sent over TCP/SCTP connections, no 227 IP Header is included. Each message is contained in a PORT message. 228 See section Section 5 for details on the PORT message. 230 3. PIM Hello Options 232 3.1. PIM over the TCP Transport Protocol 234 Option Type: PIM-over-TCP Capable 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Type = 27 | Length = 4 + X | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | TCP Connection ID AFI | Reserved | Exp | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | TCP Connection ID | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 Allocated Hello Type values can be found in [HELLO-OPT]. 248 When a router is configured to use PIM over TCP on a given interface, 249 it MUST include the PIM-over-TCP Capable hello option in its Hello 250 messages for that interface. If a router is explicitly disabled from 251 using PIM over TCP, it MUST NOT include the PIM-over-TCP Capable 252 hello option in its Hello messages. 254 All Hello messages containing the PIM-over-TCP Capable hello option, 255 MUST also contain the Interface ID hello option, see section 256 Section 3.3. 258 Implementations MAY provide a configuration option to enable or 259 disable PORT functionality. It is RECOMMENDED that this capability 260 be disabled by default. 262 Length: Length in bytes for the value part of the Type/Length/Value 263 encoding; where X is the number of bytes that make up the 264 Connection ID field. X is 4 when AFI of value 1 (IPv4) is used, 265 16 when AFI of value 2 (IPv6) is used, and 0 if AFI of value 0 is 266 used [AFI]. 268 TCP Connection ID AFI: The AFI value to describe the address-family 269 of the address of the TCP Connection ID field. When this field is 270 0, a mechanism outside the scope of this document is used to 271 obtain the addresses used to establish the TCP connection. 273 Reserved: Set to zero on transmission and ignored on receipt. 275 Exp: For experimental use [RFC3692]. 277 TCP Connection ID: An IPv4 or IPv6 address used to establish the 278 TCP connection. This field is omitted (length 0) for the 279 Connection ID AFI 0. 281 3.2. PIM over the SCTP Transport Protocol 283 Option Type: PIM-over-SCTP Capable 285 0 1 2 3 286 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 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Type = 28 | Length = 4 + X | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | SCTP Connection ID AFI | Reserved | Exp | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | SCTP Connection ID | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Allocated Hello Type values can be found in [HELLO-OPT]. 297 When a router is configured to use PIM over SCTP on a given 298 interface, it MUST include the PIM-over-SCTP Capable hello option in 299 its Hello messages for that interface. If a router is explicitly 300 disabled from using PIM over SCTP, it MUST NOT include the PIM-over- 301 SCTP Capable hello option in its Hello messages. 303 All Hello messages containing the PIM-over-SCTP Capable hello option, 304 MUST also contain the Interface ID hello option, see section 305 Section 3.3. 307 Implementations MAY provide a configuration option to enable or 308 disable PORT functionality. It is RECOMMENDED that this capability 309 be disabled by default. 311 Length: Length in bytes for the value part of the Type/Length/Value 312 encoding; where X is the number of bytes that make up the 313 Connection ID field. X is 4 when AFI of value 1 (IPv4) is used, 314 16 when AFI of value 2 (IPv6) is used, and 0 if AFI of value 0 is 315 used [AFI]. 317 SCTP Connection ID AFI: The AFI value to describe the address- 318 family of the address of the SCTP Connection ID field. When this 319 field is 0, a mechanism outside the scope of this document is used 320 to obtain the addresses used to establish the SCTP connection. 322 Reserved: Set to zero on transmission and ignored on receipt. 324 Exp: For experimental use [RFC3692]. 326 SCTP Connection ID: An IPv4 or IPv6 address used to establish the 327 SCTP connection. This field is omitted (length 0) for the 328 Connection ID AFI 0. 330 3.3. Interface ID 332 All Hello messages containing PIM-over-TCP Capable or PIM-over-SCTP 333 Capable hello options, MUST also contain the Interface ID hello 334 option [I-D.gulrajani-pim-hello-intid]. 336 The Interface ID is used to associate the connection a Join/Prune 337 message is received over, with an interface which is added or removed 338 from an oif-list. When unnumbered interfaces are used or when a 339 single Transport connection is used for sending and receiving Join/ 340 Prune messages over multiple interfaces, the Interface ID is used to 341 convey the interface from Join/Prune message sender to Join/Prune 342 message receiver. The value of the Interface ID hello option in 343 Hellos sent on an interface, must be the same as the Interface ID 344 value in all PORT Join/Prune messages sent to a PIM neighbor on that 345 interface. 347 The Interface ID need only uniquely identify an interface of a 348 router, it does not need to identify which router the interface 349 belongs to. This means that the Router ID part of the Interface ID 350 MAY be 0. For details on the Router ID and the value 0, see 351 [I-D.gulrajani-pim-hello-intid]. 353 4. Establishing Transport Connections 355 While a router interface is PORT enabled, a PIM-over-TCP or a PIM- 356 over-SCTP option is included in the PIM Hello messages sent on that 357 interface. When a router on a PORT-enabled interface receives a 358 Hello message containing a PIM-over-TCP/PIM-over-SCTP Option from a 359 new neighbor, or an existing neighbor that did not previously include 360 the option, it switches to PORT mode for that particular neighbor. 362 When a router switches to PORT mode for a neighbor, it stops sending 363 and accepting Native Join/Prune messages for that neighbor. Any 364 state from previous Native Join/Prune messages is left to expire as 365 normal. It will also attempt to establish a Transport connection 366 (TCP or SCTP) with the neighbor. If both the router and its neighbor 367 have announced both PIM-over-TCP and PIM-over-SCTP options, SCTP MUST 368 be used. 370 When the router is using TCP, it will compare the TCP Connection ID 371 it announced in the PIM-over-TCP Capable Option with the TCP 372 Connection ID in the Hello received from the neighbor. The router 373 with the lower Connection ID will do an active Transport open to the 374 neighbor Connection ID. The router with the higher Connection ID 375 will do a passive Transport open. An implementation may open 376 connections only on-demand, in that case it may be that the neighbor 377 with the higher Connection ID does the active open, see Section 4.5. 378 Note that the source address of the active open must be the announced 379 Connection ID. 381 When the router is using SCTP, the IP address comparison need not be 382 done since the SCTP protocol can handle call collision. 384 If PORT is used both for IPv4 and IPv6, both IPv4 and IPv6 PIM Hello 385 messages are sent, both containing PORT Hello options. If two 386 neighbors announce the same transport (TCP or SCTP) and the same 387 Connection ID in the IPv4 and IPv6 Hello messages, then only one 388 connection is established and is shared. Otherwise, two connections 389 are established and are used separately. 391 The PIM router that performs the active open initiates the connection 392 with a locally generated source transport port number and a well- 393 known destination transport port number. The PIM router that 394 performs the passive open listens on the well-known local transport 395 port number and does not qualify the remote transport port number. 396 See Section 5 for well-known port number assignment for PORT. 398 When a Transport connection is established (or reestablished), the 399 two routers MUST both send a full set of Join/Prune messages for 400 state for which the other router is the upstream neighbor. This is 401 needed to ensure that the upstream neighbor has the correct state. 402 When moving from Datagram mode, or when the connection has gone down, 403 the router cannot be sure that all the previous Join/Prune state was 404 received by the neighbor. Any state created before the connection 405 was established (or reestablished) that is not refreshed, MUST be 406 left to expire and be deleted. When the non-refreshed state has 407 expired and been deleted, the two neighbors will be in sync. 409 It is possible that a router starts sending Hello messages with a new 410 Connection ID, e.g. due to configuration changes. One MUST always 411 use the last announced and last seen Connection IDs. A connection is 412 identified by the local Connection ID (the one we are announcing on a 413 particular interface), and the remote Connection ID (the one we are 414 receiving from a neighbor on the same interface). When either the 415 local or remote ID changes, the Connection ID pair we need a 416 connection for changes. There may be an existing connection with the 417 same pair, in which case we will share that connection. Or a new 418 connection may need to be established. Note that for link-local 419 addresses, the interface should be regarded as part of the ID, so 420 that connection sharing is not attempted when the same link-local 421 addresses are seen on different interfaces. 423 When a Connection ID changes, if the previously used connection is 424 not needed (there are no other PIM neighborships using the same 425 Connection ID pair), both peers MUST attempt a graceful shutdown of 426 the connection. Next (even if the old connection is still needed), 427 they MUST, unless a connection already exists with the new Connection 428 ID pair, immediately or on-demand attempt to establish a new 429 connection with the new Connection ID pair. 431 Normally the Interface ID would not change while a connection is up. 432 However, if it does, it should not affect the connection. It just 433 means that when subsequent PORT join/prune messages are received, 434 they should be matched against the last seen Interface ID. 436 Note that, a Join sent over a Transport connection will only be seen 437 by the upstream router, and thus will not cause routers on the link 438 that do not use PIM PORT with the upstream router to possibly delay 439 the refresh of Join state for the same state. Similarly, a Prune 440 sent over a Transport connection will only be seen by the upstream 441 router, and will thus never cause routers on the link that do not use 442 PIM PORT with the upstream router, to send a Join to override this 443 Prune. 445 Note also, that a datagram PIM Join/Prune message for a said (S,G) or 446 (*,G) sent by some router on a link will not cause routers on the 447 same link that use a Transport connection with the upstream router 448 for that state, to suppress the refresh of that state to the upstream 449 router (because they don't need to periodically refresh this state) 450 or to send a Join to override a Prune (as the upstream router will 451 only stop forwarding the traffic when all joined routers that use a 452 Transport connection have explicitly sent a Prune for this state, as 453 explained in Section 6). 455 4.1. Connection Security 457 TCP/SCTP packets MUST be sent with a TTL/Hop Limit of 255 to 458 facilitate enabling of the Generalized TTL Security Mechanism (GTSM) 459 [RFC5082]. Implementations SHOULD provide a configuration option to 460 enable the GTSM check. This means checking that inbound packets from 461 directly connected neighbors have a TTL/Hop Limit of 255, but MAY 462 also allow for a different TTL/Hop Limit threshold to check that the 463 sender is within a certain number of router hops. The GTSM check 464 SHOULD be disabled by default. 466 Implementations SHOULD support the TCP Authentication Option (TCP-AO) 467 [RFC5925]. 469 4.2. Connection Maintenance 471 TCP is designed to keep connections up indefinitely during a period 472 of network disconnection. If a PIM-over-TCP router fails, the TCP 473 connection may stay up until the neighbor actually reboots, and even 474 then it may continue to stay up until you actually try to send the 475 neighbor some information. This is particularly relevant to PIM, 476 since the flow of Join/Prune messages might be in only one direction, 477 and the downstream neighbor might never get any indication via TCP 478 that the other end of the connection is not really there. 480 One can detect that a PORT connection is not working by regularly 481 sending PORT messages. E.g., for TCP the connection will be reset if 482 no TCP ACKs are received after a few retries. PORT in itself does 483 not require any periodic signaling. PORT Join/Prune messages are 484 only sent when there is a state change. If the state changes are not 485 frequent enough, a PORT Keep-Alive message can be sent instead. E.g. 486 if an implementation wants to send a PORT message, to check that the 487 connection is working, at least every 60 seconds, then whenever there 488 is 60 seconds since the previous message, a Keep-Alive message could 489 be sent. If there were less than 60 seconds between each Join/Prune, 490 no Keep-Alive messages would be needed. Implementations SHOULD 491 support the use of PORT Keep-Alive messages. It is RECOMMENDED that 492 a configuration option is available to network administrators to 493 enable it when needed. Note that Keep-Alives can be used by a peer, 494 independently of whether the other peer supports it. 496 The mechanism above relies on the connection eventually going down 497 when we don't get any ACKs for the data we send. A quicker and more 498 reliable way of detecting that a connection is not working, is to 499 send regular PORT messages, and have our peer take down the 500 connection if it doesn't receive them. This can be done by sending 501 Keep-alive messages with a non-zero holdtime value. If the last 502 received Keep-alive message had a non-zero holdtime, one tears down 503 the connection if the time measured in seconds since the last 504 processed PORT message exceeds the specified holdtime. 506 Implementations SHOULD support Keep-Alive messages. An 507 implementation that supports Keep-Alive messages acts as follows when 508 processing a received PORT message. When processing a Keep-Alive 509 message with a non-zero Holdtime value, it MUST set a timer to the 510 value. We call this timer Connection Expiry Timer (CET). If the CET 511 is already running, it MUST be reset to the new value. When 512 processing a Keep-Alive message with a zero Holdtime value, the CET 513 MUST be stopped if running. When processing a PORT message other 514 than Keep-Alive, the CET MUST be reset to the last received Holdtime 515 value if running. If the CET is not running, no action is taken. If 516 the CET expires, the connection SHOULD be shut down. 518 It is possible that a router receives Join/Prune messages for an 519 interface/link that is down. As long as the neighbor has not 520 expired, it is RECOMMENDED processing those messages as usual. If 521 they are ignored, then the router SHOULD ensure it gets a full update 522 for that interface when it comes back up. This can be done by 523 changing the GenID (Generation Identifier, see [RFC4601]), or by 524 terminating and reestablishing the connection. 526 If a PORT neighbor changes its GenID and a connection is established 527 or attempting to be established, the local side should generally tear 528 down the connection and do as described in Section 4.3. However, if 529 the connection is shared by multiple interfaces and the GenID changes 530 only for one of them, the local side SHOULD simply send a full 531 update, similar to other cases when a GenID changes for an upstream 532 neighbor. 534 4.3. Actions When a Connection Goes Down 536 A connection may go down for a variety of reasons. It may be due to 537 an error condition, or a configuration change. A connection SHOULD 538 be shut down as soon as there are no more PIM neighbors using it. 539 That is, for the connection we have associated local and remote 540 Connection IDs. When there is no PIM neighbor with that particular 541 remote connection ID on any interface where we announce the local 542 connection ID, the connection SHOULD be shut down. This may happen 543 when a new connection ID is configured, PORT is disabled, or a PIM 544 neighbor expires. 546 If a PIM neighbor expires, one should free connection state and 547 downstream oif-list state for the neighbor. A downstream router, 548 when an upstream neighboring router has expired, will simply update 549 the RPF neighbor for the corresponding state to a new neighbor where 550 it would trigger Join/Prune messages. This behavior is according to 551 [RFC4601] where also the term RPF neighbor is defined. It is 552 required of a PIM router to clear its neighbor table for a neighbor 553 who has timed out due to neighbor holdtime expiration. 555 When a connection is no longer available between two PORT enabled PIM 556 neighbors, they MUST immediately, or on-demand, try to reestablish 557 the connection following the normal rules for connection 558 establishment. The neighbors MUST also start expiry timers so that 559 all oif-list state for the neighbor using the connection, gets 560 expired after JP_HOLDTIME, unless it later gets refreshed by 561 receiving new Join/Prunes. 563 The value of JP_HOLDTIME is 215 seconds. This value is based on 564 section 4.11 of [RFC4601] which says that JP_HoldTime should be 3.5 * 565 t_periodic where the default for t_periodic is 60 seconds. 567 4.4. Moving from PORT to Datagram Mode 569 There may be situations where an administrator decides to stop using 570 PORT. If PORT is disabled on a router interface, or a previously 571 PORT enabled neighbor no longer announces any of the PORT Hello 572 options, one follows the rules in Section 4.3 for taking down 573 connections and starting timers. Next, one should trigger a full 574 state update similar to what would be done if the GenID changed in 575 Datagram Mode. This means sending joins for any state where we 576 switched from PORT to Datagram Mode for the upstream neighbor. 578 4.5. On-demand versus Pre-configured Connections 580 Transport connections could be established when they are needed or 581 when a router interface to other PIM neighbors has come up. The 582 advantage of on-demand Transport connection establishment is the 583 reduction of router resources. Especially in the case where there is 584 no need for a full mesh of connections on a network interface. The 585 disadvantage is additional delay and queueing when a Join/Prune 586 message needs to be sent and a Transport connection is not 587 established yet. 589 If a router interface has become operational and PIM neighbors are 590 learned from Hello messages, at that time, Transport connections may 591 be established. The advantage is that a connection is ready to 592 transport data by the time a Join/Prune message needs to be sent. 593 The disadvantage is there can be more connections established than 594 needed. This can occur when there is a small set of RPF neighbors 595 for the active distribution trees compared to the total number of 596 neighbors. Even when Transport connections are pre-established 597 before they are needed, a connection can go down and an 598 implementation will have to deal with an on-demand situation. 600 Note that for TCP, it is the router with the lower Connection ID that 601 decides whether to open a connection immediately, or on-demand. The 602 router with the higher Connection ID should only initiate a 603 connection on-demand. That is, if it needs to send a Join/Prune 604 message and there is no currently established connection. 606 Therefore, this specification recommends but does not mandate the use 607 of on-demand Transport connection establishment. 609 4.6. Possible Hello Suppression Considerations 611 This specification indicates that a Transport connection cannot be 612 established until a Hello message is received. One reason for this 613 is to determine if the PIM neighbor supports this specification and 614 the other is to determine the remote address to use to establish the 615 Transport connection. 617 There are cases where it is desirable to suppress entirely the 618 transmission of Hello messages. In this case, it is outside the 619 scope of this document on how to determine if the PIM neighbor 620 supports this specification as well as an out-of-band (outside of the 621 PIM protocol) method to determine the remote address to establish the 622 Transport connection. 624 4.7. Avoiding a Pair of TCP Connections between Neighbors 626 To ensure that there is only one TCP connection between a pair of PIM 627 neighbors, the following set of rules must be followed. Note that 628 this section applies only to TCP, for SCTP this is not an issue. Let 629 A and B be two PIM neighbors where A's Connection ID is numerically 630 smaller than B's Connection ID, and each is known to the other as 631 having a potential PIM adjacency relationship. 633 At node A: 635 o If there is already an established TCP connection to B, on the 636 PIM-over-TCP port, then A MUST NOT attempt to establish a new 637 connection to B. Rather it uses the established connection to send 638 Join/Prune messages to B. (This is independent of which node 639 initiated the connection.) 641 o If A has initiated a connection to B, but the connection is still 642 in the process of being established, then A MUST refuse any 643 connection on the PIM-over-TCP port from B. 645 o At any time when A does not have a connection to B which is either 646 established or in the process of being established, A MUST accept 647 connections from B. 649 At node B: 651 o If there is already an established TCP connection to A, on the 652 PIM-over-TCP port, then B MUST NOT attempt to establish a new 653 connection to A. Rather it uses the established connection to send 654 Join/Prune messages to A. (This is independent of which node 655 initiated the connection.) 657 o If B has initiated a connection to A, but the connection is still 658 in the process of being established, then if A initiates a 659 connection too, B MUST accept the connection initiated by A and 660 must release the connection which it (B) initiated. 662 5. PORT Message Definition 664 It may be desirable for scaling purposes to allow Join/Prune messages 665 from different PIM protocol families to be sent over the same 666 Transport connection. Also, it may be desirable to have a set of 667 Join/Prune messages for one address-family sent over a Transport 668 connection that is established over a different address-family 669 network layer. 671 To be able to do this we need a common PORT message format. This 672 will provide both record boundary and demux points when sending over 673 a stream protocol like TCP/SCTP. 675 A PORT message may contain PORT options, see Section 5.3. We will 676 define two PORT options for carrying PIM Join/Prune messages. One 677 for IPv4 and one for IPv6. For each PIM Join/Prune message to be 678 sent over the Transport connection, we send a PORT Join/Prune message 679 containing exactly one such option. 681 Each PORT message will have the Type/Length/Value format. Multiple 682 different TLV types can be sent over the same Transport connection. 684 To make sure PIM Join/Prune messages are delivered as soon as the TCP 685 transport layer receives the Join/Prune buffer, the TCP Push flag 686 will be set in all outgoing Join/Prune messages sent over a TCP 687 transport connection. 689 PORT messages will be sent using destination TCP port number 8471. 690 When using SCTP as the reliable transport, destination port number 691 8471 will be used. See Section 10 for IANA considerations. 693 PORT messages are error checked. This includes a bad PIM checksum, 694 illegal type fields, illegal addresses or a truncated message. If 695 any parsing errors occur in a PORT message, it is skipped, and we 696 proceed to any following PORT messages. 698 The TLV type field is 16 bits. The range 61440 - 65535 is for 699 experimental use [RFC3692]. 701 This document defines two message types. 703 5.1. PORT Join/Prune Message 705 PORT Join/Prune Message 707 0 1 2 3 708 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 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 | Type = 1 | Message Length | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | Reserved | Exp | 713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 714 | Interface | 715 | ID | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | PORT Option Type | Option Value Length | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Value | 720 | . | 721 | . | 722 | . | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 \ . \ 725 / . / 726 \ . \ 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | PORT Option Type | Option Value Length | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | Value | 731 | . | 732 | . | 733 | . | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 The PORT Join/Prune Message is used for sending a PIM Join/Prune. 738 Message Length: Length in bytes for the value part of the Type/ 739 Length/Value encoding. If no PORT Options were included, the 740 length would be 12. If n PORT Options with Option Value lengths 741 L1, L2, ..., Ln are included, the message length will be 12 + 4*n 742 + L1 + L2 + ... + Ln. 744 Reserved: Set to zero on transmission and ignored on receipt. 746 Exp: For experimental use [RFC3692]. 748 Interface ID: This is the Interface ID of the Interface ID Hello 749 option contained in the PIM Hello messages the PIM router is 750 sending to the PIM neighbor. It indicates to the PIM neighbor 751 what interface to associate the Join/Prune with. The Interface ID 752 allows us to do connection sharing. 754 PORT Options: The message MUST contain exactly one PIM Join/Prune 755 Port Option, either one PIM IPv4 Join/Prune or one PIM IPv6 Join/ 756 Prune. It MUST NOT contain both. It MAY contain additional 757 options not defined in this document. A router receiving a PORT 758 Join/Prune message containing unknown options MUST ignore the 759 entire PORT message. See Section 5.3 for option definitions. 761 5.2. PORT Keep-alive Message 763 PORT Keep-alive Message 765 0 1 2 3 766 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 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Type = 2 | Message Length | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | Reserved | Exp | 771 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 772 | Holdtime | PORT Option Type | 773 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 | Option Value Length | Value | 775 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . + 776 | . | 777 | . | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 \ . \ 780 / . / 781 \ . \ 782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 | PORT Option Type | Option Value Length | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 785 | Value | 786 | . | 787 | . | 788 | . | 789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 791 The PORT Keep-alive Message is used to regularly send PORT messages 792 to verify that a connection is alive. They are used when other PORT 793 messages are not sent at the desired frequency. 795 Message Length: Length in bytes for the value part of the Type/ 796 Length/Value encoding. If no PORT Options were included, the 797 length would be 6. If n PORT Options with Option Value lengths 798 L1, L2, ..., Ln are included, the message length will be 6 + 4*n + 799 L1 + L2 + ... + Ln. 801 Reserved: Set to zero on transmission and ignored on receipt. 803 Exp: For experimental use [RFC3692]. 805 Holdtime: This specifies a holdtime in seconds for the connection. 806 A non-zero value means that the connection SHOULD be gracefully 807 shut down if no further PORT messages are received within the 808 specified time. This is measured on the receiving side by 809 measuring the time from one PORT message has been processed until 810 the next has been processed. Note that this is done for any PORT 811 message, not just keep-alive messages. A hold time of 0 disables 812 the keep-alive mechanism. 814 PORT Options: A keep-alive message MUST NOT contain any of the 815 options defined in this document. It MAY contain other options 816 not defined in this document. Unknown options MUST be ignored. 817 See Section 5.3 for option definitions. 819 5.3. PORT Options 821 Each PORT Option is a TLV. The type is 16 bits. PORT Option types 822 are assigned by IANA, except the range 61440 - 65535 which is for 823 experimental use [RFC3692]. The length specifies the length of the 824 value in bytes. Below are the two options defined in this document. 826 PIM IPv4 Join/Prune Option 828 PIM IPv4 Join/Prune Option Format 830 0 1 2 3 831 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 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | PORT Option Type = 1 | Option Value Length | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | PIMv2 Join/Prune Message | 836 | . | 837 | . | 838 | . | 839 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 The IPv4 Join/Prune Option is used to carry a PIMv2 Join/Prune 842 message that has all IPv4 encoded addresses in the PIM payload. 844 Option Value Length: The number of bytes that make up the PIMv2 845 Join/Prune message. 847 PIMv2 Join/Prune Message: PIMv2 Join/Prune message and payload with 848 no IP header in front of it. 850 PIM IPv6 Join/Prune Option 852 PIM IPv6 Join/Prune Option Format 854 0 1 2 3 855 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 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | PORT Option Type = 2 | Option Value Length | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | PIMv2 Join/Prune Message | 860 | . | 861 | . | 862 | . | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 The IPv6 Join/Prune Option is used to carry a PIMv2 Join/Prune 866 message that has all IPv6 encoded addresses in the PIM payload. 868 Option Value Length: The number of bytes that make up the PIMv2 869 Join/Prune message. 871 PIMv2 Join/Prune Message: PIMv2 Join/Prune message and payload with 872 no IP header in front of it. 874 6. Explicit Tracking 876 When explicit tracking is used, a router keeps track of join state 877 for individual downstream neighbors on a given interface. This is 878 done for all PORT joins and prunes. It may also be done for native 879 join/prune messages, if all neighbors on the LAN have set the T bit 880 of the LAN Prune Delay option. In the discussion below we will talk 881 about ET (explicit tracking) neighbors, and non-ET neighbors. The 882 set of ET neighbors always includes the PORT neighbors. The set of 883 non-ET neighbors consists of all the non-PORT neighbors unless all 884 neighbors have set the LAN Prune Delay T bit. Then the ET neighbors 885 set contains all neighbors. 887 For some link-types, e.g. point-to-point, tracking neighbors is no 888 different than tracking interfaces. It may also be possible for an 889 implementation to treat different downstream neighbors as being on 890 different logical interfaces, even if they are on the same physical 891 link. Exactly how this is implemented and for which link types, is 892 left to the implementer. 894 For (*,G) and (S,G) state, the router starts forwarding traffic on an 895 interface when a Join is received from a neighbor on such an 896 interface. When a non-ET neighbor sends a Prune, as specified 897 [RFC4601], if no Join is sent to override this Prune before the 898 expiration of the Override Timer, the upstream router concludes that 899 no non-ET neighbor is interested. If no ET neighbors are interested, 900 the interface can be removed from the oif-list. When an ET neighbor 901 sends a Prune, one removes the join state for that neighbor. If no 902 other ET or non-ET neighbors are interested, the interface can be 903 removed from the oif-list. When a PORT neighbor sends a prune, there 904 can be no Prune Override, since the Prune is not visible to other 905 neighbors. 907 For (S,G,rpt) state, the router needs to track Prune state on the 908 shared tree. It needs to know which ET neighbors have sent prunes, 909 and whether any non-ET neighbors have sent prunes. Normally one 910 would forward a packet from a source S to a group G out on an 911 interface if a (*,G)-join is received, but no (S,G,rpt)-prune. With 912 ET one needs to do this check per ET neighbor. That is, the packet 913 should be forwarded unless all ET neighbors that have sent 914 (*,G)-joins have also sent (S,G,rpt)-prunes, and if a non-ET neighbor 915 has sent a (*,G)-join, whether there also is non-ET (S,G,rpt)-prune 916 state. 918 7. Multiple Address-Family Support 920 To allow for efficient use of router resources, one can mux Join/ 921 Prune messages of different address families on the same Transport 922 connections. There are two ways this can be accomplished, one using 923 a common message format over a TCP connection and the other using 924 multiple streams over a single SCTP connection. 926 Using the common message format described previously in this 927 specification, using different PORT options, both IPv4 and IPv6 based 928 Join/Prune messages can be encoded within the same Transport 929 connection. 931 When using SCTP multi-streaming, the common message format is still 932 used to convey address family information but an SCTP association is 933 used, on a per-family basis, to send data concurrently for multiple 934 families. When data is sent concurrently, head of line blocking, 935 which can occur when using TCP, is avoided. 937 8. Miscellany 939 No changes expected in processing of other PIM messages like PIM 940 Asserts, Grafts, Graft-Acks, Registers, and Register-Stops. This 941 goes for BSR and Auto-RP type messages as well. 943 This extension is applicable only to PIM-SM, PIM-SSM and Bidir-PIM. 944 It does not take requirements for PIM-DM into consideration. 946 9. Security Considerations 948 TCP connections can be authenticated using TCP-AO [RFC5925]. When 949 using SCTP, [RFC4895] can be used for authentication on a per SCTP 950 association basis. Also GTSM [RFC5082] can be used to help prevent 951 spoofing. 953 10. IANA Considerations 955 This specification makes use of a TCP port number and a SCTP port 956 number for the use of PIM-Over-Reliable-Transport that has been 957 allocated by IANA. It also makes use of IANA PIM Hello Options 958 allocations that should be made permanent. 960 10.1. PORT Hello Options 962 In the Protocol Independent Multicast (PIM) Hello Options registry, 963 the following options are needed for PORT. 965 Value Length Name Reference 966 ------- ---------- ----------------------- --------------- 967 27 Variable PIM-over-TCP Capable this document 968 28 Variable PIM-over-SCTP Capable this document 970 10.2. PORT Message Type Registry 972 A registry for PORT message types is requested. The message type is 973 a 16-bit integer, with values from 0 to 65535. An RFC is required 974 for assignments in the range 0 - 61439. This document defines one 975 PORT message type. Type 1, PORT Join/Prune Message. The type range 976 61440 - 65535 is for experimental use [RFC3692]. 978 The initial content of the registry should be as follows: 980 Type Name Reference 981 ------------- ------------------------------- --------------- 982 0 Reserved this document 983 1 Join/Prune this document 984 2 Keep-alive Message this document 985 3-61439 Unassigned 986 61440-65535 Experimental this document 988 10.3. PORT Option Type Registry 990 A registry for PORT option types is requested. The option type is a 991 16-bit integer, with values from 0 to 65535. An RFC is required for 992 assignments in the range 0 - 61439. This document defines two PORT 993 option types. Type 1, PIM IPv4 Join/Prune Message; and Type 2, PIM 994 IPv6 Join/Prune Message. The type range 61440 - 65535 is for 995 experimental use [RFC3692]. 997 The initial content of the registry should be as follows: 999 Type Name Reference 1000 ------------- ------------------------------- --------------- 1001 0 Reserved this document 1002 1 PIM IPv4 Join/Prune Message this document 1003 2 PIM IPv6 Join/Prune Message this document 1004 3-61439 Unassigned 1005 61440-65535 Experimental this document 1007 11. Contributors 1009 In addition to the persons listed as authors, significant 1010 contributions were provided by Apoorva Karan and Arjen Boers. 1012 12. Acknowledgments 1014 The authors would like to give a special thank you and appreciation 1015 to Nidhi Bhaskar for her initial design and early prototype of this 1016 idea. 1018 Appreciation goes to Randall Stewart for his authoritative review and 1019 recommendation for using SCTP. 1021 Thanks also goes to the following for their ideas and commentary 1022 review of this specification, Mike McBride, Toerless Eckert, Yiqun 1023 Cai, Albert Tian, Suresh Boddapati, Nataraj Batchu, Daniel Voce, John 1024 Zwiebel, Yakov Rekhter, Lenny Giuliano, Gorry Fairhurst, Sameer 1025 Gulrajani, Thomas Morin, Dimitri Papadimitriou, Bharat Joshi, Rishabh 1026 Parekh, Manav Bhatia and Pekka Savola. 1028 A special thank you goes to Eric Rosen for his very detailed review 1029 and commentary. Many of his comments are reflected as text in this 1030 specification. 1032 13. References 1034 13.1. Normative References 1036 [I-D.gulrajani-pim-hello-intid] 1037 Gulrajani, S. and S. Venaas, "An Interface ID Hello Option 1038 for PIM", draft-gulrajani-pim-hello-intid-00 (work in 1039 progress), February 2011. 1041 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 1042 RFC 793, September 1981. 1044 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1045 Requirement Levels", BCP 14, RFC 2119, March 1997. 1047 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1048 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1049 Protocol Specification (Revised)", RFC 4601, August 2006. 1051 [RFC4895] Tuexen, M., Stewart, R., Lei, P., and E. Rescorla, 1052 "Authenticated Chunks for the Stream Control Transmission 1053 Protocol (SCTP)", RFC 4895, August 2007. 1055 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1056 RFC 4960, September 2007. 1058 [RFC5015] Handley, M., Kouvelas, I., Speakman, T., and L. Vicisano, 1059 "Bidirectional Protocol Independent Multicast (BIDIR- 1060 PIM)", RFC 5015, October 2007. 1062 [RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., and C. 1063 Pignataro, "The Generalized TTL Security Mechanism 1064 (GTSM)", RFC 5082, October 2007. 1066 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 1067 Authentication Option", RFC 5925, June 2010. 1069 13.2. Informative References 1071 [AFI] IANA, "Address Family Indicators (AFIs)", ADDRESS FAMILY 1072 NUMBERS http://www.iana.org/numbers.html, February 2007. 1074 [HELLO-OPT] 1075 IANA, "PIM Hello Options", PIM-HELLO-OPTIONS per 1076 RFC4601 http://www.iana.org/assignments/pim-hello-options, 1077 March 2007. 1079 [RFC3692] Narten, T., "Assigning Experimental and Testing Numbers 1080 Considered Useful", BCP 82, RFC 3692, January 2004. 1082 Authors' Addresses 1084 Dino Farinacci 1085 cisco Systems 1086 Tasman Drive 1087 San Jose, CA 95134 1088 USA 1090 Email: dino@cisco.com 1092 IJsbrand Wijnands 1093 cisco Systems 1094 Tasman Drive 1095 San Jose, CA 95134 1096 USA 1098 Email: ice@cisco.com 1100 Stig Venaas 1101 cisco Systems 1102 Tasman Drive 1103 San Jose, CA 95134 1104 USA 1106 Email: stig@cisco.com 1108 Maria Napierala 1109 AT&T Labs 1110 200 Laurel Drive 1111 Middletown, New Jersey 07748> 1112 USA 1114 Email: mnapierala@att.com