idnits 2.17.1 draft-ietf-magma-msnip-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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 284: '...v6. This option MUST be included in a...' RFC 2119 keyword, line 311: '... configuration SHOULD be logged to t...' RFC 2119 keyword, line 315: '...ers on that link MUST be configured to...' RFC 2119 keyword, line 341: '...en the IP system MUST default to flood...' RFC 2119 keyword, line 349: '... IP system MUST use the SSM multi...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Both the Host Interest Solicitation message and the Receiver Membership Report message MUST not be forwarded by routers (see Section 12). The Router Alert option [RFC2113] [RFC2711] MUST be included in the packet by the router or host IP system transmitting the message. Routers receiving Host Interest Solicitation messages and IP systems receiving Receiver Membership Reports MUST not process a received MSNIP message if the Router Alert option is not present. -- 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 4801 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 4601 (Obsoleted by RFC 7761) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Fenner 3 Internet-Draft AT&T Labs--Research 4 Intended status: Standards Track B. Haberman 5 Expires: September 5, 2011 Johns Hopkins University Applied 6 Physics Lab 7 H. Holbrook 8 Arastra, Inc. 9 I. Kouvelas 10 S. Venaas 11 cisco Systems 12 March 4, 2011 14 Multicast Source Notification of Interest Protocol (MSNIP) 15 draft-ietf-magma-msnip-06.txt 17 Abstract 19 This document discusses the Multicast Source Interest Notification 20 Protocol (MSNIP). MSNIP is an extension to IGMPv3 and MLDv2 that 21 provides membership notification services for sources of multicast 22 traffic operating within the SSM destination address range. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 5, 2011. 41 Copyright Notice 43 Copyright (c) 2011 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Routing Protocol Support . . . . . . . . . . . . . . . . . . . 4 60 3. Service Interface for Requesting Membership Notification . . . 5 61 3.1. Application Operation . . . . . . . . . . . . . . . . . . 6 62 4. MSNIP Managed Address Range Negotiation . . . . . . . . . . . 7 63 4.1. Router Coordination . . . . . . . . . . . . . . . . . . . 7 64 4.1.1. MSNIP Operation Option . . . . . . . . . . . . . . . . 7 65 4.1.2. SSM Range Option . . . . . . . . . . . . . . . . . . . 8 66 4.2. Managed Range Discovery by Source Systems . . . . . . . . 8 67 5. Requesting and Receiving Notifications . . . . . . . . . . . . 10 68 5.1. Host Interest Solicitation . . . . . . . . . . . . . . . . 10 69 5.2. Router Receiver Membership Reports . . . . . . . . . . . . 11 70 6. Application Notification . . . . . . . . . . . . . . . . . . . 13 71 7. Router Processing . . . . . . . . . . . . . . . . . . . . . . 15 72 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 17 73 8.1. Host Interest Solicitation Message . . . . . . . . . . . . 17 74 8.2. Receiver Membership Report Message . . . . . . . . . . . . 18 75 8.3. IPv4 Header Fields . . . . . . . . . . . . . . . . . . . . 19 76 8.4. IPv6 Header Fields . . . . . . . . . . . . . . . . . . . . 19 77 9. Constants Timers and Default Values . . . . . . . . . . . . . 20 78 10. Possible Optimisations . . . . . . . . . . . . . . . . . . . . 21 79 10.1. Suppressing HIS Messages . . . . . . . . . . . . . . . . . 21 80 10.2. Host Stack Filtering . . . . . . . . . . . . . . . . . . . 21 81 10.3. Responding to Unexpected IGMP Queries . . . . . . . . . . 21 82 10.4. Host and Router Startup . . . . . . . . . . . . . . . . . 22 83 11. Inter-operation with IGMP / MLD Proxying . . . . . . . . . . . 23 84 12. Security Considerations . . . . . . . . . . . . . . . . . . . 24 85 12.1. Receiver Membership Report Attacks . . . . . . . . . . . . 24 86 12.2. Host Interest Solicitation Attacks . . . . . . . . . . . . 24 87 12.3. MSNIP Managed Range Discovery . . . . . . . . . . . . . . 25 88 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 89 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 90 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 91 15.1. Normative References . . . . . . . . . . . . . . . . . . . 28 92 15.2. Informative References . . . . . . . . . . . . . . . . . . 28 93 Appendix A. Extending MSNIP to Any-Source Multicast . . . . . . . 30 94 A.1. Extending MSNIP to ASM with PIM-SM . . . . . . . . . . . . 30 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 97 1. Introduction 99 The Multicast Source Notification of Interest Protocol (MSNIP) is an 100 extension to version 3 of the Internet Group Membership Protocol 101 (IGMPv3 [RFC3376]) and version 2 of the Multicast Listener Discovery 102 Protocol (MLDv2 [RFC3810]). MSNIP operates between multicast sources 103 and their first-hop routers to provide information on the presence of 104 receivers to the source systems. Using the services offered by MSNIP 105 an application on an IP system wishing to source multicast data can 106 register to be notified when receivers join and leave the session. 107 This enables multicast sources to avoid the work of transmitting 108 packets onto their first-hop link when there are no joined receivers. 110 A common scenario where MSNIP may be useful is one where there is a 111 multicast server offering a large pool of potential flows that map 112 onto separate multicast destination addresses but receivers exist 113 only for a small subset of the flows. If the source were to 114 continuously transmit data for all the flows that could potentially 115 have receivers, significant resources would be wasted in the system 116 itself as well as the first-hop link and first-hop router. Using a 117 higher level control protocol to determine the existence of receivers 118 for particular flows may not be practical as there may be many 119 potential receivers in each active session. 121 Information on which multicast destination addresses have receivers 122 for a particular sender is typically available to the multicast 123 routing protocol on the first hop router for a source. MSNIP uses 124 this information to notify the application in the sending system of 125 when it should start or stop transmitting. This is achieved without 126 any destination address specific state on the first-hop router for 127 potential sources without receivers. 129 2. Routing Protocol Support 131 For reasons described in this section, MSNIP only supports 132 transmission control for applications that use multicast destination 133 addresses that are routed using Source Specific Multicast (SSM). See 134 Appendix A for information on how MSNIP potentially can be extended 135 to also work with Any-Source Multicast (ASM). 137 Many currently deployed multicast routing protocols require data from 138 an active source to be propagated past the first-hop router before 139 information on the existence of receivers becomes available on the 140 first-hop. In addition, such protocols require that this activity is 141 repeated periodically to maintain source liveness state on remote 142 routers. All dense-mode protocols fall under this category as well 143 as sparse-mode protocols that use shared trees for source discovery 144 (such as PIM-SM [RFC4601]). In order to provide receiver interest 145 notification for such protocols, the default mode of operation would 146 require that the source IP system periodically transmits on all 147 potential destination addresses and the first-hop routers prune the 148 traffic back. Such a flood-and-prune behavior on the first-hop link 149 significantly diminishes the benefits of managing source 150 transmission. 152 In contrast, with source-specific sparse-mode protocols such as PIM- 153 SSM [RFC4601]) availability of receiver membership information on the 154 first-hop routers is independent of data transmission. Such 155 protocols use an external mechanism for source discovery (like 156 source-specific IGMPv3 membership reports) to build source-specific 157 multicast trees. 159 Clearly these two classes of routing protocols require different 160 handling for the problem MSNIP is trying to solve. In addition the 161 second type covers the majority of applications that MSNIP is 162 targeted at. MSNIP avoids the extra complication in supporting 163 routing protocols that require a flood and prune behavior. 165 3. Service Interface for Requesting Membership Notification 167 Applications within an IP system that wish to source multicast 168 packets and are interested in being notified on the existence of 169 receivers must register with the IP layer of the system. MSNIP 170 requires that within the IP system, there is (at least conceptually) 171 a service interface that can be used to register with the IP layer 172 for such notifications. Dual stack systems supporting both IPv4 and 173 IPv6 need to provide separate service interfaces for each protocol. 175 A system's IPv4 or IPv6 service interface must support the following 176 operation or any logical equivalent: 178 IPMulticastSourceRegister (socket, source-address, multicast- 179 address) 181 IPMulticastSourceDeregister (socket, source-address, multicast- 182 address) 184 In addition the application must provide the following interface for 185 receiving notifications from the IP system: 187 IPMulticastSourceStart (socket, source-address, multicast-address) 189 IPMulticastSourceStop (socket, source-address, multicast-address) 191 where: 193 socket: is an implementation-specific parameter used to distinguish 194 amongst different requesting entities (e.g., programs or 195 processes) within the system; the socket parameter of BSD UNIX 196 system calls is a specific example. 198 source-address: is the IP unicast source address that the 199 application wishes to use in transmitting data to the specified 200 multicast address. The specified address must be one of the IP 201 addresses associated with the network interfaces of the IP system. 202 Note that an interface in an IP system may be associated with more 203 than one IP address. An implementation may allow a special 204 "unspecified" value to be passed as the source-address parameter, 205 in which case the request would apply to the "primary" IP address 206 of the "primary" or "default" interface of the system (perhaps 207 established by system configuration). If transmission to the same 208 multicast address is desired using more than one source IP 209 address, IPMulticastSourceRegister must be invoked separately for 210 each desired source address. 212 multicast-address: is the IP multicast destination address to which 213 the request pertains. If the application wishes to transmit data 214 to more than one multicast addresses for a given source address, 215 IPMulticastSourceRegister must be invoked separately for each 216 desired multicast address. 218 3.1. Application Operation 220 Applications wishing to use MSNIP to control their multicast data 221 transmission to destination G from source address S operate as 222 follows. 224 Initially the application contacts the IP system to obtain the socket 225 handle for use on all subsequent interactions. The application 226 invokes IPMulticastSourceRegister for the desired S and G and then 227 waits without transmitting any packets for the IP system to notify 228 that receivers for the session exist. 230 If and when the IP system notifies the application that receivers 231 exist using the IPMulticastSourceStart call, the application may 232 start transmitting data. After the application has been notified to 233 send, if all receivers for the session leave, the IP system will 234 notify the application using the IPMulticastSourceStop call. At this 235 point the application should stop transmitting data until it is 236 notified again that receivers have joined through another 237 IPMulticastSourceStart call. 239 When the application no longer wishes to transmit data it should 240 invoke the IPMulticastSourceDeregister call to let the IP system know 241 that it is no longer interested in notifications for this source and 242 destination. The IPMulticastSourceDeregister call should be implicit 243 in the teardown of the associated socket state. 245 4. MSNIP Managed Address Range Negotiation 247 With current multicast deployment in the Internet, different 248 multicast routing protocols coexist and operate under separate parts 249 of the multicast address space. Multicast routers are consistently 250 configured with information that maps specific multicast address 251 ranges to multicast routing protocols. Part of this configuration 252 describes the subset of the address space that is used by source- 253 specific multicast (SSM) [RFC5771]. As described in section 2, MSNIP 254 only tries to control application transmission within the SSM address 255 range. 257 It is desirable for applications within an IP system that supports 258 MSNIP to have a consistent service interface for multicast 259 transmission that does not require the application to be aware of the 260 SSM address range. MSNIP supports this by allowing applications to 261 use the service interface described in section 3 for multicast 262 destination addresses that are outside its operating range. When an 263 application registers for notifications for a destination address 264 that is not managed by MSNIP it is immediately notified to start 265 transmitting. This is equivalent to the default behavior of IP 266 multicast without MSNIP support which forces multicast applications 267 to assume that there are multicast receivers present in the network. 269 4.1. Router Coordination 271 In order for MSNIP to operate on a shared link where two or more 272 multicast routers may be present, all the multicast routers must be 273 MSNIP-capable and have an identical configuration for the SSM address 274 range. MSNIP enforces these requirements by using two new options 275 for IPv4 in the Multicast Router Discovery protocol [RFC4286] and one 276 new option for IPv6 in the Neighbor Discovery / ICMPv6 protocol 277 [RFC4861]. 279 4.1.1. MSNIP Operation Option 281 A multicast router advertises that it is participating in MSNIP using 282 the MSNIP Operation option in either the Multicast Router Discovery 283 protocol for IPv4 or the Neighbor Discovery / ICMPv6 protocol for 284 IPv6. This option MUST be included in all router advertisement 285 messages of a router that is configured for MSNIP. The format of the 286 option is as follows: 288 0 1 2 3 289 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 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type | Length | Padding | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Padding | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 Type: The type field is set to WW (TBD by IANA) for IPv4 and ZZ 297 (TBD by IANA) for IPv6. 299 Length: The length field is set to 0 for IPv4 and 1 for IPv6. 301 Padding: The six extra bytes of padding are only present in IPv6 302 and are required to bring the size of the option up to the eight 303 octet boundary. The value of the padding bytes must be set to 304 zero on transmission and ignored on receipt. 306 A multicast router uses received Multicast Router Advertisement and 307 Neighbor Discovery / ICMPv6 messages to determine if all live 308 neighbor multicast routers on each interface are participating in 309 MSNIP. When a router advertisement message not containing an MSNIP 310 option is received by a router participating in MSNIP, the mis- 311 configuration SHOULD be logged to the operator in a rate-limited 312 manner. 314 If even one multicast router on a link does not have MSNIP capability 315 then ALL routers on that link MUST be configured to not provide MSNIP 316 services and to not advertise the MSNIP Operation option. 318 4.1.2. SSM Range Option 320 The SSM Range Multicast Router Discovery option advertises the IPv4 321 SSM Range with which the router is configured. The option is defined 322 in [I-D.ietf-magma-mrdssm]. This option is only valid in IPv4. The 323 SSM range for IPv6 is well defined for all valid scopes [RFC3306] and 324 a mechanism to allow additional ranges to operate in SSM mode on a 325 per-link bases is not required. 327 4.2. Managed Range Discovery by Source Systems 329 When an application in an IP system uses the MSNIP service interface 330 to register for notification, the IP system must behave differently 331 depending on whether or not the destination address for which the 332 application registered is operating under SSM (and is being managed 333 by MSNIP). For SSM channels, the IP system should only instruct the 334 application to transmit when there are receivers for the multicast 335 destination. For non-SSM destination addresses the IP system will 336 not be able to determine if there are receivers and should 337 immediately instruct the application to transmit. In addition, an 338 MSNIP-capable IP system must be able to detect if there are multicast 339 routers on its connected links and if they support MSNIP operation. 340 If no multicast routers are present or if the multicast routers are 341 not MSNIP-capable then the IP system MUST default to flooding and 342 immediately instruct applications to transmit. 344 An IP system controls transmission behavior under the different 345 possible conditions by adapting its definition of the MSNIP-managed 346 multicast destination address range: 348 o On a link with multicast routers operating the MSNIP protocol the 349 IP system MUST use the SSM multicast destination address range as 350 the MSNIP-managed range. IPv4 systems MUST use the contents of 351 the SSM Range option in received Multicast Router Advertisement 352 messages [I-D.ietf-magma-mrdssm] to discover the configured SSM 353 range. SSM range discovery is not needed in IPv6 where the SSM 354 destination address range is fixed. 356 o On a link not connected to a multicast routed infrastructure or on 357 a link with multicast routers that do not support MSNIP operation, 358 the IP system MUST use an empty range as its MSNIP-managed range. 359 This forces applications transmitting to any multicast destination 360 address to default to flooding thus providing backward 361 compatibility. 363 As described in Section 4.1.1, an IP system can determine the status 364 of a link and distinguish between the above two cases through the 365 reception of IPv4 Multicast Router Advertisement and Neighbor 366 Discovery / ICMPv6 messages. 368 5. Requesting and Receiving Notifications 370 Like IGMP, MSNIP is an asymmetric protocol specifying different 371 behavior for systems wishing to source traffic and for multicast 372 routers. Host IP systems multicast Host Interest Solicitation 373 messages to register for notification with their first-hop routers. 374 Routers unicast Router Receiver Membership Reports to IP systems to 375 notify them of the arrival of the first or departure of the last 376 receiver for a session. Note that a system may perform at the same 377 time both of the above functions. An example is a router that wishes 378 to source traffic. 380 5.1. Host Interest Solicitation 382 Source systems that wish to be managed by MSNIP periodically transmit 383 a Host Interest Solicitation message. This message is multicast with 384 a multicast destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) or 385 ALL_MLDv2_ROUTERS (FF02::16) and is transmitted every [Interest 386 Solicitation Interval] seconds. The Host Interest Solicitation 387 message contains a holdtime which is set to [Interest Solicitation 388 Holdtime] and instructs the multicast first-hop routers to maintain 389 MSNIP state for this IP system for the specified period. Systems 390 with multiple interfaces or multiple IP addresses per interface must 391 originate separate Host Interest Solicitation messages from each of 392 their IP addresses that they wish to have managed by MSNIP. In 393 practice a system with more than one IP address is treated by MSNIP 394 as multiple IP systems. 396 When an IP system first comes up it transmits [Robustness Variable] 397 Host Interest Solicitation messages spaced by [Initial Interest 398 Solicitation Interval] seconds. 400 All MSNIP capable routers that receive a Host Interest Solicitation 401 message from an IP system, maintain a system interest record of the 402 form: 404 (IP system address, holdtime timer) 406 Each time a Host Interest Solicitation message is received from the 407 IP system, the holdtime timer is reset to the holdtime in the 408 received message. In addition the router may respond to the 409 solicitation message with a Receiver Membership Report message 410 described in Section 5.2. The message contains a TRANSMIT record for 411 each of the multicast destination addresses within the MSNIP-managed 412 range for which the routing protocol indicates there are receivers 413 for this source system. 415 The holdtime timer of a record counts down to zero. When the 416 holdtime timer of a specific system interest record expires, the 417 record is deleted. 419 5.2. Router Receiver Membership Reports 421 Receiver Membership Report messages are used by routers to 422 communicate the receiver membership status of particular multicast 423 destination addresses to a specific IP system. Each message contains 424 a list of transmission control records of either TRANSMIT or HOLD 425 type that instruct a system to respectively start or stop sending 426 traffic on this link to the specified multicast destination address. 427 Receiver Membership Report messages are unicast to the target system. 429 In addition to reports sent in response to Host Interest Solicitation 430 messages, routers send unsolicited Receiver Membership Reports to IP 431 systems when the receiver membership status reported by the multicast 432 routing protocol changes for a specific source and multicast 433 destination. Such reports are only sent if the multicast destination 434 address is managed by MSNIP and the router has a system interest 435 record created by a previously received Host Interest Solicitation 436 message with an IP system address equal to the source address. If 437 the source / destination pair satisfy these conditions then 438 [Robustness Variable] Receiver Membership Reports are sent out spaced 439 by [Unsolicited Membership Report Interval] seconds. If the 440 membership status changes again for the same destination address and 441 source system while transmission of Receiver Membership Reports is 442 still pending then the pending report messages are canceled and a new 443 set of [Robustness Variable] messages indicating the new state are 444 scheduled. 446 When an IP system receives a Receiver Membership Report message, for 447 each of the TRANSMIT records listed in the message, it creates or 448 updates a transmission record of the form: 450 (router address, source address, multicast address, holdtime 451 timer) 453 The router address is obtained from the source address of the IP 454 header of the received message. The source address is obtained from 455 the destination address of the IP header of the received message. 456 The multicast address is obtained from the information in the 457 TRANSMIT record. The holdtime timer is set to the value of the 458 holdtime field in the received Receiver Membership Report message. 460 For each HOLD record present in the message, the system deletes the 461 matching previously created transmission record from its state. 463 The holdtime timer of a record counts down to zero. When the 464 holdtime timer of a specific transmission record expires, the record 465 is deleted. 467 Note that creation and deletion of transmission records in an IP 468 system's state may cause local applications to be notified to start 469 and stop transmitting data (see Section 6). 471 6. Application Notification 473 This section describes the relation between protocol events and 474 notifications to source applications within an IP system. The state 475 machine below is specific to each source address of the IP system and 476 each multicast destination address. The initial state is the No Info 477 state. 479 In tabular form, the state-machine is: 481 +------------------+---------------------------------------------+ 482 | | Previous State | 483 | Event +--------------+---------------+--------------+ 484 | | No Info | Hold | Transmit | 485 +------------------+--------------+---------------+--------------+ 486 | New Register | - | - | - | 487 | | Start new | | Start new | 488 +------------------+--------------+---------------+--------------+ 489 | | -> Hold | - | - | 490 | Start Manage | Stop ALL | | | 491 | | registered | | | 492 +------------------+--------------+---------------+--------------+ 493 | | - | -> No Info | -> No Info | 494 | Stop Manage | | Stop ALL | | 495 | | | registered | | 496 +------------------+--------------+---------------+--------------+ 497 | | - | -> Transmit | - | 498 | Recv TRANSMIT | | Start ALL | | 499 | | | registered | | 500 +------------------+--------------+---------------+--------------+ 501 | Recv last HOLD | - | - | -> Hold | 502 | or timeout | | | Stop ALL | 503 | | | | registered | 504 +------------------+--------------+---------------+--------------+ 506 The events in the state machine above have the following meaning: 508 New register: A new application has registered through a call to 509 IPMulticastSourceRegister for this S and G. 511 Start manage: We received an SSM Range option in an MRD packet on 512 the interface that S belongs to that changed the status of G from 513 a non-managed to a MSNIP-managed destination address. The SSM 514 Range option is only valid in IPv4. 516 Stop manage: We received an SSM Range option in an MRD packet on 517 the interface that S belongs to that changed the status of G from 518 a MSNIP-managed to a non-managed destination address or the 519 mapping state that caused this destination address to be managed 520 expired. The SSM Range option is only valid in IPv4. 522 Receive TRANSMIT: We received a Receiver Membership Report with S 523 as the IP destination address that contains a TRANSMIT record for 524 G. 526 Receive last HOLD or timeout: We either received a Receiver 527 Membership Report with S as the IP destination address that 528 contains a HOLD record for G or the holdtime timer in a 529 transmission record for S and G expired and there are no other 530 transmission records for S and G. This means that the last router 531 that was reporting receivers no longer does so and there are no 532 routers left wishing to receive traffic from this S to destination 533 address G. 535 The state machine actions have the following meaning: 537 Start new: Send an IPMulticastSourceStart notification to the 538 application that just registered for this S and G. 540 Start ALL registered: Send an IPMulticastSourceStart notification 541 to all applications that are registered for this S and G. 543 Stop ALL registered: Send an IPMulticastSourceStop notification to 544 all applications that are registered for this S and G. 546 7. Router Processing 548 This section describes the per-source system tracking state machine 549 operated by each first-hop router. The initial state is No Info. 551 In tabular form, the state-machine is: 553 +---------------------+----------------------------------------------+ 554 | | Previous State | 555 | Event +----------------------+-----------------------+ 556 | | Not tracking | Tracking | 557 +---------------------+----------------------+-----------------------+ 558 | | -> Tracking | - | 559 | Receive HIS | Set HT to message | Set HT to message | 560 | | holdtime; Send ALL | holdtime; Send ALL | 561 | | existing TRANSMITs | existing TRANSMITs | 562 +---------------------+----------------------+-----------------------+ 563 | HIS timeout | - | -> Not tracking | 564 | | | | 565 +---------------------+----------------------+-----------------------+ 566 | Receivers for new | - | - | 567 | destination G | | Send TRANSMIT for G | 568 +---------------------+----------------------+-----------------------+ 569 | Receivers of G | - | - | 570 | leave | | Send HOLD for G | 571 +---------------------+----------------------+-----------------------+ 573 The events in the state machine above have the following meaning: 575 Receive HIS: The router has received a Host Interest Solicitation 576 from S. 578 HIS timeout: The holdtime timer (HT) in the host interest record 579 associated with S has expired. 581 Receivers for new destination G: The routing protocol has informed 582 MSNIP that it now has receivers for the MSNIP-managed destination 583 address G and source IP system S. 585 Receivers of G leave: The routing protocol has informed MSNIP that 586 all receivers for the MSNIP-managed destination address G and 587 source IP system S have left the channel. 589 The state machine actions have the following meaning: 591 Set HT to message holdtime: The holdtime timer in the host interest 592 record associated with S is restarted to the value of the holdtime 593 field in the received Host Interest Solicitation message. 595 Send ALL existing TRANSMITs: The router builds and transmits 596 Receiver Membership Reports to S that contain a TRANSMIT record 597 for each of the MSNIP-managed destination addresses that have 598 receivers for S. 600 Send TRANSMIT for G: The router builds and transmits a Receiver 601 Membership Report to S that contains a TRANSMIT record for the 602 destination address G. 604 Send HOLD for G: The router builds and transmits a Receiver 605 Membership Report to S that contains a HOLD record for the 606 destination address G. 608 8. Message Formats 610 The following packet formats are valid for both IPv4 and IPv6. IP 611 version-specific values will be explicitly defined. 613 There are two message types of concern to the MSNIP protocol 614 described in this document: 616 +---------------------+------------------------------+ 617 | Type Number (hex) | Message Name | 618 +---------------------+------------------------------+ 619 | 0xXX | Host Interest Solicitation | 620 +---------------------+------------------------------+ 621 | 0xYY | Receiver Membership Report | 622 +---------------------+------------------------------+ 624 Both the Host Interest Solicitation message and the Receiver 625 Membership Report message MUST not be forwarded by routers (see 626 Section 12). The Router Alert option [RFC2113] [RFC2711] MUST be 627 included in the packet by the router or host IP system transmitting 628 the message. Routers receiving Host Interest Solicitation messages 629 and IP systems receiving Receiver Membership Reports MUST not process 630 a received MSNIP message if the Router Alert option is not present. 632 8.1. Host Interest Solicitation Message 634 A Host Interest Solicitation message is periodically multicast by 635 MSNIP capable systems to declare interest in Receiver Membership 636 Reports from multicast routers on the link. The Host Interest 637 Solicitation message is multicast with a destination address of 638 ALL_IGMPv3_ROUTERS (224.0.0.22) or ALL_MLDv2_ROUTERS (FF02::16). 640 0 1 2 3 641 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 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Type | Reserved | Checksum | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Holdtime | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 Type: The type field is set to XX (to be assigned by IANA as an 649 IGMP type for IPv4 and an ICMPv6 type for IPv6). 651 Reserved: Transmitted as zero. Ignored upon receipt. 653 Checksum: In IPv4, the Checksum is the 16-bit one's complement of 654 the one's complement sum of the whole IGMP message (the entire IP 655 payload). In IPv6, the Checksum is the standard ICMPv6 checksum, 656 covering the entire MLDv2 message plus a "pseudo-header" of IPv6 657 header fields [RFC4443]. For computing the checksum, the Checksum 658 field is set to zero. When receiving packets, the checksum MUST 659 be verified before processing a packet. 661 Holdtime: The amount of time a receiving router must keep the 662 system interest state alive, in seconds. The default value for 663 this field is [Interest Solicitation Holdtime]. 665 8.2. Receiver Membership Report Message 667 A Receiver Membership Report message is unicast by first-hop 668 multicast routers and targeted at potential sources to inform them of 669 the existence or not of receivers for the listed multicast 670 destination addresses. 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Type | Dest Count | Checksum | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Holdtime | Reserved | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Record-Type-1 | Record-Reserved-1 | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Destination-Address-1 | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | . | 684 | . | 685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 Type: The type field is set to YY (to be assigned by IANA as an 688 IGMP type for IPv4 and an ICMPv6 type for IPv6). 690 Dest Count: The number of multicast destination address records 691 present in this message. 693 Checksum: In IPv4, the Checksum is the 16-bit one's complement of 694 the one's complement sum of the whole IGMP message (the entire IP 695 payload). In IPv6, the Checksum is the standard ICMPv6 checksum, 696 covering the entire MLDv2 message plus a "pseudo-header" of IPv6 697 header fields [RFC4443]. For computing the checksum, the Checksum 698 field is set to zero. When receiving packets, the checksum MUST 699 be verified before processing a packet. 701 Holdtime: The amount of time in seconds that the target host must 702 keep alive the transmission record state created or updated by the 703 TRANSMIT records in this report. The router originating the 704 Receiver Membership Report sets this field to the current value of 705 the holdtime timer in the system interest record corresponding to 706 the target host. As a result Receiver Membership Reports sent in 707 response to the reception of a Host Interest Solicitation message 708 have their holdtime set to the value of the holdtime field in the 709 received HIS message. 711 Reserved: Transmitted as zero. Ignored upon receipt. 713 Record-Type-1: The type of the first transmission control record in 714 this message. Valid values are: 716 +-------------+----------------------------------------------+-------+ 717 | Record Type | Description | Value | 718 +-------------+----------------------------------------------+-------+ 719 | TRANSMIT | Request to start transmitting to destination | 1 | 720 +-------------+----------------------------------------------+-------+ 721 | HOLD | Request to stop transmitting to destination | 2 | 722 +-------------+----------------------------------------------+-------+ 724 Record-Reserved-1: Transmitted as zero. Ignored upon receipt. 726 Destination-Address-1: The multicast destination address of the 727 first record in the message. 729 8.3. IPv4 Header Fields 731 Like all IGMP messages, MSNIP messages are encapsulated in IPv4 732 datagrams, with an IP protocol number of 2. MSNIP messages can be 733 identified from other IGMP messages by the message types listed in 734 Section 8. Every MSNIP message described in this document is sent 735 with an IP Time-to-Live of 1, and carries an IP Router Alert option 736 [RFC2113] in its IP header. 738 8.4. IPv6 Header Fields 740 MLD messages are a sub-protocol of the Internet Control Message 741 Protocol (ICMPv6 [RFC4443]). MSNIP messages are identified in IPv6 742 packets by the combination of a preceding Next Header value of 58 and 743 by the MLD message types listed in Section 8. All MSNIP messages 744 described in this document are sent with a link-local IPv6 Source 745 Address (or the unspecified address, if a valid link-local address is 746 not available), an IPv6 Hop Limit of 1, and an IPv6 Router Alert 747 option [RFC2711] in a Hop-by-hop Options header. 749 9. Constants Timers and Default Values 751 Robustness Variable: The Robustness Variable allows tuning for the 752 expected packet loss on a network. If a network is expected to be 753 lossy, the Robustness Variable may be increased. MSNIP is robust 754 to (Robustness Variable - 1) packet losses. The Robustness 755 Variable MUST NOT be zero, and SHOULD NOT be one. Default: 2 757 Interest Solicitation Interval: The interval used by MSNIP capable 758 systems between transmissions of Host Interest Solicitation 759 messages. Default: 60 secs 761 Interest Solicitation Holdtime: The interval inserted in Host 762 Interest Solicitation messages by systems to instruct routers how 763 long they should maintain system interest state for. This MUST be 764 ((the Robustness Variable) times (the Interest Solicitation 765 Interval) plus (one second)). 767 Initial Interest Solicitation Interval: The interval used by 768 systems to send out the initial Host Interest Solicitation 769 messages when they first come up. Default: 1 second. 771 Unsolicited Membership Report Interval: The interval used by 772 routers to send out a set of Membership Report messages when the 773 receiver membership changes for a specific system. Default: 1 774 second. 776 10. Possible Optimisations 778 10.1. Suppressing HIS Messages 780 A possible optimisation for MSNIP is to suppress the transmission of 781 Host Interest Solicitation messages from the source address of an IP 782 system for which no local application has registered interest. In 783 addition to conserving bandwidth, not transmitting HIS messages 784 prevents remote receivers for groups with no matching source 785 application from creating transmission record state in the host 786 system. 788 10.2. Host Stack Filtering 790 Legacy applications that have not been coded with MSNIP support can 791 still be prevented from wasting first-hop link bandwidth by filtering 792 transmitted packets at the operating system level. Even though such 793 applications will not register for MSNIP notifications with the host 794 operating system, if the OS is MSNIP-capable and the application is 795 transmitting data to an MSNIP-managed group for which there are no 796 transmit records, the OS can safely filter the packets and not 797 transmit them on the wire. 799 A problem with the filtering approach is that it cannot be combined 800 with the HIS message suppression optimisation (see Section 10.1). If 801 there are no registered applications in the system and HIS messages 802 are being suppressed then the first-hop routers will not send any 803 Receiver Membership Reports to the system. As a result, knowledge of 804 receiver membership from the presence of transmit records for groups 805 operated by legacy applications will not exist. It therefore becomes 806 unsafe to filter packets from legacy applications. 808 10.3. Responding to Unexpected IGMP Queries 810 Under steady state the router side of the IGMP protocol elects a 811 single router on each link that is responsible for issuing IGMP 812 Queries. Routers other than the acting IGMP querier will send an 813 IGMP Query only if they restart and have no IGMP querier election 814 state or if the active Querier crashes and a new election takes 815 place. 817 MSNIP can take advantage of this mechanism to quickly populate the 818 host interest records of a new router starting up. When the router 819 comes up it will issue an IGMP Query in an attempt to be elected as a 820 Querier. MSNIP-capable hosts will notice that the sender of the 821 Query is not the acting Querier. They can use this trigger to 822 respond with Host Interest Solicitation Messages (with transmission 823 randomised over a small interval) to quickly bring the new router up- 824 to-date. 826 10.4. Host and Router Startup 828 When a host operating system is restarted there may be applications 829 that are started as part of the initialisation process and want to 830 source IPv4 multicast traffic. It is possible for the applications 831 to register through MSNIP with the IP subsystem and to start 832 transmitting multicast data before the host receives the MSNIP- 833 managed range definition through the SSM Range option of the 834 Multicast Router Discovery protocol. 836 This temporary flooding can be avoided if the host OS holds off 837 notifying MSNIP-capable applications that they can transmit until it 838 receives an MRD advertisement and learns the SSM configuration for 839 the network. This behaviour has the drawback that it is not 840 compatible with legacy networks with no MRD deployment. In such a 841 network the host OS has to be able to determine after a configurable 842 period that MRD is not enabled and hence all multicast applications 843 wishing to source traffic should be notified to transmit. A good 844 default value for this period is the MAX_RESPONSE_DELAY of the 845 Multicast Router Discovery protocol [RFC4286]. 847 Late router startup is harder to deal with. Hosts that start up 848 before the multicast router may time out waiting for an MRD 849 advertisement and instruct all MSNIP-capable multicast source 850 applications to transmit data. One way to work around this problem 851 is to configure the host OS to wait forever for an MRD advertisement 852 before instructing MSNIP applications to transmit. 854 11. Inter-operation with IGMP / MLD Proxying 856 MSNIP is intended for use on networks with multicast servers offering 857 a large number of potential sessions. Although unlikely, it is 858 possible to deploy such a server behind an IGMP / MLD Proxy 859 [RFC4605]. If the proxy is not MSNIP-aware and does not implement 860 the extensions described below then sources behind the proxy will 861 default to flooding. 863 If a device performing IGMP / MLD Proxying wishes to proxy MSNIP, it 864 MUST forward MSNIP Host Interest Solicitation messages that are 865 received on downstream interfaces to its upstream interface. No 866 special treatment is required for MSNIP Receiver Membership Reports 867 as they are unicast to the target host. 869 In addition to the forwarding of MSNIP messages, an IGMP proxy MUST 870 operate the Multicast Router Discovery protocol [RFC4286] on all its 871 downstream interfaces and advertise the MSNIP capability option 872 (Section 4.1.1) and SSM address range option (Section 4.1.2). The 873 MSNIP capability option should be advertised on downstream interfaces 874 only if it is included in MRD messages received on the upstream 875 interface. The address range to be included in the SSM Range option 876 MUST be determined by MRD and IGMP messages received on the upstream 877 interface of the proxy according to the rules in Section 4.2. 879 In addition to the forwarding of MSNIP messages, an MLD proxy MUST 880 operate the IPv6 Neighbour Discovery protocol. The MSNIP capability 881 option should be advertised on downstream interfaces when it is 882 included in IPv6 Neighbour Discovery messages received on the 883 upstream interface. 885 12. Security Considerations 887 We consider the ramifications of a forged message of each type. As 888 described in [RFC3376] and [RFC3810], IPSEC AH can be used to 889 authenticate IGMP and MLD messages if desired. 891 12.1. Receiver Membership Report Attacks 893 A DoS attack on a host could be staged through forged Receiver 894 Membership Report messages. The attacker can send a large number of 895 reports, each with a large number of TRANSMIT records and a holdtime 896 field set to a large value. The host will have to store and maintain 897 the transmission records specified in all of those reports for the 898 duration of the holdtime. This would consume both memory and CPU 899 cycles in the host. 901 Forged Receiver Membership Report messages from the local network can 902 be easily traced. There are three measures necessary to defend 903 against externally forged reports: 905 o Routers SHOULD NOT forward Receiver Membership Reports. This is 906 easier for a router to accomplish if the report carries the 907 Router-Alert option. 909 o Hosts SHOULD ignore Receiver Membership Reports without the 910 Router-Alert option. 912 Note that a remote attack through the multicast routing protocol is 913 possible. A remote site can originate join state for a large number 914 of groups that will propagate through MSNIP to the target source 915 host. Such attacks are considered a more significant problem for the 916 routers involved and are left up to the routing protocol security. 918 HOLD records in forged Receiver Membership Report messages are not a 919 significant threat as hosts track the individual interests of each 920 first-hop router separately. Only by forging the source address of 921 the report message so that is appears to have originated from a real 922 first-hop router can the attacker cause the source to stop 923 transmitting to a group that has valid receivers. Such forged 924 messages can be detected by the router itself. 926 12.2. Host Interest Solicitation Attacks 928 Forged Host Interest Solicitation messages can have two effects: 930 o When non-existent source addresses are used the solicitation 931 messages can create unwanted host record state on attached routers 932 for the duration of the holdtime specified in the message. 934 o When a source address corresponding to an existing host is used in 935 the forged HIS message, receipt of the message by attached routers 936 will cause them to transmit Receiver Membership Reports messages 937 for all MSNIP-managed multicast destination addresses with 938 receivers for the target host. Although no additional state will 939 be created in routers or hosts from this attack, bandwidth and CPU 940 is wasted in both the first-hop routers and the target host. 942 Just like for the Receiver Membership Report message, attacks using 943 the Host Interest Solicitation message can be reduced by requiring 944 the use of the Router-Alert option on the message. 946 12.3. MSNIP Managed Range Discovery 948 As discussed in [I-D.ietf-magma-mrdssm] it is possible for directly 949 connected systems to send forged Multicast Router Advertisement 950 messages containing the SSM Range Discovery option. As the SSM Range 951 Discovery option determines the MSNIP-managed range under IPv4, such 952 forged messages can temporarily replace the managed range map with 953 incorrect information in receiving hosts. An incorrect mapping can 954 have two effects: 956 o Applications using a multicast destination address within the real 957 SSM range that have no valid receivers can be tricked into 958 thinking that their chosen destination address is no longer an SSM 959 address and will therefore start transmitting data. 961 o Applications using group addresses outside the valid SSM range can 962 be tricked into thinking that they are using an SSM destination 963 address and therefore prevented from transmitting data. 965 The Multicast Router Discovery SSM Range Option specification 966 suggests that a router receiving a Multicast Router Advertisement 967 with an inconsistent SSM Range Option log the event to the operator. 968 Such logging will enable tracking of this type of attack. 970 13. IANA Considerations 972 This document introduces the following new types and options that 973 require allocation by IANA: 975 o Two new IGMP messages for Host Interest Solicitation and Receiver 976 Membership Report. Each of these messages requires a new IGMP 977 type value to be assigned by IANA [IGMPREG]. 979 o The new MSNIP Operation option for the Multicast Router Discovery 980 protocol. This option requires a new MRD type value to be 981 assigned by IANA. 983 o The new MSNIP Operation option for the Neighbour Discovery / 984 ICMPv6 protocol. This option requires a new NDP / ICMPv6 type 985 value to be assigned by IANA. 987 14. Acknowledgements 989 The authors would like to thank Dave Thaler, Jon Crowcroft, Toerless 990 Eckert, Haixiang He, Pekka Savola and Karen Kimball for their 991 contribution to this specification. 993 15. References 995 15.1. Normative References 997 [I-D.ietf-magma-mrdssm] 998 Kouvelas, I., "Multicast Router Discovery SSM Range 999 Option", draft-ietf-magma-mrdssm-03 (work in progress), 1000 June 2003. 1002 [RFC2113] Katz, D., "IP Router Alert Option", RFC 2113, 1003 February 1997. 1005 [RFC2711] Partridge, C. and A. Jackson, "IPv6 Router Alert Option", 1006 RFC 2711, October 1999. 1008 [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. 1009 Thyagarajan, "Internet Group Management Protocol, Version 1010 3", RFC 3376, October 2002. 1012 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1013 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1015 [RFC4286] Haberman, B. and J. Martin, "Multicast Router Discovery", 1016 RFC 4286, December 2005. 1018 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 1019 Message Protocol (ICMPv6) for the Internet Protocol 1020 Version 6 (IPv6) Specification", RFC 4443, March 2006. 1022 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 1023 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 1024 September 2007. 1026 15.2. Informative References 1028 [IGMPREG] IANA, "IGMP Type Numbers", IGMP TYPE NUMBERS - per 1029 RFC3228, 1030 BCP57 http://www.iana.org/assignments/igmp-type-numbers, 1031 June 2005. 1033 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 1034 Multicast Addresses", RFC 3306, August 2002. 1036 [RFC4601] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, 1037 "Protocol Independent Multicast - Sparse Mode (PIM-SM): 1038 Protocol Specification (Revised)", RFC 4601, August 2006. 1040 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 1041 "Internet Group Management Protocol (IGMP) / Multicast 1042 Listener Discovery (MLD)-Based Multicast Forwarding 1043 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 1045 [RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for 1046 IPv4 Multicast Address Assignments", BCP 51, RFC 5771, 1047 March 2010. 1049 Appendix A. Extending MSNIP to Any-Source Multicast 1051 This document defines MSNIP only for use with SSM. As noted in 1052 Section 2 many currently deployed multicast routing protocols require 1053 data from an active source to be propagated past the first-hop router 1054 before information on the existence of receivers becomes available on 1055 the first-hop. We will specify in Appendix A.1 how MSNIP can be 1056 extended to work for ASM when PIM-SM [RFC4601]) is used. 1058 Whether MSNIP can be used for ASM depends on the multicast routing 1059 protocols used. There may be different protocols used for different 1060 group addresses. Rather than requiring a host to know for which ASM 1061 groups MSNIP can be used, we suggest that the host can use it for all 1062 ASM groups. If the first-hop router is unable to determine whether 1063 there are receivers or not, it can tell the source that there are 1064 receivers present anyway. The host will then start sending and the 1065 behavior will be as if MSNIP is not used. If MSNIP is extended to 1066 ASM, one should consider adding a flag to the MSNIP Operation Option 1067 Section 4.1.1, or creating a new option for use with IPv4 in the 1068 Multicast Router Discovery protocol [RFC4286] and Neighbor Discovery 1069 / ICMPv6 protocol [RFC4861], in order to announced the router 1070 capability to the hosts. 1072 A.1. Extending MSNIP to ASM with PIM-SM 1074 When PIM-SM [RFC4601] is used to provide ASM service, a first-hop 1075 router will generally not know if there are receivers for a group 1076 until it starts receiving data from an active source. Until the 1077 source becomes active, receivers simply join the shared tree for the 1078 group. This allows the Rendezvous-Point (RP) for the group to learn 1079 that receivers are present. Next when a source becomes active, a 1080 first-hop router (the Designated Router (DR)) will be responsible for 1081 sending PIM register messages to the the RP. If there are receivers 1082 present, the RP and/or last-hop routers will join the Shortest Path 1083 Tree (SPT) towards the source. This will result in at least one 1084 first-hop router learning that a source exists. The last part is 1085 similar to when using PIM-SM for SSM. With SSM a last-hop router 1086 immediately joins the Shortest Path Tree (SPT). 1088 MSNIP can be extended to ASM with PIM-SM as follows: 1090 o Host Interest Solicitation Message (Section 8.1) need to be 1091 extended to include a list of groups that the host is interested 1092 in receiving membership reports for. 1094 o When a Designated Router (DR) receives a Host Interest 1095 Solicitiation Message with source address S containing a group G, 1096 it will periodically send PIM Null-Register messages to the RP for 1097 (S,G). This is done instead of the data PIM Register messages the 1098 DR would use if the source did not use MSNIP. Per the DR register 1099 state machine in section 4.4.1 of [RFC4601], one can immediately 1100 send a Null-Register and then move to Prune state as if a 1101 Register-Stop was received. When the Register-Stop timer expires, 1102 send a Null-Register as usual. But then, rather than setting the 1103 Register-Stop timer to Register_Probe_Time, transition directly to 1104 Prune state as if a Register-Stop was received again. By 1105 periodically receiving the (S,G) registers, the RP will know that 1106 a source exists, and will join the SPT towards the source if it 1107 has receivers. Just like SSM, a first-hop routers will then 1108 receive an SPT join for (S,G) and learn that there are receivers. 1109 It can then inform the source. If the first-hop router has 1110 (*,G)-state, e.g., local interest or it is part of the shared 1111 tree, but has not yet got an (S,G) olist, it must immediately 1112 inform the source. 1114 One benefit with this approach, is that PIM data registers can be 1115 avoided. 1117 Authors' Addresses 1119 Bill Fenner 1120 AT&T Labs--Research 1121 1 River Oaks Place 1122 San Jose, CA 95134 1123 USA 1125 Email: fenner@research.att.com 1127 Brian Haberman 1128 Johns Hopkins University Applied Physics Lab 1129 11100 Johns Hopkins Road 1130 Laurel, MD 20723-6099 1131 USA 1133 Email: brian@innovationslab.net 1135 Hugh Holbrook 1136 Arastra, Inc. 1137 P.O. Box 10905 1138 Palo Alto, CA 94303 1139 USA 1141 Email: holbrook@arastra.com 1143 Isidor Kouvelas 1144 cisco Systems 1145 Tasman Drive 1146 San Jose, CA 95134 1147 USA 1149 Email: kouvelas@cisco.com 1151 Stig Venaas 1152 cisco Systems 1153 Tasman Drive 1154 San Jose, CA 95134 1155 USA 1157 Email: stig@cisco.com