idnits 2.17.00 (12 Aug 2021) /tmp/idnits9496/draft-ietf-magma-msnip-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 51 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** 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 237: '...This option MUST be included in all Mu...' RFC 2119 keyword, line 255: '...ers on that link MUST be configured to...' RFC 2119 keyword, line 660: '...ustness Variable MUST NOT be zero, and...' RFC 2119 keyword, line 661: '... SHOULD NOT be one. Default: 2...' RFC 2119 keyword, line 670: '...state for. This MUST be ((the Robustn...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (21 February 2002) is 7394 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) -- Looks like a reference, but probably isn't: 'RFC-2113' on line 562 == Unused Reference: '2' is defined on line 733, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Obsolete normative reference: RFC 2401 (ref. '2') (Obsoleted by RFC 4301) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force MAGMA WG 2 INTERNET-DRAFT Bill Fenner/AT&T 3 draft-ietf-magma-msnip-00.txt Hugh Holbrook/Cisco 4 Isidor Kouvelas/Cisco 5 21 February 2002 6 Expires: August 2002 8 IPv4 Multicast Source Notification of Interest Protocol (MSNIP) 10 Status of this Document 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering Task 16 Force (IETF), its areas, and its working groups. Note that other groups 17 may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet- Drafts as reference material 22 or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This document is a product of the IETF MAGMA WG. Comments should be 31 addressed to the authors, or the WG's mailing list at 32 pim@catarina.usc.edu. 34 Abstract 36 This document discusses the Multicast Source Interest 37 Notification Protocol (MSNIP). MSNIP is an extension to 38 IGMPv3 that provides membership notification services for 39 sources of multicast traffic. 41 Table of Contents 43 1. Introduction. . . . . . . . . . . . . . . . . . . . . . 3 44 2. Routing Protocol Support. . . . . . . . . . . . . . . . 3 45 3. API for Requesting Membership Notification. . . . . . . 4 46 3.1. API Usage. . . . . . . . . . . . . . . . . . . . . . 5 47 4. MSNIP Managed Address Range Negotiation . . . . . . . . 5 48 4.1. Router Coordination. . . . . . . . . . . . . . . . . 6 49 4.1.1. MSNIP Operation Option. . . . . . . . . . . . . . 6 50 4.1.2. SSM Range Option. . . . . . . . . . . . . . . . . 7 51 4.2. Communicating Range to Source Systems. . . . . . . . 7 52 5. Requesting and Receiving Notifications. . . . . . . . . 8 53 5.1. Host Interest Solicitation . . . . . . . . . . . . . 8 54 5.2. Router Receiver Membership Reports . . . . . . . . . 9 55 6. Application Notification. . . . . . . . . . . . . . . . 10 56 7. Router Processing . . . . . . . . . . . . . . . . . . . 12 57 8. Message Formats . . . . . . . . . . . . . . . . . . . . 14 58 8.1. Interest Solicitation Packet . . . . . . . . . . . . 14 59 8.2. Receiver Membership Report Packet. . . . . . . . . . 15 60 9. Constants Timers and Default Values . . . . . . . . . . 17 61 10. Todo list... . . . . . . . . . . . . . . . . . . . . . 17 62 11. Acknowledgements . . . . . . . . . . . . . . . . . . . 18 63 12. Authors' Addresses . . . . . . . . . . . . . . . . . . 18 64 13. References . . . . . . . . . . . . . . . . . . . . . . 19 66 1. Introduction 68 The Multicast Source Notification of Interest Protocol (MSNIP) is 69 an extension to version 3 of the Internet Group Membership Protocol 70 (IGMPv3 [1] ). MSNIP operates between multicast sources and their first- 71 hop routers to provide information on the presence of receivers to the 72 source systems. Using the services offered by MSNIP an application on an 73 IP system wishing to source multicast data can register to be notified 74 when receivers join and leave the session. This enables multicast 75 sources to avoid the work of transmitting packets onto their first-hop 76 link when there are no joined receivers. 78 A common scenario where MSNIP may be useful is one where there is a 79 multicast server offering a large pool of potential flows that map onto 80 separate multicast destination addresses but receivers exist only for a 81 small subset of the flows. If the source were to continuously transmit 82 data for all the flows that could potentially have receivers, 83 significant resources would be wasted in the system itself as well as 84 the first-hop link. Using a higher level control protocol to determine 85 the existence of receivers for particular flows may not be practical as 86 there may be many potential receivers in each active session. 88 Information on which multicast destination addresses have receivers 89 for a particular sender is typically available to the multicast routing 90 protocol on the first hop router for a source. MSNIP uses this 91 information to notify the application in the sending system of when it 92 should start or stop transmitting. This is achieved without any 93 destination address specific state on the first-hop router for potential 94 sources without receivers. 96 2. Routing Protocol Support 98 For reasons described in this section, MSNIP only supports 99 transmission control for applications that use multicast destination 100 addresses that are routed using Source Specific Multicast (SSM). 102 Many currently deployed multicast routing protocols, require data 103 from an active source to be propagated past the first-hop router before 104 information on the existence of receivers becomes available on the 105 first-hop. In addition, such protocols require that this activity is 106 repeated periodically to maintain source liveness state on remote 107 routers. All dense-mode protocols fall under this category as well as 108 sparse-mode protocols that use shared trees for source discovery (such 109 as PIM-SM [3] ). In order to provide receiver interest notification for 110 such protocols, the default mode of operation would require that the 111 source IP system periodically transmits on all potential destination 112 addresses and the first-hop routers prune the traffic back. Such a 113 flood-and-prune behaviour on the first-hop link significantly diminishes 114 the benefits of managing source transmission. 116 In contrast, with source-specific sparse-mode protocols such as 117 PIM-SSM [3] availability of receiver membership information on the 118 first-hop routers is independent of data transmission. Such protocols 119 use an external mechanism for source discovery (like source-specific 120 IGMPv3 membership reports) to build source-specific multicast trees. 122 Clearly these two classes of routing protocols require different 123 handling for the problem MSNIP is trying to solve. In addition the 124 second type covers the majority of applications that MSNIP is targeted 125 at. MSNIP avoids the extra complication in supporting routing protocols 126 that require a flood and prune behaviour. 128 3. API for Requesting Membership Notification 130 Applications within an IP system that wish to source multicast 131 packets and are interested in being notified on the existence of 132 receivers must register with the IP layer of the system. MSNIP requires 133 that within the IP system, there is (at least conceptually) an 134 Application Programming Interface or API that can be used to register 135 with the IP layer for such notifications. A system's IP API must support 136 the following operation or any logical equivalent: 138 IPMulticastsSourceRegister (socket, source-address, multicast-address) 139 IPMulticastsSourceDeregister (socket, source-address, multicast-address) 141 In addition the application must provide the following API for 142 receiving notifications from the IP system: 144 IPMulticastSourceStart (socket, source-address, multicast-address) 145 IPMulticastSourceStop (socket, source-address, multicast-address) 147 where: 149 socket 150 is an implementation-specific parameter used to distinguish amongst 151 different requesting entities (e.g., programs or processes) within 152 the system; the socket parameter of BSD Unix system calls is a 153 specific example. 155 source-address 156 is the IP unicast source address that the application wishes to use 157 in transmitting data to the specified multicast address. The 158 specified address must be one of the IP addresses associated with 159 the network interfaces of the IP system. Note that an interface in 160 an IP system may be associated with more than one IP addresses. An 161 implementation may allow a special "unspecified" value to be passed 162 as the source-address parameter, in which case the request would 163 apply to the "primary" IP address of the "primary" or "default" 164 interface of the system (perhaps established by system 165 configuration). If transmission to the same multicast address is 166 desired using more than one source IP address, 167 IPMulticastSourceRegister is invoked separately for each desired 168 source address. 170 multicast-address 171 is the IP multicast destination address to which the request 172 pertains. If the application wishes to transmit data to more than 173 one multicast addresses for a given source address, 174 IPMulticastSourceRegister is invoked separately for each desired 175 multicast address. 177 3.1. API Usage 179 Applications wishing to use MSNIP to control their multicast data 180 transmission to destination G from source address S operate as follows. 182 Initially the application contacts the IP system to obtain the 183 socket handle for use on all subsequent interactions. The application 184 invokes IPMulticastSourceRegister for the desired S and G and then waits 185 without transmitting any packets for the IP system to notify that 186 receivers for the session exist. 188 If and when the IP system notifies the application that receivers 189 exist using the IPMulticastSourceStart call, the application may start 190 transmitting data. After the application has been notified to send, if 191 all receivers for the session leave, the IP system will notify the 192 application using the IPMulticastSourceStop call. At this point the 193 application should stop transmitting data until it is notified again 194 that receivers have joined through another IPMulticastSourceStart call. 196 When the application no longer wishes to transmit data it should 197 invoke the IPMulticastsSourceDeregister call to let the IP system know 198 that it is no longer interested in notifications for this source and 199 destination. The IPMulticastsSourceDeregister call should be implicit in 200 the teardown of the associated socket state. 202 4. MSNIP Managed Address Range Negotiation 204 With current multicast deployment in the Internet, different 205 multicast routing protocols coexist and operate under separate parts of 206 the multicast address space. Multicast routers are consistently 207 configured with information that maps specific multicast address ranges 208 to multicast routing protocols. Part of this configuration describes the 209 subset of the address space that is used by source-specific multicast 210 (SSM) [4]. As described in section 2 MSNIP only tries to control 211 application transmission within the SSM address range. 213 It is desirable for applications within an IP system that supports 214 MSNIP to have a consistent API for multicast transmission that does 215 require the application to be aware of the SSM address range. MSNIP 216 supports this by allowing applications to use the API described in 217 section 3 for multicast destination addresses that are outside its 218 operating range. When an application registers for notifications for a 219 destination address that is not managed by MSNIP it is immediately 220 notified to start transmitting. This complies with the default behaviour 221 of IP multicast without MSNIP support which forces multicast 222 applications to assume that there are multicast receivers present in the 223 network. 225 4.1. Router Coordination 227 In order for MSNIP to operate on a shared link where more than one 228 multicast routers may be present all multicast routers must be MSNIP 229 capable and have a consistent configuration for the SSM address range. 230 MSNIP enforces these requirements by using two new options in the IGMP 231 Multicast Router Discovery protocol [5]. 233 4.1.1. MSNIP Operation Option 235 A multicast router advertises that it is participating in MSNIP 236 using the MSNIP Operation Multicast Router Discovery protocol option. 237 This option MUST be included in all Multicast Router Advertisement 238 messages of a router that is configured for MSNIP. The format of the 239 option is as follows: 241 0 1 2 3 242 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 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | Type=X | Length=0 | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 A multicast router uses received Multicast Router Advertisement 248 messages to determine if all live neighbour multicast routers on each 249 interface are participating in MSNIP. When a Multicast Router 250 Advertisement message not containing an MSNIP option is received by a 251 router participating in MSNIP, a miss-configuration should be logged to 252 the operation in a rate-limited manner. 254 If even one multicast router on a link does not have MSNIP capability 255 then ALL routers on that link MUST be configured to not provide MSNIP 256 services and to not advertise the MSNIP Operation option. 258 4.1.2. SSM Range Option 260 The SSM Range Multicast Router Discover option advertises the SSM 261 Range with which the router is configured. The option is defined in [7]. 263 4.2. Communicating Range to Source Systems 265 When an application in an IP system uses the MSNIP API to register 266 for notification, the IP system must behave differently depending on 267 whether or not the destination address for which the application 268 registered is operating under SSM (and is being managed by MSNIP). For 269 SSM channels, the IP system should only instruct the application to 270 transmit when there are receivers for the multicast destination. For 271 non-SSM destination addresses the IP system will not be able to 272 determine if there are receivers and should immediately instruct the 273 application to transmit. 275 The MSNIP managed range discovery mechanism in a source IP system 276 has to deal with three different link configurations: 278 o A link connected to a multicast routed infrastructure where the first- 279 hop multicast routers are configured for MSNIP operation. 281 o A link connected to a multicast routed infrastructure where the first- 282 hop multicast routers are not participating in MSNIP. 284 o A link with no multicast routers. 286 To be able to differentiate between the three cases and in each 287 case discover the MSNIP managed range an MSNIP capable source IP system 288 must process IGMP Queries as well as Multicast Router Discovery 289 Advertisement messages. The presence of an IGMP querier differentiates 290 between the first two cases, where the host is in a multicast routed 291 network, and the third, where there is no multicast routing. 293 Multicast Router Discovery Advertisements provide the 294 differentiation between the first two cases. If the MRD Advertisements 295 contain the MSNIP Operation option then the IP system knows that routers 296 on that interface are configured for MSNIP operation. 298 In each of the three cases the MSNIP managed range is defined as 299 follows: 301 MSNIP capable multicast routers: 302 The IP system should use as the MSNIP range the SSM range provided 303 by the last SSM Range option [7] received in a Multicast Router 304 Discovery message. 306 Multicast routers not participating in MSNIP: 307 The IP system should use an empty MSNIP managed range. This 308 provides a compatibility mode where all group ranges default to 309 flooding. 311 Link without multicast routing: 312 The IP system should use as the MSNIP managed range the default SSM 313 range of 232/8 defined in [6]. This allows directly connected 314 receivers to perform the router side of the MSNIP protocol and 315 control the source transmission within the default SSM range. 317 5. Requesting and Receiving Notifications 319 Like IGMP, MSNIP is an asymmetric protocol specifying different 320 behaviours for systems wishing to source traffic and for multicast 321 routers. Host IP systems multicast Host Interest Solicitation messages 322 to register for notification with their first-hop routers. Routers 323 unicast Router Receiver Membership Reports to IP system to notify them 324 of the arrival of the first or departure of the last receivers for a 325 session. Note that a system may perform at the same time both of the 326 above functions. An example is a router that wishes to source traffic. 328 5.1. Host Interest Solicitation 330 Source systems that wish to be managed by MSNIP periodically 331 transmit an Interest Solicitation message. This message is multicast 332 with a multicast destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) 333 and is transmitted every [Interest Solicitation Interval] seconds. The 334 Interest Solicitation message contains a holdtime which is set to 335 [Interest Solicitation Holdtime] and instructs the multicast first-hop 336 routers to maintain MSNIP state for this IP system for the specified 337 period. A generation ID is also included in the Interest Solicitation 338 message to provide support for routers to detect IP system crashes (see 339 section 8.1). 341 When an IP system first comes up it transmits [Robustness Variable] 342 Interest Solicitation messages randomly spaced over [Initial Interest 343 Solicitation Interval] seconds. 345 All MSNIP capable routers that receive an Interest Solicitation 346 message from an IP system, maintain a system interest record of the 347 form: 349 (IP system address, holdtime timer) 351 Each time an Interest Solicitation message is received from the IP 352 system, the holdtime timer is reset to the holdtime in the received 353 message. In addition the router responds to the solicitation message 354 with a Receiver Membership Report message described in section 5.2. The 355 message contains a TRANSMIT record for each of the multicast destination 356 addresses within the MSNIP managed range for which the routing protocol 357 indicates there are receivers for this source system. 359 When the holdtime timer of a specific system interest record 360 expires, the record is deleted. 362 5.2. Router Receiver Membership Reports 364 Receiver Membership Report messages are used by routers to 365 communicate the receiver membership status of particular multicast 366 destination addresses to a specific IP system. Each message contains a 367 list of transmission control records of either TRANSMIT or HOLD type 368 that instruct a system to respectively start or stop sending traffic on 369 this link to the specified multicast destination address. Receiver 370 Membership Report messages are unicast to the target system. 372 In addition to the receipt of an Interest Solicitation message, 373 routers send unsolicited Receiver Membership Reports to IP systems when 374 the receiver membership status reported by the multicast routing 375 protocol changes for a specific source and multicast destination. Such 376 reports are only sent if the destination address is managed by MSNIP and 377 the router has a system interest record created by a previously received 378 Interest Solicitation message with a IP system address equal to the 379 source address. If the source destination pair satisfy these conditions 380 then [Robustness Variable] Receiver Membership Reports are sent out 381 within [Unsolicited Membership Report Interval] seconds. If during the 382 [Unsolicited Membership Report Interval] an additional membership change 383 occurs for the same destination address and source system, transmission 384 of any related pending Receiver Membership Report messages is cancelled 385 and a new set of [Robustness Variable] messages is scheduled. 387 When an IP system receives a Receiver Membership Report message, 388 for each of the TRANSMIT records listed in the message it creates or 389 updates a transmission record of the form: 391 (router address, source address, multicast address, holdtime timer) 393 The router address is obtained from the source address on the IP header 394 of the received message. The source address is obtained from the 395 destination address in the of the IP header. The holdtime timer is set 396 to [Interest Solicitation Holdtime] seconds. 398 For each HOLD record present in the message, the system deletes the 399 matching previously created transmission record from its state. 401 Note that creation and deletion of transmission records in an IP 402 systems state may cause local applications to be notified to start and 403 stop transmitting data (see section 6). 405 6. Application Notification 407 This section describes the relation between protocol events and 408 notifications to source applications within an IP system. The state 409 machine below is specific to each source address of the IP system and 410 each multicast destination address. The initial state is the No Info 411 state. 413 +-----------------------------------+ 414 | Figures omitted from text version | 415 +-----------------------------------+ 417 Figure 1: Per source-address (S) and multicast destination address (G) state 418 machine at an IP system 420 In tabular form, the state-machine is: 422 +-----------+-----------------------------------------------------------+ 423 | | Event | 424 | +----------+-----------+------------+-----------+-----------+ 425 |Prev State |New |Start |Stop |Recv |Recv last | 426 | |Register |Manage |Manage |TRANSMIT |HOLD or | 427 | | | | | |timeout | 428 +-----------+----------+-----------+------------+-----------+-----------+ 429 | |Start new |-> Hold |- |- |- | 430 |No Info | |Stop ALL | | | | 431 | | |registered | | | | 432 +-----------+----------+-----------+------------+-----------+-----------+ 433 | |- |- |-> No Info |-> |- | 434 |Hold | | | |Transmit | | 435 | | | |Stop ALL |Start ALL | | 436 | | | |registered |registered | | 437 +-----------+----------+-----------+------------+-----------+-----------+ 438 | |Start new |- |-> No Info |- |-> Hold | 439 |Transmit | | | | |Stop ALL | 440 | | | | | |registered | 441 +-----------+----------+-----------+------------+-----------+-----------+ 443 The events in state machine above have the following meaning: 445 New register 446 A new application has registered through a call to 447 IPMulticastsSourceRegister for this S and G. 449 Start manage 450 We received a SSM Range option in an MRD packet on the interface 451 that S belongs to that changed the status of G from a non-managed 452 to a MSNIP managed destination address. 454 Stop manage 455 We received a SSM Range option in an MRD packet on the interface 456 that S belongs to that changed the status of G from a MSNIP managed 457 to a non-managed destination address or the mapping state that 458 caused this destination address to be managed expired. 460 Receive TRANSMIT 461 We received a Receiver Membership Report with S as the IP 462 destination address that contains a TRANSMIT record for G. 464 Receive last HOLD or timeout 465 We either received a Receiver Membership Report with S as the IP 466 destination address that contains a HOLD record for G or a TRANSMIT 467 record for S and G expired and there are no other TRANSMIT records 468 for S and G. This means that the last router that was reporting 469 receivers no longer does so and there are no routers left wishing 470 to receive traffic from this S to destination address G. 472 The state machine actions have the following meaning: 474 Start new 475 Send an IPMulticastSourceStart notification to the application that 476 just registered for this S and G. 478 Start ALL registered 479 Send an IPMulticastSourceStart notification to all applications 480 that are registered for this S and G. 482 Stop ALL registered 483 Send an IPMulticastSourceStop notification to all applications that 484 are registered for this S and G. 486 7. Router Processing 488 This section describes the per-source system tracking state machine 489 operated by each first-hop router. The initial state is No Info. 491 +-----------------------------------+ 492 | Figures omitted from text version | 493 +-----------------------------------+ 495 Figure 2: Per IP source system (S) state machine at a router 497 In tabular form, the state-machine is: 499 +------------+----------------------------------------------------------+ 500 | | Event | 501 | +------------+-----------+--------------+------------------+ 502 |Prev State | Receive | HIS | Receivers | Receivers | 503 | | HIS | timeout | for new | of G leave | 504 | | | | destination | | 505 | | | | G | | 506 +------------+------------+-----------+--------------+------------------+ 507 | | -> | - | - | - | 508 | | Tracking | | | | 509 | | Set HT to | | | | 510 |Not | message | | | | 511 |tracking | holdtime | | | | 512 | | Send ALL | | | | 513 | | existing | | | | 514 | | TRANSMITs | | | | 515 +------------+------------+-----------+--------------+------------------+ 516 |Tracking | Set HT to | -> Not | Send | Send HOLD | 517 | | message | tracking | TRANSMIT | for G | 518 | | holdtime | | for G | | 519 +------------+------------+-----------+--------------+------------------+ 521 The events in state machine above have the following meaning: 523 Receive HIS 524 The router has received a Host Interest Solicitation from S. 526 HIS timeout 527 The holdtime timer (HT) associated with S has expired. 529 Receivers for new destination G 530 The routing protocol has informed MSNIP that it now has receivers 531 for the MSNIP managed destination address G and source IP system S. 533 Receivers of G leave 534 The routing protocol has informed MSNIP that all receivers for the 535 MSNIP managed destination address G and source IP system S have 536 left the channel. 538 The state machine actions have the following meaning: 540 Set HT to message holdtime 541 The holdtime timer associated with S is restarted to the value of 542 the holdtime in the received Host Interest Solicitation message. 544 Send ALL existing TRANSMITs 545 The router builds and transmits Receiver Membership Reports to S 546 that contain a TRANSMIT record for each of the MSNIP managed 547 destination addresses that have receivers for S. 549 Send TRANSMIT for G 550 The router builds and transmits a Receiver Membership Report to S 551 that contains a TRANSMIT record for the destination address G. 553 Send HOLD for G 554 The router builds and transmits a Receiver Membership Report to S 555 that contains a HOLD record for the destination address G. 557 8. Message Formats 559 Like all other IGMP messages, MSNIP messages are encapsulated in 560 IPv4 datagrams, with an IP protocol number of 2. Every MSNIP message 561 described in this document is sent with an IP Time-to-Live of 1, and 562 carries an IP Router Alert option [RFC-2113] in its IP header. 564 There are two IGMP message types of concern to the MSNIP protocol 565 described in this document: 567 +-------------------+----------------------------+ 568 | Type Number (hex) | Message Name | 569 +-------------------+----------------------------+ 570 | 0x23 | Interest Solicitation | 571 +-------------------+----------------------------+ 572 | 0x24 | Receiver Membership Report | 573 +-------------------+----------------------------+ 575 8.1. Interest Solicitation Packet 577 A Interest Solicitation packet is periodically multicast by MSNIP 578 capable systems to declare interest in Receiver Membership Reports from 579 multicast routers on the link. The Interest Solicitation message is 580 multicast with a destination address of ALL_IGMPv3_ROUTERS (224.0.0.22). 582 0 1 2 3 583 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 584 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 585 | Type = 0x24 | Reserved | Checksum | 586 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 587 | Holdtime | GenID | 588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 Reserved 591 Transmitted as zero. Ignored upon receipt. 593 Checksum 594 Calculated as for Range Map packet. 596 Holdtime 597 The amount of time a receiving router must keep the system interest 598 state alive, in seconds. 600 GenID 601 Generation ID of the IP system. A number that is selected randomly 602 for each of the [Robustness Variable] initial Interest Solicitation 603 messages when the system comes up and afterwards remains fixed to 604 the value used in the last of the initial messages throughout the 605 system lifetime. The GenID is used by routers to detect system 606 crashes. 608 8.2. Receiver Membership Report Packet 610 A Receiver Membership Report packet is unicast by first-hop multicast 611 routers and targeted at potential sources to inform them of the 612 existence or not of receivers for the listed multicast destination 613 addresses. 615 0 1 2 3 616 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 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 618 | Type = 0x25 | Dest Count | Checksum | 619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 620 | Record-Type-1 | Reserved | 621 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 | Destination-Address-1 | 623 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 624 | . | 625 | . | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 Dest Count 629 The number of multicast destination address records present in this 630 message. 632 Checksum 633 Calculated as for Range Map packet. 635 Record-Type-1 636 The type of the first transmission control record in this message. 637 Valid values are: 639 +-------------+----------------------------------------------+-------+ 640 | Record Type | Description | Value | 641 +-------------+----------------------------------------------+-------+ 642 | TRANSMIT | Request to start transmitting to destination | 1 | 643 +-------------+----------------------------------------------+-------+ 644 | HOLD | Request to stop transmitting to destination | 2 | 645 +-------------+----------------------------------------------+-------+ 647 Reserved 648 Transmitted as zero. Ignored upon receipt. 650 Destination-Address-1 651 The multicast destination address of the first record in the 652 message. 654 9. Constants Timers and Default Values 656 Robustness Variable 657 The Robustness Variable allows tuning for the expected packet loss 658 on a network. If a network is expected to be lossy, the Robustness 659 Variable may be increased. MSNIP is robust to (Robustness Variable 660 - 1) packet losses. The Robustness Variable MUST NOT be zero, and 661 SHOULD NOT be one. Default: 2 663 Interest Solicitation Interval 664 The interval used by MSNIP capable systems between transmissions of 665 Interest Solicitation messages. Default: 60 secs 667 Interest Solicitation Holdtime 668 The interval inserted in Interest Solicitation messages by systems 669 to instruct routers how long they should maintain system interest 670 state for. This MUST be ((the Robustness Variable) times (the 671 Interest Solicitation Interval) plus (one second)). 673 Initial Interest Solicitation Interval 674 The interval used by systems to send out the initial Interest 675 Solicitation messages when they first come up. Default: 1 second. 677 Unsolicited Membership Report Interval 678 The interval used by routers to send out a set of Membership Report 679 messages when the receiver membership changes for a specific 680 system. Default: 1 second. 682 10. Todo list... 684 o Add security considerations section. 686 o If application ignores or does not ask for notification in managed 687 range host OS should filter packets. 689 o Maybe provide masks for registration / notification API. 691 o When we hear out-of-order IGMP query resend interest registration. 693 o Only send interest registration when application is interested. This 694 is not possible if we do host filtering... 696 o Maybe add API to ask the kernel for the state of a particular 697 destination. bool IpMulticastSourceHasInterest (socket, source- 698 address, multicast-address). 700 o Add GenID changes to router FSM. 702 11. Acknowledgements 704 The authors would like to thank Dave Thaler and Jon Crowcroft for their 705 contribution to this specification. 707 12. Authors' Addresses 709 Bill Fenner 710 AT&T Labs - Research 711 75 Willow Road 712 Menlo Park, CA 94025 713 fenner@research.att.com 715 Hugh Holbrook 716 Cisco Systems 717 170 W. Tasman Drive 718 San Jose, CA 95134 719 holbrook@cisco.com 721 Isidor Kouvelas 722 Cisco Systems 723 170 W. Tasman Drive 724 San Jose, CA 95134 725 kouvelas@cisco.com 727 13. References 729 [1] B. Cain, S Deering, W. Fenner, I Kouvelas, A. Thyagarajan, "Internet 730 Group Management Protocol, Version 3", Work In Progress, , 2000. 733 [2] S. Kent, R. Atkinson, "Security Architecture for the Internet 734 Protocol.", RFC 2401. 736 [3] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 737 Independent Multicast - Sparse Mode (PIM-SM): Protocol 738 Specification (Revised)", Work In Progress, , 2002. 741 [4] Z. Albanna, K. Almeroth, D. Meyer, "IANA Guidelines for IPv4 742 Multicast Address Allocation", Best Current Practices, , 2001. 745 [5] S. Biswas, B. Haberman, "IGMP Multicast Router Discovery", Work In 746 Progress, , 2001. 748 [6] H. Holbrook, B. Cain, "Source-Specific Multicast for IP", work in 749 progress, , 21 November 2001. 751 [7] I. Kouvelas, "Multicast Router Discovery SSM Range Option", work in 752 progress, , February 2002.