idnits 2.17.1 draft-ietf-idmr-msnip-01.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 abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 255: '...Discovery option SHOULD be included in...' RFC 2119 keyword, line 703: '...ts, the checksum MUST be verified befo...' RFC 2119 keyword, line 806: '...ustness Variable MUST NOT be zero, and...' RFC 2119 keyword, line 807: '... SHOULD NOT be one. Default: 2...' RFC 2119 keyword, line 816: '...ime it out. This MUST be ((the Robustn...' (1 more instance...) 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 November 2001) is 8186 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 654 == Unused Reference: '2' is defined on line 893, 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' Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force IDMR WG 2 INTERNET-DRAFT Bill Fenner/AT&T 3 draft-ietf-idmr-msnip-01.txt Hugh Holbrook/Cisco 4 Isidor Kouvelas/Cisco 5 21 November 2001 6 Expires: May 2002 8 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 IDMR 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 [1] 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 4. MSNIP Managed Address Range Negotiation . . . . . . . . 5 47 4.1. Router Coordination. . . . . . . . . . . . . . . . . 6 48 4.1.1. MSNIP Capability Discovery Option . . . . . . . . 6 49 4.1.2. SSM Range Discovery Option. . . . . . . . . . . . 7 50 4.2. Communicating Range to Source Systems. . . . . . . . 7 51 4.2.1. MSNIP Range Map Messages. . . . . . . . . . . . . 8 52 5. Requesting and Receiving Notifications. . . . . . . . . 9 53 5.1. Host Interest Solicitation . . . . . . . . . . . . . 10 54 5.2. Router Receiver Membership Reports . . . . . . . . . 10 55 6. Routerless Operation. . . . . . . . . . . . . . . . . . 11 56 7. Application Notification. . . . . . . . . . . . . . . . 12 57 8. Router Processing . . . . . . . . . . . . . . . . . . . 14 58 9. Message Formats . . . . . . . . . . . . . . . . . . . . 16 59 9.1. Range Map Packet . . . . . . . . . . . . . . . . . . 16 60 9.2. Interest Solicitation Packet . . . . . . . . . . . . 18 61 9.3. Receiver Membership Report Packet. . . . . . . . . . 19 62 10. Constants Timers and Default Values. . . . . . . . . . 20 63 11. Todo list... . . . . . . . . . . . . . . . . . . . . . 21 64 12. Acknowledgements . . . . . . . . . . . . . . . . . . . 21 65 13. Authors' Addresses . . . . . . . . . . . . . . . . . . 21 66 14. References . . . . . . . . . . . . . . . . . . . . . . 22 68 1. Introduction 70 The Multicast Source Notification of Interest Protocol (MSNIP) is 71 an extension to version 3 of the Internet Group Membership Protocol 72 (IGMPv3 [1] ). MSNIP operates between multicast sources and their first- 73 hop routers to provide information on the presence of receivers to the 74 source systems. Using the services offered by MSNIP an application on an 75 IP system wishing to source multicast data can register to be notified 76 when receivers join and leave the session. This enables multicast 77 sources to avoid the work of transmitting packets onto their first-hop 78 link when there are no joined receivers. 80 A common scenario where MSNIP may be useful is one where there is a 81 multicast server offering a large pool of potential flows that map onto 82 separate multicast destination addresses but receivers exist only for a 83 small subset of the flows. If the source were to continuously transmit 84 data for all the flows that could potentially have receivers, 85 significant resources would be wasted in the system itself as well as 86 the first-hop link. Using a higher level control protocol to determine 87 the existence of receivers for particular flows may not be practical as 88 there may be many potential receivers in each active session. 90 Information on which multicast destination addresses have receivers 91 for a particular sender is typically available to the multicast routing 92 protocol on the first hop router for a source. MSNIP uses this 93 information to notify the application in the sending system of when it 94 should start or stop transmitting. This is achieved without any 95 destination address specific state on the first-hop router for potential 96 sources without receivers. 98 2. Routing Protocol Support 100 For reasons described in this section, MSNIP only supports 101 transmission control for applications that use multicast destination 102 addresses that are routed using Source Specific Multicast (SSM). 104 Many currently deployed multicast routing protocols, require data 105 from an active source to be propagated past the first-hop router before 106 information on the existence of receivers becomes available on the 107 first-hop. In addition, such protocols require that this activity is 108 repeated periodically to maintain source liveness state on remote 109 routers. All dense-mode protocols fall under this category as well as 110 sparse-mode protocols that use shared trees for source discovery (such 111 as PIM-SM [3] ). In order to provide receiver interest notification for 112 such protocols, the default mode of operation would require that the 113 source IP system periodically transmits on all potential destination 114 addresses and the first-hop routers prune the traffic back. Such a 115 flood-and-prune behaviour on the first-hop link significantly diminishes 116 the benefits of managing source transmission. 118 In contrast, with source-specific sparse-mode protocols such as 119 PIM-SSM [3] availability of receiver membership information on the 120 first-hop routers is independent of data transmission. Such protocols 121 use an external mechanism for source discovery (like source-specific 122 IGMPv3 membership reports) to build source-specific multicast trees. 124 Clearly these two classes of routing protocols require different 125 handling for the problem MSNIP is trying to solve. In addition the 126 second type covers the majority of applications that MSNIP is targeted 127 at. MSNIP avoids the extra complication in supporting routing protocols 128 that require a flood and prune behaviour. 130 3. API for Requesting Membership Notification 132 Applications within an IP system that wish to source multicast 133 packets and are interested in being notified on the existence of 134 receivers must register with the IP layer of the system. MSNIP requires 135 that within the IP system, there is (at least conceptually) an 136 Application Programming Interface or API that can be used to register 137 with the IP layer for such notifications. A system's IP API must support 138 the following operation or any logical equivalent: 140 IPMulticastsSourceRegister (socket, source-address, multicast-address) 141 IPMulticastsSourceDeregister (socket, source-address, multicast-address) 143 In addition the application must provide the following API for 144 receiving notifications from the IP system: 146 IPMulticastSourceStart (socket, source-address, multicast-address) 147 IPMulticastSourceStop (socket, source-address, multicast-address) 149 where: 151 socket 152 is an implementation-specific parameter used to distinguish among 153 different requesting entities (e.g., programs or processes) within 154 the system; the socket parameter of BSD Unix system calls is a 155 specific example. 157 source-address 158 is the IP unicast source address that the application wishes to use 159 in transmitting data to the specified multicast address. The 160 specified address must be one of the IP addresses associated with 161 the network interfaces of the IP system. Note that an interface in 162 an IP system may be associated with more than one IP addresses. An 163 implementation may allow a special "unspecified" value to be passed 164 as the source-address parameter, in which case the request would 165 apply to the "primary" IP address of the "primary" or "default" 166 interface of the system (perhaps established by system 167 configuration). If transmission to the same multicast address is 168 desired using more than one source IP address, 169 IPMulticastSourceRegister is invoked separately for each desired 170 source address. 172 multicast-address 173 is the IP multicast destination address to which the request 174 pertains. If the application wishes to transmit data to more than 175 one multicast address for a given source address, 176 IPMulticastSourceRegister is invoked separately for each desired 177 multicast address. 179 Applications wising 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 Capability Discovery Option 235 A multicast router advertises that it is MSNIP capable using the 236 MSNIP Capable Multicast Router Discovery protocol option. This option 237 MUST be included in all Multicast Router Advertisement messages. The 238 format of the option is as follows: 240 0 1 2 3 241 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 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Type=X | Length=0 | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 A multicast router uses received Multicast Router Advertisement 247 messages to determine if all live neighbour multicast routers on each 248 interface are MSNIP capable. If even one multicast router on a given 249 interface does not advertise the MSNIP Capable option in its Multicast 250 Router Advertisement messages then the interface is not considered as 251 MSNIP capable. 253 4.1.2. SSM Range Discovery Option 255 The SSM Range Discovery option SHOULD be included in all Multicast 256 Router Advertisement messages. It contains the list of multicast 257 destination address ranges that are configured to operate under source 258 specific multicast on this router. Note that the maximum length of a 259 Multicast Router Discovery option limits the number of ranges to 50 (Is 260 this an issue?). The format of the option is as follows: 262 0 1 2 3 263 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 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Type=Y | Length=var | Mask-Len-1 | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Destination-Prefix-1 | Mask-Len-2 | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 | Destination-Prefix-2 | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | ... | 273 Length 274 The length of the SSM Range Discovery option is variable and is 275 equal to five times the number of destination ranges present in the 276 option. 278 Destination-Prefix-n 279 The multicast destination address prefix of nth range present in 280 this option. 282 Mask-Len-n 283 The mask length for the nth address range. 285 A router receiving a Multicast Router Discovery message with an SSM 286 Range Discovery Option must compare the contents of the option with the 287 multicast address ranges ranges in the local SSM configuration and 288 signal any differences to the administrator. 290 4.2. Communicating Range to Source Systems 292 When an application in an IP system uses the MSNIP API to register 293 for notification, the IP system must behave differently depending on 294 whether or not the destination address for which the application 295 registered is operating under SSM. For SSM channels, the IP system 296 should only instruct the application to transmit when there are 297 receivers for the multicast destination. For non-SSM destination 298 addresses the IP system will not be able to determine if there are 299 receivers and should immediately instruct the application to transmit. 301 To be able to differentiate between SSM and non-SSM multicast 302 destination addresses a source IP system must know the SSM range which 303 is configured on the first-hop routers. One method for an IP system to 304 discover the SSM range would be to listen to Multicast Router 305 Advertisement messages and use the information in the SSM Range option. 306 However, as currently specified, IGMP Multicast Router Discovery 307 messages are sent to the ALL-Routers (224.0.0.2) multicast destination 308 address to which host IP systems do not normally subscribe. 310 Three options are under consideration for the mechanism to distribute 311 the MSNIP managed range (SSM range) to host IP systems: 313 o Make hosts listen to the ALL-Routers multicast destination for IGMP 314 Multicast Router Discovery messages. 316 o Use a separate MSNIP control message and nominate a router as 317 responsible for communicating the range to hosts. This option is 318 presented in more detail below using the IGMP querier as the router 319 responsible for distributing the MSNIP / SSM range. 321 o Do not use the IGMP Multicast Router Discovery SSM Range option to 322 distribute the information between routers. Instead use an MSNIP 323 message that hosts receive as well. Note that such a separate 324 mechanism would not have the size limitations of the router discovery 325 option. 327 4.2.1. MSNIP Range Map Messages 329 This section describes the option of using a separate MSNIP control 330 message for communicating the SSM multicast address range to host IP 331 systems. Communicating the range is left up to the IGMP querying 332 router. The querier periodically multicasts a MSNIP Range Map message 333 containing the definition of the address ranges over which MSNIP 334 operates. The destination of the Range Map message is the ALL-SYSTEMS 335 multicast address. The Range Map message is sent every [Range Map 336 Interval] seconds. The message also contains a holdtime which is set to 337 [Range Map Holdtime] and instructs IP systems to maintain the range 338 mapping state for the specified holdtime. 340 In addition to the periodic transmission, triggered Range Map messages 341 are sent when either: 343 o the IGMP querier on a link receives an Interest Solicitation message 344 (described in section 5.1 ) from an IP system that was not previously 345 registered with MSNIP or was registered with a different GenID (see 346 section 9.2 ). 348 o the configured SSM address range on the querier changes. 350 When either of these two events occur the querier initiates transmission 351 of a set of [Robustness Variable] Range Map messages. 353 Upon receipt of a Range Map message, an IP system builds or updates 354 a set of range records as follows. For each multicast address range 355 present in the message, the system either creates or updates a record of 356 the form: 358 (interface, range prefix, range mask) 360 Where interface is the interface the Range Map message was received on 361 and prefix and mask are the definition of the address range. If range 362 records which were created by a previous Range Map message received on 363 this interface are not present in the current message, these records are 364 deleted. 366 In addition to the address range records, the IP system maintains a 367 holdtime timer associated with the interface which is initialised to the 368 holdtime in the received message. If the timer expires before the 369 receipt of the next Range Map message, all multicast address range 370 records related to the interface are deleted. 372 5. Requesting and Receiving Notifications 374 Like IGMP, MSNIP is an asymmetric protocol specifying different 375 behaviours for systems wishing to source traffic and for multicast 376 routers. Host IP systems multicast Host Interest Solicitation messages 377 to register for notification with their first-hop routers. Routers 378 unicast Router Receiver Membership Reports to IP system to notify them 379 of the arrival of the first or departure of the last receivers for a 380 session. Note that a system may perform at the same time both of the 381 above functions. An example is a router that wishes to source traffic. 383 5.1. Host Interest Solicitation 385 Source systems that wish to be managed by MSNIP periodically 386 transmit an Interest Solicitation message. This message is multicast 387 with a multicast destination address of ALL_IGMPv3_ROUTERS (224.0.0.22) 388 and is transmitted every [Interest Solicitation Interval] seconds. The 389 Interest Solicitation message contains a holdtime which is set to 390 [Interest Solicitation Holdtime] and instructs the multicast first-hop 391 routers to maintain MSNIP state for this IP system for the specified 392 period. A generation ID is also included in the Interest Solicitation 393 message to provide support for routers to detect IP system crashes (see 394 section 9.2). 396 When an IP system first comes up it transmits [Robustness Variable] 397 Interest Solicitation messages randomly spaced over [Initial Interest 398 Solicitation Interval] seconds. 400 All MSNIP capable routers that receive an 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 an Interest Solicitation message is received from the IP 407 system, the holdtime timer is reset to the holdtime in the received 408 message. In addition the router responds to the solicitation message 409 with a Receiver Membership Report message described in section 5.2. The 410 message contains a TRANSMIT record for each of the multicast destination 411 addresses within the MSNIP managed range for which the routing protocol 412 indicates there are receivers for this source system. 414 When the holdtime timer of a specific system interest record 415 expires, the record is deleted. 417 5.2. Router Receiver Membership Reports 419 Receiver Membership Report messages are used by routers to 420 communicate the receiver membership status of particular multicast 421 destination addresses to a specific IP system. Each message contains a 422 list of transmission control records of either TRANSMIT or HOLD type 423 that instruct a system to respectively start or stop sending traffic on 424 this link to the specified multicast destination address. Receiver 425 Membership Report messages are unicast to the target system. 427 In addition to the receipt of an Interest Solicitation message, 428 routers send unsolicited Receiver Membership Reports to IP systems when 429 the receiver membership status reported by the multicast routing 430 protocol changes for a specific source and multicast destination. Such 431 reports are only sent if the destination address is managed by MSNIP and 432 the router has a system interest record created by a previously received 433 Interest Solicitation message with a IP system address equal to the 434 source address. If the source destination pair satisfy these conditions 435 then [Robustness Variable] Receiver Membership Reports are sent out 436 within [Unsolicited Membership Report Interval] seconds. If during the 437 [Unsolicited Membership Report Interval] an additional membership change 438 occurs for the same destination address and source system, transmission 439 of any related pending Receiver Membership Report messages is cancelled 440 and a new set of [Robustness Variable] messages is scheduled. 442 When an IP system receives a Receiver Membership Report message, 443 for each of the TRANSMIT records listed in the message it creates or 444 updates a transmission record of the form: 446 (router address, source address, multicast address, holdtime timer) 448 The router address is obtained from the source address on the IP header 449 of the received message. The source address is obtained from the 450 destination address in the of the IP header. The holdtime timer is set 451 to [Interest Solicitation Holdtime] seconds. 453 For each HOLD record present in the message, the system deletes the 454 matching previously created transmission record from its state. 456 Note that creation and deletion of transmission records in an IP 457 systems state may cause local applications to be notified to start and 458 stop transmitting data (see section 7). 460 6. Routerless Operation 462 As defined in this specification MSNIP provides receiver membership 463 notification services for multicast networks operating an SSM routing 464 protocol. The protocol operates between the source IP system and the 465 first-hop routers. Although not obvious, local receivers on the same 466 link as the multicast source do not require special handling. Local 467 receivers use the usual process of joining the SSM channel through 468 IGMPv3 source specific joins. IGMP makes the local membership 469 information available to the routing protocol on all routers on the 470 link. The routing protocol is then responsible for electing the router 471 that will be responsible for acting on behalf of the local receivers (in 472 PIM this is the Designated Router or the PIM Assert winner). Normal 473 operation then results in MSNIP being notified and the source signalled 474 to start transmitting. 476 A special case that is not handled by default is that of a link not 477 connected to a routed multicast network. On a link with only senders and 478 receivers but no routers MSNIP capable sources do not have a mechanism 479 for being notified about the existence of local receivers. However, 480 since there is no router to send out Range Map messages, IP systems 481 assume that there are no MSNIP managed address ranges and all 482 applications default to transmitting immediately. Therefore expected 483 behaviour (without MSNIP) is preserved. 485 In order to prevent source flooding in a routerless link when there 486 are no local receivers for the data, MSNIP requires that one of the IP 487 systems on the link acts as an MSNIP server. This server must implement 488 the router side of the IGMPv3 and MSNIP protocols. The MSNIP server 489 must be configured with a multicast address range that is to be managed 490 which will then be advertised in the Range Map messages. When IGMPv3 491 Source Specific reports are received for sources on the link, the IGMP 492 component in the server must notify the MSNIP component. If the 493 multicast destination address for which the report was received is a 494 managed address then MSNIP can perform its usual functions to control 495 the source. 497 7. Application Notification 499 This section describes the relation between protocol events and 500 notifications to source applications within an IP system. The state 501 machine below is specific to each source address of the IP system and 502 each multicast destination address. The initial state is the No Info 503 state. 505 +-----------------------------------+ 506 | Figures omitted from text version | 507 +-----------------------------------+ 509 Figure 1: Per source-address (S) and multicast destination address (G) state 510 machine at an IP system 512 In tabular form, the state-machine is: 514 +-----------+-----------------------------------------------------------+ 515 | | Event | 516 | +----------+-----------+------------+-----------+-----------+ 517 |Prev State |New |Start |Stop |Recv |Recv last | 518 | |Register |Manage |Manage |TRANSMIT |HOLD or | 519 | | | | | |timeout | 520 +-----------+----------+-----------+------------+-----------+-----------+ 521 | |Start new |-> Hold |- |- |- | 522 |No Info | |Stop ALL | | | | 523 | | |registered | | | | 524 +-----------+----------+-----------+------------+-----------+-----------+ 525 | |- |- |-> No Info |-> |- | 526 |Hold | | | |Transmit | | 527 | | | |Stop ALL |Start ALL | | 528 | | | |registered |registered | | 529 +-----------+----------+-----------+------------+-----------+-----------+ 530 | |Start new |- |-> No Info |- |-> Hold | 531 |Transmit | | | | |Stop ALL | 532 | | | | | |registered | 533 +-----------+----------+-----------+------------+-----------+-----------+ 535 The events in state machine above have the following meaning: 537 New register 538 A new application has registered through a call to 539 IPMulticastsSourceRegister for this S and G. 541 Start manage 542 We received a Range Map packet on the interface that S belongs to 543 that changed the status of G from a non-managed to a MSNIP managed 544 destination address. 546 Stop manage 547 We received a Range Map packet on the interface that S belongs to 548 that changed the status of G from a MSNIP managed to a non-managed 549 destination address or the mapping state that caused this 550 destination address to be managed expired. 552 Receive TRANSMIT 553 We received a Receiver Membership Report with S as the IP 554 destination address that contains a TRANSMIT record for G. 556 Receive last HOLD or timeout 557 We either received a Receiver Membership Report with S as the IP 558 destination address that contains a HOLD record for G or a TRANSMIT 559 record for S and G expired and there are no other TRANSMIT records 560 for S and G. This means that the last router that was reporting 561 receivers no longer does so and there are no routers left wishing 562 to receive traffic from this S to destination address G. 564 The state machine actions have the following meaning: 566 Start new 567 Send an IPMulticastSourceStart notification to the application that 568 just registered for this S and G. 570 Start ALL registered 571 Send an IPMulticastSourceStart notification to all applications 572 that are registered for this S and G. 574 Stop ALL registered 575 Send an IPMulticastSourceStop notification to all applications that 576 are registered for this S and G. 578 8. Router Processing 580 This section describes the per-source system tracking state machine 581 operated by each first-hop router. The initial state is No Info. 583 +-----------------------------------+ 584 | Figures omitted from text version | 585 +-----------------------------------+ 587 Figure 2: Per IP source system (S) state machine at a router 589 In tabular form, the state-machine is: 591 +------------+----------------------------------------------------------+ 592 | | Event | 593 | +------------+-----------+--------------+------------------+ 594 |Prev State | Receive | HIS | Receivers | Receivers | 595 | | HIS | timeout | for new | of G leave | 596 | | | | destination | | 597 | | | | G | | 598 +------------+------------+-----------+--------------+------------------+ 599 | | -> | - | - | - | 600 | | Tracking | | | | 601 | | Set HT to | | | | 602 |Not | message | | | | 603 |tracking | holdtime | | | | 604 | | Send ALL | | | | 605 | | existing | | | | 606 | | TRANSMITs | | | | 607 +------------+------------+-----------+--------------+------------------+ 608 |Tracking | Set HT to | -> Not | Send | Send HOLD | 609 | | message | tracking | TRANSMIT | for G | 610 | | holdtime | | for G | | 611 +------------+------------+-----------+--------------+------------------+ 613 The events in state machine above have the following meaning: 615 Receive HIS 616 The router has received a Host Interest Solicitation from S. 618 HIS timeout 619 The holdtime timer (HT) associated with S has expired. 621 Receivers for new destination G 622 The routing protocol has informed MSNIP that it now has receivers 623 for the MSNIP managed destination address G and source IP system S. 625 Receivers of G leave 626 The routing protocol has informed MSNIP that all receivers for the 627 MSNIP managed destination address G and source IP system S have 628 left the channel. 630 The state machine actions have the following meaning: 632 Set HT to message holdtime 633 The holdtime timer associated with S is restarted to the value of 634 the holdtime in the received Host Interest Solicitation message. 636 Send ALL existing TRANSMITs 637 The router builds and transmits Receiver Membership Reports to S 638 that contain a TRANSMIT record for each of the MSNIP managed 639 destination addresses that have receivers for S. 641 Send TRANSMIT for G 642 The router builds and transmits a Receiver Membership Report to S 643 that contains a TRANSMIT record for the destination address G. 645 Send HOLD for G 646 The router builds and transmits a Receiver Membership Report to S 647 that contains a HOLD record for the destination address G. 649 9. Message Formats 651 Like all other IGMP messages, MSNIP messages are encapsulated in 652 IPv4 datagrams, with an IP protocol number of 2. Every MSNIP message 653 described in this document is sent with an IP Time-to-Live of 1, and 654 carries an IP Router Alert option [RFC-2113] in its IP header. 656 There are three IGMP message types of concern to the MSNIP protocol 657 described in this document: 659 +-------------------+----------------------------+ 660 | Type Number (hex) | Message Name | 661 +-------------------+----------------------------+ 662 | 0x23 | Range Map | 663 +-------------------+----------------------------+ 664 | 0x24 | Interest Solicitation | 665 +-------------------+----------------------------+ 666 | 0x25 | Receiver Membership Report | 667 +-------------------+----------------------------+ 669 9.1. Range Map Packet 671 A Range Map packet is periodically multicast by the IGMP querier to 672 declare the multicast destination address ranges managed by MSNIP. The 673 Range Map message is multicast with a destination address of ALL_SYSTEMS 674 (224.0.0.1). 676 0 1 2 3 677 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 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Type = 0x23 | Range Count | Checksum | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | Holdtime | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Destination-Prefix-1 | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Mask-Len-1 | Reserved | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | . | 688 | . | 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 Range Count 692 The number of multicast destination address range records present 693 in this message. Note that the actual maximum number of ranges that 694 can be reported is limited by the maximum size of an IP packet. As 695 each Range Map packet replaces the mapping at a receiving system, a 696 router cannot split the range mapping into more than one Range Map 697 packets. 699 Checksum 700 The Checksum is the 16-bit one's complement of the one's complement 701 sum of the whole MSNIP message (the entire IP payload). For 702 computing the checksum, the Checksum field is set to zero. When 703 receiving packets, the checksum MUST be verified before processing 704 a packet. 706 Holdtime 707 The amount of time a receiving system must keep the range map state 708 alive, in seconds. 710 Destination-Prefix-1 711 The destination address range prefix of the first range record 712 present in this message. 714 Mask-Len-1 715 The mask length for the destination address range in the first 716 record present in this message. 718 Reserved 719 Transmitted as zero. Ignored upon receipt. 721 9.2. Interest Solicitation Packet 723 A Interest Solicitation packet is periodically multicast by MSNIP 724 capable systems to declare interest in Receiver Membership Reports from 725 multicast routers on the link. The Interest Solicitation message is 726 multicast with a destination address of ALL_IGMPv3_ROUTERS (224.0.0.22). 728 0 1 2 3 729 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 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | Type = 0x24 | Reserved | Checksum | 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Holdtime | GenID | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 736 Reserved 737 Transmitted as zero. Ignored upon receipt. 739 Checksum 740 Calculated as for Range Map packet. 742 Holdtime 743 The amount of time a receiving router must keep the system interest 744 state alive, in seconds. 746 GenID 747 Generation ID of the IP system. A number that is selected randomly 748 for each of the [Robustness Variable] initial Interest Solicitation 749 messages when the system comes up and afterwards remains fixed to 750 the value used in the last of the initial messages throughout the 751 system lifetime. The GenID is used by routers to detect system 752 crashes. 754 9.3. Receiver Membership Report Packet 756 A Receiver Membership Report packet is unicast by first-hop multicast 757 routers and targeted at potential sources to inform them of the 758 existence or not of receivers for the listed multicast destination 759 addresses. 761 0 1 2 3 762 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 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | Type = 0x25 | Dest Count | Checksum | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | Record-Type-1 | Reserved | 767 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 | Destination-Address-1 | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 | . | 771 | . | 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 774 Dest Count 775 The number of multicast destination address records present in this 776 message. 778 Checksum 779 Calculated as for Range Map packet. 781 Record-Type-1 782 The type of the first transmission control record in this message. 783 Valid values are: 785 +-------------+----------------------------------------------+-------+ 786 | Record Type | Description | Value | 787 +-------------+----------------------------------------------+-------+ 788 | TRANSMIT | Request to start transmitting to destination | 1 | 789 +-------------+----------------------------------------------+-------+ 790 | HOLD | Request to stop transmitting to destination | 2 | 791 +-------------+----------------------------------------------+-------+ 793 Reserved 794 Transmitted as zero. Ignored upon receipt. 796 Destination-Address-1 797 The multicast destination address of the first record in the 798 message. 800 10. Constants Timers and Default Values 802 Robustness Variable 803 The Robustness Variable allows tuning for the expected packet loss 804 on a network. If a network is expected to be lossy, the Robustness 805 Variable may be increased. MSNIP is robust to (Robustness Variable 806 - 1) packet losses. The Robustness Variable MUST NOT be zero, and 807 SHOULD NOT be one. Default: 2 809 Range Map Interval 810 The interval used by the IGMP querier between transmissions of 811 Range Map messages. Default: 60 secs 813 Range Map Holdtime 814 The interval inserted in Range Map messages that indicates to 815 systems how long they should use the included mapping information 816 before they time it out. This MUST be ((the Robustness Variable) 817 times (the Range Map Interval) plus (one second)). 819 Interest Solicitation Interval 820 The interval used by MSNIP capable systems between transmissions of 821 Interest Solicitation messages. Default: 60 secs 823 Interest Solicitation Holdtime 824 The interval inserted in Interest Solicitation messages by systems 825 to instruct routers how long they should maintain system interest 826 state for. This MUST be ((the Robustness Variable) times (the 827 Interest Solicitation Interval) plus (one second)). 829 Initial Interest Solicitation Interval 830 The interval used by systems to send out the initial Interest 831 Solicitation messages when they first come up. Default: 1 second. 833 Unsolicited Membership Report Interval 834 The interval used by routers to send out a set of Membership Report 835 messages when the receiver membership changes for a specific 836 system. Default: 1 second. 838 11. Todo list... 840 o Add security considerations section. 842 o Cover IPv6. 844 o If application ignores or does not ask for notification in managed 845 range host OS should filter packets. 847 o Maybe provide masks for registration / notification API. 849 o Case where host and app starts before MSNIP range is available. 851 o When we hear out-of-order IGMP query resend interest registration. 853 o Only send interest registration when application is interested. This 854 is not possible if we do host filtering... 856 o Maybe add API to ask the kernel for the state of a particular 857 destination. bool IpMulticastSourceHasInterest (socket, source- 858 address, multicast-address). 860 o Add GenID changes to router FSM. 862 12. Acknowledgements 864 The authors would like to thank Dave Thaler and Jon Crowcroft for their 865 contribution to this specification. 867 13. Authors' Addresses 869 Bill Fenner 870 AT&T Labs - Research 871 75 Willow Road 872 Menlo Park, CA 94025 873 fenner@research.att.com 875 Hugh Holbrook 876 Cisco Systems 877 170 W. Tasman Drive 878 San Jose, CA 95134 879 holbrook@cisco.com 881 Isidor Kouvelas 882 Cisco Systems 883 170 W. Tasman Drive 884 San Jose, CA 95134 885 kouvelas@cisco.com 887 14. References 889 [1] B. Cain, S Deering, W. Fenner, I Kouvelas, A. Thyagarajan, "Internet 890 Group Management Protocol, Version 3", Work In Progress, , 2000. 893 [2] S. Kent, R. Atkinson, "Security Architecture for the Internet 894 Protocol.", RFC 2401. 896 [3] B. Fenner, M. Handley, H. Holbrook, I. Kouvelas, "Protocol 897 Independent Multicast - Sparse Mode (PIM-SM): Protocol 898 Specification (Revised)", Work In Progress, , 2000. 901 [4] Z. Albanna, K. Almeroth, D. Meyer, "IANA Guidelines for IPv4 902 Multicast Address Allocation", Best Current Practices, , 2001. 905 [5] S. Biswas, B. Haberman, "IGMP Multicast Router Discovery", Work In 906 Progress, , 2001.