Network Working Group Toni Paila Internet Draft Lin Xu Expires: October 2002 Nokia Research Center Wolfgang Hansmann University of Bonn April 2002 Source Controlled Multicasting Status of This Memo This document is an Internet-Draft and is subject to 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract Traditionally, multicast trees in the Internet are built bottom-up. The construction of multicast trees depends on the multicast receivers's ability to inform their next hop multicast routers about their multicast group memberships. There are cases, in which the traditional host-driven way of building the multicast trees is insufficient. To point out one, consider an access network with unidirectional links. In a mobile environment, this requires that the receiving interface of a mobile node must also have the capabilities to send out MLD or IGMP responses. This is not possible for broadcast networks (e.g DVB-T and DAB), that provide high downstream data Paila et al. [Page 1] Internet Draft Source Controlled Multicasting April 2002 rates, but no uplink connectivity. This document presents Source Controlled Multicast as a proposal solution to overcome the problems with unidirectional links. It presents a way to for source to control the multicast tree joining process on behalf of mobile nodes behind unidirectional links. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Solution Framework and Operation . . . . . . . . . . . . . . 5 4. Message formats . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Object Header . . . . . . . . . . . . . . . . . . . . . . 7 4.3 Message Structure . . . . . . . . . . . . . . . . . . . . 7 4.4 IPv4 Multicast Address Record . . . . . . . . . . . . . . 8 4.5 IPv6 Multicast Address record . . . . . . . . . . . . . . 10 4.6 Rule . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Protocol Operation . . . . . . . . . . . . . . . . . . . . . 11 5.1 MCC Operation . . . . . . . . . . . . . . . . . . . . . . 11 5.2 MCR Operation . . . . . . . . . . . . . . . . . . . . . . 11 5.2.1 MCR State . . . . . . . . . . . . . . . . . . . . . 11 5.2.2 Operation on Reception of a MCC message . . . . . . 12 5.2.3 Timeouts . . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Author's addresses . . . . . . . . . . . . . . . . . . . . . 14 Paila et al. [Page 2] Internet Draft Source Controlled Multicasting April 2002 1. Introduction Traditionally, multicast trees in the Internet are built bottom-up. The hosts willing to receive a certain multicast group send out group membership reports or equivalent. Consequently, multicast capable routers receive the reports from hosts and react by informing the adjacent multicast routers in a way specific to the multicast routing protocol in question. As a result, the multicast tree for the given group is built. Thus, the construction of multicast trees depends on the multicast receivers's ability to inform their next hop multicast routers about their multicast group memberships. There are cases, in which the traditional host-driven way of building the multicast trees is insufficient. To point out one, consider an access network with unidirectional links. An example of such a network is a DVB-T access system including the unidirectional broadcast radio links. The hosts served by such an access system are capable of receiving, only. Hence, the hosts are unable to send any Memberhips Reports or equivalent, and thus unable to express their willingness to receive multicast transmission over the unidirectional link. The problem is that it should be possible to make certain multicast groups available on the unidirectional links which the served hosts may be interested in. The decision of which multicast groups should be made accessible over the unidirectional link may be either up to the access network provider or an individual third party to which the access network provider maintains a trust relationship. Further issues on the selection of available multicast groups are not discussed in this document. This document presents a proposal solution for the above mentioned problem. The proposal, called Source Controlled Multicast, presents a way to for a multicast source (or a network entity different from the multicast listeners) to control the multicast tree building process. Paila et al. [Page 3] Internet Draft Source Controlled Multicasting April 2002 2. Terms 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 [1]. In addition, this document uses the following terms: MR Last hop multicast capable router. MCC Multicast Controller. A network entity that acts as a controller in the Source Control mechanism introduced in this document. MCC is in charge of generating control messages to tell the MCR's which multicast groups to join. MCR Multicast Control Responder. A network entity that receives MCC messages and joins multicast groups on behalf of (a number of) RO- MNs. The RO-MNs and the MCR must have the same first hop MR. Alternatively, a MCR can be implemented in a MR itself. RO-MN A multicast capable IPv4 or IPv6 node having only a receive-only network interface. Thus, the MN is not able to send multicast group membership reports. SCG Source Controllable Group. This is a multicast group comprising of at least one MCC as source controller and at least one MCR as control responder. TBD to be decided Paila et al. [Page 4] Internet Draft Source Controlled Multicasting April 2002 3. Solution Framework and Operation +---------+ +------+ | MCC |------+-------| MR1 |-----+..... > +---------+ +---------+ | +------+ | | RO-MN || | +------+ +---------+| | | MCR1 | +---------+ | +------+ | | +------+ +-------| MR2 |........... > +---------+ | MCR2 | | RO-MN || +------+ +---------+| +---------+ | = bidirectional link : = unidirectional link Figure 1, Solution Framework for Source Controlled Multicast A multicast group is used to communicate Source Control Messages from a Multicast Controller to a set of Multicast Control Responders. A Multicast Controller and a set of Multicast Control Responders that are members of such group define a Source Controllable Group. The membership to a specific group may be either statically configured in MCC and MCR, or it may be dynamically configured by a method out of the scope of this document. Each SCG has at least one MCC and at least one MCR. In the Figure 1 above, the nodes MCC, MCR1 and MCR2 make together a Source Controllable Group. A single MCC or MCR may belong to several Source Controllable Groups. Note also that the MR1 and MCR1 illustrate the case in which MR and MCR are separate entities. As an alternative, MR2 and MCR2 illustrate the case in which MCR is implemented in MR. The operation of MCC and MCR consists of three phases. Phase 1 - Source Controllable Group Building Upon startup, any node that belongs to any SCG should immediately joins all the SCG groups it belongs to. Note that phase 1 will be continuous. MCR may join this group at any time. Phase 2 - Source Control Message Delivery Multicast Controller sends Control Messages to one of its Source Controllable Groups. The information delivered in a Control Paila et al. [Page 5] Internet Draft Source Controlled Multicasting April 2002 Message is given in Chapter 4. The control messages are routed along the multicast tree of the group until they reach the designated multicast capable router of each MCR. This router makes the Control Message available for the MCR. The MCR interprets the Control Message and takes appropriate actions upon the received information. Among the information is the Requested Group. The MCR may execute one of the following actions - Join the Requested Group - Leave the Requested Group - Silently discard the message (in case the message was invalid) Phase 3 - Joining the multicast groups Assume that the selected action for Control Message was to join the Requested Group. Consequently the MCR joins the group. This results in building of a multicast tree for the Requested Group, bottom-up. Now, any messages that are sent to the Requested Group will reach each subnet that selected to join in response to the Control Message. The nodes behind the unidirectional links MAY be informed about the availablity of the group by means of the Session Announcement Protocol (SAP) [5]. 4. Message formats 4.1 Overview A Source Control Message uses UDP with a TBD destination port for transport and is sent by one of the MCCs of the SCG and received by all the joined MCRs in that group. The Control Message conveys the following pieces of information: Paila et al. [Page 6] Internet Draft Source Controlled Multicasting April 2002 Requested Groups A list of multicast groups the "agreeing" MCR is requested to join. Target selection criteria Definition of what the abovementioned "agreeing" means. The criteria specifies a list of properties that must hold for the MCR to be "agreeing". For example, MCC may request MCRs that belong to a certain geographical area to join. Alternative, MCC may request all the MCR that have free capacity in the respective local subnet to join. 4.2 Object header A SCM control message contains a set of objects. All objects share the following header format: 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 16-bit unsigned integer that specifies the object type. The following objects types are defined: 1 IPv4_MulticastAddressRecord 2 IPv6_MulticastAddressRecord 3 Rule Length 16-bit unsigned integer. Specifies the length of the object in octets including the header. 4.3 Message Structure A SCM message consists of a set of IPv4_MulticastAddressRecords or IPv6_MulticastAddressRecords. An optional Rule object can be appended to any of the multicast address records objects. This message Paila et al. [Page 7] Internet Draft Source Controlled Multicasting April 2002 structure is expressed by the BNF expression SCMMessage = 1*((IPv4_MulticastAddressRecord| IPv6_MulticastAddressRecord)[Rule]) 4.4 IPv4 Multicast Address Record The IPv4 Multicast Address Record carries information on a specific IPv4 multicast group for a MCR to join. 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime |F|O| Number of sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 multicast address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source #1, if any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source #n, if any | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 1 IPv4 multicast address the IPv4 multicast group address this object refers to. Lifetime 16-bit unsigned integer. This field specifies the lifetime for this address record in units of seconds. A lifetime value of 0 deletes the multicast address record state for this multicast group entry. Number of sources 14-bit integer. For SSM (source specific multicast) support a set of of multicast sender addresses can be passed with an IPv4 Paila et al. [Page 8] Internet Draft Source Controlled Multicasting April 2002 Multicast Address Record. If "Number of sources" is greater than 0, a corresponding number of IPv4 addresses are appended to the object. Filter rule bit (F) The F bit specifies the multicast filter rule to be applied according to [3] or [4]: 0 - INCLUDE indicates that the following list of senders should be passed with a filter mode of INCLUDE 1 - EXCLUDE indicates that the following list of senders should be passed with a filter mode of EXCLUDE Operation bit (O) 0 - DELETE indicates that the following list of senders should be deleted from an existing set of senders. The filter rule mode remains unchanged. 1 - ADD indicates that the following list of sender should be added to the already existing set of senders. The filter rule mode remains unchanged. If sender state with a filter mode of INCLUDE has been established, reception of a multicast address record with filter mode EXCLUDE replaces the sender state changing the filter mode to EXCLUDE. If sender state with a filter mode of EXCLUDE exists and a multicast address record with INCLUDE filter mode is received, then the filter mode of the state is changed to INCLUDE. When changing the filter mode of a multicast address record the set of multicast senders is replaced by the set of senders given in the multicast address record. Paila et al. [Page 9] Internet Draft Source Controlled Multicasting April 2002 4.5 IPv6 Multicast Address record The IPv6 Multicast Address Record carries information on a specific IPv6 multicast group for a MCR to join. 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lifetime |F|O| Number of sources | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + | | | + IPv6 multicast address | | | + | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source #1, if any + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + Source #n, if any + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 2 All other fields of the IPv6 Multicast Address record have the same meaning as the corresponding fields in the IPv4 Multicast Address record except that all address fields carry IPv6 addresses. Paila et al. [Page 10] Internet Draft Source Controlled Multicasting April 2002 4.6 Rule 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 | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rule Data ... +-+-+-+-+-+- Type 3 Rule Data The rule object lists constraints that have to be met by the matching multicast address. The format of this object is TBD. 5. Protocol Operation 5.1 MCC Operation The MCC periodically sends control messages to the multicast group to which the MCRs listen. At any time, the MCC's configuration of multicast memberships may change. The interval at which these messages are sent is TBD, it must be small enough to prevent timeouts of multicast membership state at the MCR due to spurious loss of messages. 5.2 MCR Operation 5.2.1 MCR State A MCR must keep track about incoming messages from the MCC. For each multicast address record the MCC must maintain a corresponding entry (G, T, R, F), where G is the address of the multicast group this entry refers to T is a timer, R is a (empty or non-empty) list of sender records ("sender list"), and F is a filter rule of either INCLUDE or EXCLUDE. Paila et al. [Page 11] Internet Draft Source Controlled Multicasting April 2002 A sender record is a tuple (S, T_s), where S is the IPv4 or IPv6 address of a multicast sender and T_s a timer. 5.2.2 Operation on Reception of a MCC message For each multicast address record in an incoming MCC message the MCR checks if the associated Rule applies to him. If it does not the message MUST be silently discarded. If the Rule applies, the multicast group address G is fetched from the multicast address record. The corresponding entry for G at the MCR is updated according to the following rules: 1. If the "Lifetime" field of the multicast address record is 0, the entry MUST be removed. No further processing is required. 2. If the multicast address record does not contain SSM senders ("Number of sources" equals 0), the timer is reset to the "Lifetime" value of the multicast address record. Any multicast sender information maintained in the entry is deleted. 3. If the multicast address record does contain SSM senders ("Number of sources" is greater than 0), then 3.1 If the filter mode specified in the multicast address record differs from the filter mode recorded in the entry any exiting multicast sender information is removed. If the "O" bit is set ("ADD") for each sender listed in the multicast address record a new pair (S, T_s) is appended to the entries's sender list. The timer is set to the "Lifetime" value. 3.2 If the filter mode is not changed, check the value of the "O" bit - If the "O" bit is not set ("DELETE"), the sender addresses in the multicast address record will be deleted from the entry's sender list. - If the "O" bit is set ("ADD"), for each new sender specified in the multicast address record list a pair (S, T_s) is appended to the entry's sender list. The timer is reset to Paila et al. [Page 12] Internet Draft Source Controlled Multicasting April 2002 the "Lifetime" value. If a sender already exists in the entry's sender list, just the timer is reset to the "Lifetime" value. After the entry has been updated, the local multicast stack MUST be notified about eventual changes in the multicast membership state of the MCR. This may require the use of OS dependent means to provide access to the IP multicast stack. 5.2.3 Timeouts: Each entry and each sender in an entry has a timer. If an entry's timer expires, the whole entry is deleted. If a sender in an entry's sender list times out, the sender is removed the entry's sender list. Again, the local multicast stack MUST be informed about eventual changes in the multicast membership state of the MCR. 6. Security Considerations To prevent a malicious node from masquerading as an MCC and thus controlling the MCR by spoofing Control Messages, the transport of Control Messages has to be protected. The receiver of the Control Message has to have means of authenticating the sending source. A way to perform this is to use IPSEC-AH [2]. Key distribution and details of any security mechanism is not in the scope of this document. 7. Acknowledgements This work has been performed in the framework of the IST project IST-1999-12515 DRiVE, which is partly funded by the European Union. The DRiVE consortium consists of Ericsson (co-ordinator) BBC, Bertelsmann, Bosch, DaimlerChrysler, Nokia, Steria, Teracom, VCON, and Vodafone as well as Rheinisch-Westfaelische Technische Hochschule RWTH Aachen, Universitaet Bonn, Heinrich-Hertz-Institut Berlin and the University of Surrey. The authors acknowledge the contributions of their colleagues in the DRiVE consortium. Paila et al. [Page 13] Internet Draft Source Controlled Multicasting April 2002 8. References [1] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels". RFC (Best Current Practice) 2119, Internet Engineering Task Force, March 1997. [2] Kent, S., and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [3] R. Vida, et al., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", Work in Progress. [4] Cain, B., Deering, S., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", Work in Progress. [5] M. Handley, C. Perkins, E. Whelan, "Session Announcement Protocol", RFC 2974, Interner Engineering Task Force, October 2000. 9. Author's addresses Toni Paila Nokia Research Center P.O. Box 407 FIN-00045 NOKIA GROUP Finland Email: toni.paila@nokia.com Lin Xu Nokia Research Center Visiokatu 1 FIN-33720 Tampere Finland Email: lin.xu@nokia.com Wolfgang Hansmann Institut fuer Informatik Roemerstrasse 164 D-53113 Bonn Germany Email: hansmann@cs.uni-bonn.de Paila et al. [Page 14]