Internet Engineering Task Force Guillermo Rigotti INTERNET-DRAFT UNICEN May 1999 Reversed Multicast (RVM) Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), ftp.ietf.org (US East Coast), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this document is unlimited. Abstract This memo presents extensions to IP that enable the use of source-based distribution trees (such as those established by DVMRP[1] or PIM-DM[2]) to deliver multicast packets generated by members of a multicast group in the opposite direction to packets originated by the source (S). Packets generated by a member M of a group G are forwarded (unicast) from an in-tree router to another, towards the source S. In addition to send the packet to its upstream, each in-tree router injects it into the multicast tree (S,G). This enables packets to reach the rest of the receivers, as S would originate them. The "reversed" use of the distribution tree is intended for sending of low volume feedback information produced by receivers in applications G. Rigotti Expires November 1999 [Page 1] Internet Draft Reversed Multicast (RVM) May 1999 such as RTP/RTCP[3] and reliable multicast. This feature diminish the overhead in routers in case of applications with a source and many receivers sending feedback, because only one distribution tree, rooted at the sender S must be maintained, in place of one per member. In addition, multicast packets originated by receivers,travel through the inverse path of information ones in the distribution tree. This can be exploited by multicast transport protocols to localize processes to subtrees or to reduce exposure. 1. Introduction Forwarding of multicast packets is based on distribution trees established by multicast routing protocols such as DVMRP, PIM, CBT, etc. There are different types of distribution trees. Source-based trees are rooted at the source. These trees span all the subnetworks with attached group members. Packets flow in in the direction root to leaves. When several senders to a group exist, it is necessary to create one tree per sender. Shared trees are rooted at a node called "core" or "rendevouz point". These trees span all the members of a group. Only one tree is created for a group, and all the senders to the group share it. In unidirectional shared trees, such as those established by PIM-SM, a packet flows from the core (root of the tree) to the leaves. A sender encapsulates the multicast packet and sends it to the unicast address of the core, who distributes it. Bidirectional shared trees enable senders in a member subnet to directly inject (through its designated router) the packets in the distribution tree, diminishing delays and overhead. Although source-based trees offer attractive characteristics from a standpoint of the offered quality of service, its use must be carefully evaluated in the case of many-to-many multicast applications. This is because of network resources consumed, such as state maintained in routers and periodic graft/prunes in case of dense mode protocols. Although currently applications are one-to-many, some, such as RTP/RTCP and reliable multicast transport protocols, demand the creation of one distribution tree per member to carry feedback information from this member to the source and the others members. This feedback information may be generated periodicaly, as in RTCP, or may be triggered by an event, such as a missing packet in SRM. The last situation could produce additional overhead in dense mode protocols, due to the flooding of the data packet, in the case that pruning information for the receiver (source of its distribution tree) has been expired. This memo presents extensions to the network level that enable multicast receivers to request the sending of feedback or control information G. Rigotti Expires November 1999 [Page 2] Internet Draft Reversed Multicast (RVM) May 1999 destined to the sender and the rest of the receivers, using the the multicast distribution tree rooted at the sender. Multicast packets generated by the receivers, are sent encapsulated in RVM (reversed) packets, in-tree router by in-tree router towards the source. When an in-tree router decapsulates such packets, it injects them into the multicast distribution tree rooted at the sender of the application with addresses (S,G), as a packet generated by the sender. Applications must be capable to distinguish the type and origin (if necessary) of the packet through different mechanisms, such as different ports for data and control information and/or specific fields in the application's PDUs. RVM packets are identified by a new option (RVM_OPTION) added to the IP header. 2. RVM_OPTION This option is defined to enable routers to recognize and process RVM packets generated by the receivers of an application. As mentioned, these packets encapsulate multicast packets carrying control information destined to the sender and the other receivers. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0| RVM_OPT | Length (8) | T |Ttl| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Downstream router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Format of RVM_OPTION. The fields of the new option, are the following: Option Type: Copied Flag = 1 Option Class = 0 Option number = RVM_OPT (new IP option) Option Length: 8 G. Rigotti Expires November 1999 [Page 3] Internet Draft Reversed Multicast (RVM) May 1999 T (Type): Type of RVM packet 00: (reversed) packet sent in direction leaf to root. 01: (normal) packet sent in direction root to leaves. 10: reserved. 11: reserved. Ttl: Indicates how a router must proceed to set the TTL value of the multicast packet encapsulated in the RVM packet. 00: TTL field of encapsulated multicast packets remains unchanged. 01: TTL field of encapsulated multicast packet is set to the remaining TTL value of the RVM packet. 10: reserved. 11: reserved. Downstream router: Local IP address of the (upstream) interface through which a router send a RVM (reversed) packet. 3. Operation 3.1. Generation of a RVM packet (Type = reversed) A receiver of a multicast application is a member (M1) of the group (G) used by the sender to multicast its packets to the receivers. That receiver is a leaf in the multicast tree rooted at the sender. When a receiver needs to send feedback information to the sender (S) and the other receivers, for example a RTP receiver generating a RTCP report, it builds a multicast packet containing such feedback information. This multicast packet is generated with destination address G, and source address S, in place of M1. The generation will be carried out by the network level upon request of the application to send a RVM packet. When request the sending of a RVM packet, the application must be provided by the network API with some means to set both TTL values (RVM packet and multicast encapsulated packet) and the type of treatment that will be applied to the TTL field of the multicast packet in each decapsulator router. As mentioned earlier, the application must have some means to enable receivers to determine the origin of the received multicast packets addressed to (S,G), for example differents ports for data and control information and/or specific application's PDU fields. The network level at the host where the receiver resides, generates an IP packet with the option RVM (type = reversed), that encapsulates the multicast packet previously generated. G. Rigotti Expires November 1999 [Page 4] Internet Draft Reversed Multicast (RVM) May 1999 The RVM packet is generated with the following contents in RVM_OPTION: - Type field of RVM option specifies direction leaf-to-root (reversed). - "Downstream router" field contains the local IP address of the interface used to reach the upstream router (the interface through which the packet is sent). - TTL field of RVM option indicates the treatment that each router will give to the TTL field of the multicast packet. This option enables applications to control the scope of multicast packets containing feedback information. This scope refers to the following aspects: the number of hops the packet is forwarded in direction to the source (TTL field of RVM packet) and the number of hops the packet is multicasted from each decapsulator router in direction to the leaves (TTL field of the multicast packet or remaining TTL of the RVM packet). 3.2. Sending a RVM (reversed) packet A RVM (reversed) packet is sent in-tree router to in-tree router towards the source (S) following the opposite direction to multicast packets originated by S. Packets are sent to the upstream node, such as mtrace[4] does, in the case its address is known. In the case of a host (where RVM packets are generated), which has not knowlwdge of routing information, packets are multicast to the address "all routers on this subnet" (224.0.0.2) on the interface through which the host has joined the group. In this case, only the Designated Forwarder for (S,G) (in the case of a multiaccess network) will process the packet. 3.3. Receiving a RVM (reversed) packet Actions carried out by routers upon reception of a RVM (reversed) packet are the following: - Accept or discard the packet. - In case the packet is accepted, process it: - generate a RVM (reversed) packet to be sent to the upstream router. - inject the decapsulated multicast packet into the subtree of the (S,G) distribution tree rooted at this router, with the exception of the subtree rooted at the router that has sent the RVM (reversed) packet. A RVM (reversed) packet will be processed only if it comes from a downstream router in the distribution tree corresponding to the encapsulated packet. G. Rigotti Expires November 1999 [Page 5] Internet Draft Reversed Multicast (RVM) May 1999 If the packet received is addressed to "all the routers on this subnet", it will be accepted if the following conditions are satisfied: 1- the multiaccess interface through wich the packet is received is a downstream interface and, 2- the router is the designated forwarder for (S,G) in that interface (this is to avoid generation of duplicate packets). If the packet received is addresed to the node, it will be rejected if the router that had sent the packet is not a downstream router with respect to the source of the encapsulated packet. In every case, the RVM (reversed) packet will be discarded if its TTL reaches 0. The propagation of RVM (reversed) packet towards the source is accomplished as follows: - Determine the address of the upstream router with respect to the source (S) of the encapsulated multicast packet. - Replace the field "downstream router" in the RVM_OPTION with the local address of the interface towards the upstream router. - Decrement by one the TTL field of the RVM (reversed) packet. - Send the modified RVM (reversed) packet as described in section 3.2. The propagation of the decapsulated multicast packet in the subtree rooted at this router must be done avoiding send the packet to the router from which the RVM (reversed) packet was received. - The packet will be transmitted over all the output interfaces (oifs) contained in the MFC entry for (S,G), with the exception of that associated to the router that had sent the RVM (reversed) packet (oif_r). - In the case this interface (oif_r) is multiaccess, it is possible that exist another downstream routers and host members of the group attached to it. To make posible that they receive the decapsulated packet, the decapsulator router proceeds as is described in section 3.4. 3.4. Generation and sending of a RVM (normal) packet A RVM (normal) packet has the same format as an RVM (reversed). It is sent in the direction root-to-leaves through the (S,G) distribution tree. The object of this type of packet is to make possible the operation in multiaccess links. When a router receives an RVM (reversed) packet through a multiaccess downstream interface, it multicasts a RVM (normal) packet on it. Each router or host attached to that link has the G. Rigotti Expires November 1999 [Page 6] Internet Draft Reversed Multicast (RVM) May 1999 responsibility to accept or reject the encapsulated multicast packet. To generate a RVM (normal) packet, the router changes the type of RVM (reversed) packet to RVM (normal) packet leaving its TTL field unchanged, and multicasts it to the address "all systems on this subnet" (224.0.0.1). Note that despite of its TTL value, the packet will never be propagated beyond the local network, because it is addressed to a "well-known" group. In this way, all routers and hosts receive the packet, operating as is described in section 3.5. 3.5. Reception of a RVM (normal) packet A router only accepts a RVM (normal) packet if it is received through the input interface towards the source of the encapsulated multicast packet. In such case, the router must check the "dowstream router" field of the RVM_OPTION. If its contents match with its own address on the interface, it means that the corresponding RVM (reversed) packet was generated by this router, so the packet is discarded. In other case, the packet comes from another router, and is processed as follows. The multicast packet is decapsulated and sent through all the output interfaces (oifs) contained in the MFC entry for (S,G). Its TTL field is set according to TTL values of the encapsulated packet, the RVM (normal) packet and TTL field of the RVM_OPTION. A host accepts the RVM (normal) packet if it arrives through an interface through which the host joined to the group of the encapsulated multicast. The network level in the host has the responsibility of decapsulate the multicast packet and deliver it to the applications. 4. Additional considerations The main advantage of this approach is the reduction of the number of source-based distribution trees that need to be maintained at network level as a consequence of one-to-many applications in which receivers need to send feedback information to the sender and another receivers. In dense mode protocols, the gain may be greater in the case of receivers sending sporadic information, such as NACKs in SRM, because the possible expiration of prunning information in the routers, that brings the flooding of packets. G. Rigotti Expires November 1999 [Page 7] Internet Draft Reversed Multicast (RVM) May 1999 An additional advantage is that this approach enables to localize process to subtrees and avoid exposure because the packets carrying feedback information follow the inverse path of those containing data, feature that would be useful in reliable multicast transport protocols. It can also be useful to resume information that need to be propagated out of the subtree, for example, RTCP reports. Other aspects that need to be considered are the increment of end-to-end delays betweeen receivers because the use of the distribution tree rooted at the sender, and the concentration of traffic in its links. 5. References [1] T. Pusateri, "Distance Vector Multicast Routing Protocol", , Inter-Domain Multicast Routing Working Group, February 1999. [2] S. Deering et al. "Protocol Independent Multicast Version 2 Dense Mode Specification", , PIM Working Group, March 1999. [3] H. Schulzrinne et al., "RTP: A Transport Protocol for Real Time Applications", RFC 1889, January 1996. [4] W. Fenner, S. Casner, "A traceroute facility for IP Multicast", , Inter-Domain Multicast Routing Working Group, August 1998. Authors' Addresses Guillermo Rigotti Computer Sciences Departament. UNICEN - Fac. Ciencias Exactas. Tandil - Bs. As. - Argentina Phone: +54 - 2293 - 440363 FAX: +54 - 2293 - 440362 Email: grigotti@exa.unicen.edu.ar G. Rigotti Expires November 1999 [Page 8]