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