Internet Engineering Task Force Haixiang He INTERNET-DRAFT Nortel Networks Expire: January, 2002 July, 2001 MSNIP Extension for IGMP Proxying Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract IGMP Proxying can be used to forward multicast data traffic in certain network topologies. Due to the limitation of the IGMP Proxying, a Proxy has to forward multicast packets received from downstream interfaces to upstream interface. In this document, we proposed a solution to solve this inefficiency by using an extension to MSNIP. 1. Introduction IGMP Proxying [1][2] can be used by IPv4 system to forward multicast traffic in certain network topologies. A device (Proxy) performing He [Page 1] Internet Draft MSNIP Extension for IGMP Proxying January, 2002 IGMP Proxying has a single upstream interface and one or more downstream interface(s). It performs IGMP host portion on its upstream interface and IGMP router portion on its downstream interfaces. MSNIP(Multicast Source Notification of Interest Protocol)[3] is an extension to IGMPv3 [4]. It is proposed to enable multicast sources to avoid the work of sending packets when there are no receivers. In IGMP Proxying, a Proxy has to forward packets received on any downstream interface to the upstream interface. This is because the Proxy lacks the abilities to find out whether there is any receiver that is interested in receiving the packets through the upstream interface. This is inefficient for the Proxy. In this document, we proposed a solution to improve the inefficiency of IGMP Proxying by using an extension to MSNIP. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Packets Forwarding to Upstream Issues and Solutions In IGMP Proxying, a Proxy forwards every multicast packet received from downstream interfaces to upstream interface even there is no receiver upstream. From the upstream network point of view, a Proxy behaves like a system that wishes to source multicast traffic. Compared to multicast sources, the only difference here is that the packets' source addresses are not the address of the Proxy's upstream interface. Same as other systems that wish to source multicast traffic, there are inefficiencies for the Proxy as well as the upstream link if there are no receiver upstream. The same concept of MSNIP can also be used here between the Proxy and the upstream router to remove the inefficiency. Like any multicast source that uses MSNIP, when a Proxy first receives packets from downstream interfaces, it forwards them to upstream interface. Then when the Proxy is informed by MSNIP that there is no receiver upstream, it stop forwarding packets to upstream interface. It will resume forwarding packets when it is informed by upstream router. But the current MSNIP specification has to be extended to accommodate the communication of receiver membership information between the Proxy and the upstream router. This is because the Proxy is not the original source of the multicast packets. So the current MSNIP specification won't work in that the receiver membership information He [Page 2] Internet Draft MSNIP Extension for IGMP Proxying January, 2002 is unicast to the original multicast source directly. Also a Proxy cannot use the current MSNIP specification to solicit interest of receiver membership information for specific multicast sources. We proposed two new MSNIP messages to accommodate the communication. The new messages allow a Proxy to solicit its interest of receiver membership information for specific sources. And they also enable a multicast router to send the receiver membership information for specific sources to a Proxy that interests in receiving this information instead of the original multicast source. A Proxy MUST have the ability to know the source address of the packets it forwards to upstream interface. The upstream router should follow the requirements for first hop router specified in MSNIP [3]. We define that SOURCE is a system that source multicast packets. We also define that PROXY is a device that forwards multicast packets. A device can be both a PROXY and a SOURCE. 3. New MSNIP Messages The two new MSNIP messages are Source Interest Solicitation message and Source Group Membership Report message. Like other MSNIP messages, these two new messages should follows the requirements specified in [3]. The new message types are: +-------------------+-----------------------------------------+ | Type Number (hex) | Message Name | +-------------------+-----------------------------------------+ | 0x26 | Source Interest Solicitation | +-------------------+-----------------------------------------+ | 0x27 | Source Group Receiver Membership Report | +-------------------+-----------------------------------------+ 3.1. Source Interest Solicitation Packet Like Interest Solicitation, the Source Interest Solicitation packet is also periodically multicast by MSNIP capable systems. But it is used by PROXYs to solicit interest in Receiver Membership Reports for specific multicast source(s) from multicast router on the link. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ He [Page 3] Internet Draft MSNIP Extension for IGMP Proxying January, 2002 | Type = 0x26 | Reserved | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Holdtime | GenID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Count | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source-Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Count The number of source addresses presented in the message. Source-Address-1 The first multicast source address in the message. Other fields Same as described in [3]. 3.2. Source Group Membership Report Packet The Group Membership Report message is unicast by the first-hop multicast routers, in this document upstream routers, to communicate the existence or not of receivers for specific source and group pairs. The destination address is the IP address of a system that has interest of receiving the information. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = 0x27 | Source Count | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group-Count-1 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source-Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Record-Type-1-1| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group-Address-1-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Count He [Page 4] Internet Draft MSNIP Extension for IGMP Proxying January, 2002 The number of source records present in the packet. Group-Count-1 The number of group records present in the first source record. Source-Address-1 The multicast source address for the first source record in the message. Record-Type-1-1 The type of the first group record of the first source record. Valid values are the same as in MSNIP specification [3]. Group-Address-1-1 The multicast group address of the first group record in the first source record. 4. MSNIP Extension Description A PROXY and an upstream router still follow the behavior of the Group Range Negotiation to communicate a range of MSNIP managed groups as specified in [3]. 4.1. Source Interest Solicitation PROXYs periodically transit Source Interest Solicitation messages following the requirements to transit Interest Solicitation messages. The upstream routers that receive an Source Interest Solicitation message maintain a system interest record of the form: (destination address, holdtime timer, source address list) where the destination address is the IP address of the upstream interface of a PROXY and each source address s in the source address list is one of the multicast source that a PROXY forwards its packets and it has interest to receive its membership report information. The upstream routers may also choose to maintain a system interest record per multicast source of the form: (source address, destination address, holdtime timer) where the source address is the multicast source and the destination address is the address of a PROXY that has interest to receive membership report information for this source. Which form of record to use is an implementation issue. He [Page 5] Internet Draft MSNIP Extension for IGMP Proxying January, 2002 The router responds to the Source Interest Solicitation message with a Source Group Membership Report Message described in section 3.2. The message contains a TRANSMIT group record for each of the group addresses within the MSNIP managed range for which the routing protocol indicates there are receivers for source(s) in the source list. 4.2. Source Group Membership Reports When receiving a Source Interest Solicitation message, or when the receiver membership status changes for a specific source and group, routers send Source Group Membership Reports. Such reports are only sent if the group is managed by MSNIP and the source address is interested by a PROXY. The receiver membership information is unicast to the PROXY that has interest of the information. The destination address is the IP address of the upstream interface of the PROXY. It can be acquired through the system interest record maintained by the upstream router. When a PROXY receives a Source Group Membership Report message, for each of the TRANSMIT source group records listed in the message, it creates or updates a source group record of the form: (interface, router address, src, group address, holdtime timer) where the src is the multicast source address and other fields are the same as in MSNIP specification. For each of the HOLD source group records in the message, the PROXY deletes the relevant source group record from its state. 4.3. Upstream Router State Information To maintain only one format of the system interest record, the upstream routers that receive an Interest Solicitation message MAY maintain a record for a SOURCE system like below: (IP address(des), holdtime timer, IP address(src)) or (IP address(src), IP address(des), holdtime timer) where IP address is the SOURCE's IP address. In this case, when the routers needs to send the receiver membership He [Page 6] Internet Draft MSNIP Extension for IGMP Proxying January, 2002 information for a specific source address, the source address is used to search the system records. If the source address is find in the source lists or source fields, then the corresponding destination address is retrieved. If the destination address equals the source address, then the Group Membership Report message is sent. Otherwise, the Source Group Membership Report message is sent. 4.4. Proxy's State Information A Proxy can be a PROXY that forwards multicast packets and it can also be a SOURCE that sends multicast packets. If a Proxy is both a PROXY and a SOURCE, it uses both Interest Solicitation and Source Interest Solicitation messages. It may use just Source Interest Solicitation message with its upstream interface IP address as one of the source address in the message. To maintain just one format of the record, when it receives an Interest Solicitation message, it also maintain a record as described in section 4.2. The source address is the IP address of the upstream interface. 5. Changes of API for Request Membership Notification If the IGMP Proxying is considered an application to MSNIP and uses the APIs to request membership notification, the current MSNIP APIs need to be modified. The new API must support the following operation or any logical equivalent: IPMulticastSourceRegister(socket, if, source-addr, multicast-addr) IPMulticastSourceDeregister(socket, if, source-addr, multicast-addr) In addition the IGMP Proxying or other applications must provide the following API for receiving notifications: IPMulticastSourceStart(socket, if, source-addr, multicast-addr) IPMulticastSourceStop(socket, if, source-addr, multicast-addr) where: source-addr is the IP multicast source address to which the request pertains. If transmission to more than one source address on a given interface is desired, IPMulticastSourceRegister is invoked separately for each desired source address. Other fields are the same as described in MSNIP specification. He [Page 7] Internet Draft MSNIP Extension for IGMP Proxying January, 2002 6. Membership Information Relay The PROXY may choose to relay the membership report information to downstream sources. In this case, the MSNIP should be performed between downstream interface(s) and the downstream IP systems (direct source or others). How and to what degree to relay the membership information is beyond the scope of this document. 7. Security Considerations Security considerations will be provided later. References [1] Fenner, W., "IGMP-based Multicast Forwarding ("IGMP Proxying")", , April, 2001. [2] He, H., Haberman, B., and Sandick, H., "IGMP Mixed Version Proxying", , February, 2001. [3] Fenner, W., Holbrook, H., and Kouvelas, I., "Multicast Source Notification of Interest Protocol (MSNIP)", , February, 2001. [4] Cain, B., Deering, S., Fenner, W., Kouvelas, I., Thyagarajan, A., "Internet Group Management Protocol, Version 3", , March, 2001. Author's Address: Haixiang He Nortel Networks 600 Technology Park Drive Billerica, MA 01821 Phone: 978-288-7482 Email: haixiang@nortelnetworks.com He [Page 8]