Network and Protocol Team F. Beck Internet-Draft M. Hoerdt Expires: novembre 30, 2003 J-J. Pansiot LSIIT June 2003 Source Discovery Protocol in SSM Networks draft-beck-mboned-ssm-source-discovery-protocol-00.txt 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. This Internet-Draft will expire on novembre 30, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document presents a protocol performing source discovery in SSM Networks. Beck, et al. Expires novembre 30, 2003 [Page 1] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation and Goals . . . . . . . . . . . . . . . . . . . . 4 3. Problem Overview . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Problems To Solve . . . . . . . . . . . . . . . . . . . . . 5 3.2 Solution Proposed . . . . . . . . . . . . . . . . . . . . . 5 4. ASM over SSM Emulation . . . . . . . . . . . . . . . . . . . 7 4.1 Protocol Description for Source-Server Interaction . . . . . 7 4.1.1 With a New Source . . . . . . . . . . . . . . . . . . . . . 7 4.1.2 With an Existing Source . . . . . . . . . . . . . . . . . . 8 4.1.3 Message Acknowledgement . . . . . . . . . . . . . . . . . . 9 4.2 Protocol Description for Receiver-Server Interaction . . . . 10 4.2.1 Information Request . . . . . . . . . . . . . . . . . . . . 10 4.2.2 Source Advertising . . . . . . . . . . . . . . . . . . . . . 12 5. Floor Control Capabilities . . . . . . . . . . . . . . . . . 13 5.1 KICK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2 VOICE . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.3 Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Messages Formats . . . . . . . . . . . . . . . . . . . . . . 15 7. Source's States . . . . . . . . . . . . . . . . . . . . . . 16 7.1 ASM over SSM emulation states . . . . . . . . . . . . . . . 16 7.2 Floor Control states . . . . . . . . . . . . . . . . . . . . 17 8. Breakdowns and Consequences . . . . . . . . . . . . . . . . 19 9. Timers and their Default Values . . . . . . . . . . . . . . 20 9.1 ON Validity . . . . . . . . . . . . . . . . . . . . . . . . 20 9.2 ON Forwarding . . . . . . . . . . . . . . . . . . . . . . . 20 9.3 ON Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.4 ON Ack . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.5 ON Src . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.6 OFF Ack . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.7 Kick . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 9.8 Mute . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.9 ALIVE . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.10 ALIVE Cycle . . . . . . . . . . . . . . . . . . . . . . . . 21 10. Security Considerations . . . . . . . . . . . . . . . . . . 22 References . . . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 24 Intellectual Property and Copyright Statements . . . . . . . 25 Beck, et al. Expires novembre 30, 2003 [Page 2] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 1. Introduction In his thesis [1], Holbrook considered the case of using multi-source applications in SSM network only environment. He defined two schemes, an hybrid approach of them and evaluated them : He proposes a sender advertisement scheme using a control channel and a session relaying scheme using a central node, and argues that both of them have advantages and inconvenients. He measured the startup delay of the sessions and simulated both propositions but did not define an architecture for it. That's why we propose an architecture based on his idea in this paper. In paper [2] Chesterfield and Schooler propose to modify rtp/rtcp to have it working under SSM environment. It is aimed at large scale multimedia distribution and control and dot not consider the case of medium sized multiparty conferences. Their solution could work under vic and rat but reduces the informations provided by rtp/rtcp protocol for conferencing application and could only work with multicast applications using RTP/RTCP. We try here to define an architecture aimed at multi-sources applications, as independent as possible from the application and only providing independent services for an applicative group. This paper describes a protocol which could be used in such an architecture to achieve the source discovery in a SSM Network. Beck, et al. Expires novembre 30, 2003 [Page 3] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 2. Motivation and Goals As a first point, we would like to have a quickly deployable architecture, according to the latest networks and applications research efforts. This means using SSM service, because it is simple to maintain for operators. Second, this proposition must be scalable regarding the number of announced sources. This architecture must be fault tolerant regarding the sources dynamics. For application performances, the architecture must be as transparent as possible compared to the classical ASM model. On the implementation viewpoint, our architecture must be portable, independent of the IP version stack used and easy to use for an application developer. Beck, et al. Expires novembre 30, 2003 [Page 4] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 3. Problem Overview In this section, we will describe an architecture that solves the problems cited, and permits the use of channels in multi-sender applications. This architecture is partially inspired by Hugh W. Holbrook's thesis [1]. 3.1 Problems To Solve We aim to use channels in multi-sender applications, but to do so, we have several problems to solve. Firstly, in the ASM model described by Deering, a multicast group is only identified by his IP address. But here, we will work with SSM multicast channels, which are described by a couple (S,G) composed of the unicast IP address of a source S and an IP multicast address G. But then, knowing that at the moment, in most of the applications like Vic or Rat a multicast group is identified by both its IP multicast address and the port used to send data to, the problem of identifying a multicast group appears. Secondly, on the one hand, in ASM when a receiver joins a group, he discovers automatically the sources when they send data to the group. In the same way, when a new source appears, the receivers learn it simply by receiving the packets sent. On the other hand, with the SSM model, no such mechanism exists, because we work with channels (S,G) where S is the single source being able to emit on this channel. Consequently, the receivers must have a way of discovering the active sources and being informed of the arrival of new ones. To achieve our goal, we have two choices : o Session Relaying o Sender Advertising We will now explain a solution, based on sender advertising. 3.2 Solution Proposed Our solution uses at least a channel per source, and a global channel, called control channel, which is used for relaying various administration information for the group. This control channel identifies the multicast group, and runs on top of UDP for sending data. Therefore, to announce a group, it is only Beck, et al. Expires novembre 30, 2003 [Page 5] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 necessary to advertise this channel and the UDP port used, receivers having only to join the multicast channel and bind it to obtain all informations necessary to take part in the session. The source of this control channel will be called controller for the group, and will perform the administration operation for this group, like advertising new sources, giving the list of the existing ones on demand and optionally making some network floor control. As it is possible for the same controller to have authority for several groups, it has been decided to use a single process that takes care of these groups. This server uses a single UDP socket listening on a announced port to communicate with the sources or the receivers which want to learn the existing sources. The source advertising messages and other administration messages are sent to all the receivers via the channel of control. This server takes care on a controller S of all the control channels identified by a channel (S,...). These channels do not necesseraly use the the same UDP port to sent data to. This server is run on the application level of the OSI model, because it takes care of the interaction with the applications used in multicast sessions. The advantage of having this server running on the application layer, is that it is possible to choose its location so that the performances are the best, and it introduces the possibility of doing floor control at the application layer. Moreover to manipulate UDP socket is very easy and allows quick implementation. This paper describes a protocol which could be used between the sources or the receivers and the controller in SSM Networks to manage sources. Beck, et al. Expires novembre 30, 2003 [Page 6] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 4. ASM over SSM Emulation In this section, we describe the ASM over SSM emulation part of the protocol, which means the way the receivers learn the active sources for a group at a given time, and the new ones which could appear during the session. 4.1 Protocol Description for Source-Server Interaction Now we will describe the interaction between a source for a group, and the controller (that means the server) for this group. We'll only take a look at the source advertising, the network floor control is optionnal and will be described later in this draft. 4.1.1 With a New Source When a new source wants to announce itself, it must begin by informing the server. The server then stores the information about the source in his cache. This announcement is done with a message composed of this protocol's header with a SDP payload [3][4][5], that we will call a message ON, sent to the UDP socket of the server. This message must contain all the necessary informations for a receiver to join the channel used by the source to send its data to the group. It is composed of the new source channel information and possibly transport or protocol over IP information. As an example if the application transmit data over UDP, this message ON must contain : the group identifier (S,G,P), the channel and the port used by the source to send the data to, the dates of beginning and end of validity of the session and possibly informations which the receivers could need to decode the data. It must be noted that the transport information is only destined to applications and not the protocol described here. In the previous example, the application behavior is the same than the ASM one. It means that UDP sources have to send to the same UDP announced port and that each receiver have to bind on the same UDP port for data reception. Once this message ON has been treated, the server must announce the source to the receivers. To do so, it forwards this message to the whole group via the control channel, if the source is allowed to send data to the group. Therefore, all the receivers learn that this source exists, and are able to join the channel it uses to send data if desired. See Figure 1 for an illustration of this mechanism. Beck, et al. Expires novembre 30, 2003 [Page 7] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 +-------+ +---->| Cache | 2. Cache | +-------+ update | | | 1. ON((S,G),..) +--------+ <--------------------- +--------+ | Server | | Source | +--------+ ---------------------> +--------+ /\ 3b. ON_ACK /\ / \ / \ Channel / \ / \ (SRC,M) /\ /\ /\ /\ / \ / \ 3a. Forwarding ON message / \ / \ | | Channel | -> +----------+ | 4. if desired, joins (S,G) +----| Receiver |-------------+ (SRC,M) +----------+ Figure 1 : Interaction Source - Server for a message ON. 4.1.2 With an Existing Source Periodically, a source must send a message ON to the server, in order to inform it that it is still active, and the server forwards this message on its control channel to the receivers. For each source, the server keeps a timer which gives the time the source entry in his cache is valid. If the server doesn't receive such a message before the timer associated with the source ends, it considers that the source isn't active anymore, removes the corresponding entry in his cache and sends a message OFF to inform the receivers that this source no longer exists. The sources and the receivers also have to maintain some timers in order to take care of the validity of the various informations and messages. For example, a source has to run a timer for the validity of a message ON in order to take care of the periodical sent of this message. A source can also explicitly announce that it stops its activity by sending a message OFF to the server, which removes the corresponding entry in its cache and forwards this message on the corresponding control channel in order to inform the receivers, which then leave this channel. The mechanism is illustrated on figure 2. Note that some upper layer protocols already have a function to advertise the end in participating in a session but not advertising that they are transmitting as control plane and data plane are mixed in classical Beck, et al. Expires novembre 30, 2003 [Page 8] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 multicast. This is the case with BYE packets from RTCP protocol. The message OFF is almost identical to the message ON. It is sent to the announced port of the control channel on an UDP socket and is a message composed of this protocol's header with a SDP payload, but all the information given in the message ON aren't necessary : it is only necessary to give the identifier of the group and the identifier of the channel used to send data. These two parameters are sufficient to leave the channel corresponding to the source. +-------+ +---->| Cache | 2. Cache | +-------+ update | | 1. OFF((S,G),..) +--------+ <--------------------- +--------+ | Server | | Source | +--------+ ---------------------> +--------+ /\ 3b. OFF_ACK /\ / \ / \ Channel / \ / \ (SRC,M) /\ /\ /\ /\ / \ / \ 3a. Forwarding OFF message / \ / \ | | | | Channel | -> +----------+ \ / | 4. leaves (S,G) +----| Receiver |------+-------+ (SRC,M) +----------+ / \ Figure 2 : Interaction Source - Server for a message OFF. 4.1.3 Message Acknowledgement In order to add functionalities and robustness to our protocol, message acknowledgements can be very useful. Thus, a new message ON_ACK is created and is sent in unicast from the server to the source in response to a ON message. In the same way, if a source announces its explicit departure by sending a message OFF to the server, this one responses with a OFF_ACK message. This acknowledgement gives the possibility to add new functionalities to our protocol. For example, it can be imagined to combine this system with MSNIP [6] in order to realize the synchronization between the sender and the receiver for the data sending on the source's tree. Another options would be to add an authentification mechanism, for example by exchanging a key or a session identifier. Beck, et al. Expires novembre 30, 2003 [Page 9] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 In order to keep the possibility to add these functionalities or other ones, a field "reserved" has been added in the protocol's message format. As we use this acknowledgement system, we have to introduce new timers. These timers represent the duration the process waits for the ON_ACK or the OFF_ACK messages before it sends again respectly a message ON or OFF. 4.2 Protocol Description for Receiver-Server Interaction Here we describe the interaction between a receiver and the server. We distinguish the case when a receiver demands informations about the sources which are active for the group, and the case when a source has announced itself. 4.2.1 Information Request The server acts here as a directory of sources. A receiver which wants to learn the list of the existing sources for a group on which the server has authority, sends him a unicast message on a known port from the receiver. This message is an UDP paquet with as payload our protocol header and a SDP description which contains the group identifier, which is the couple (S,G). We call this message a message INFO_REQ. When the server receives such a message, it takes a look at his cache, and responses to the receiver in unicast with a message INFO_RESP giving this list of source and enough informations for the receiver to join the corresponding channels if wanted. If the server wants to be able to give these informations, it has to maintain a cache containing all these. That means that the cache must contain the group identifier (S,G,P), if there are more than one controller, the control channels used by these controllers, the dates of beginning and ending of validity of the session, and the source list. That gives the table : +---------------+----------------------+---+---------+------+-------+ |control channel|second control channel|...|beginning|ending|sources| +---------------+----------------------+---+---------+------+-------+ The source list is composed of zero or several entries. Each entry describes a source and gives the information that a receiver may need to join the channel used for sending data to the group and then use these data. Such an entry is like : Beck, et al. Expires novembre 30, 2003 [Page 10] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 FLAGS _____/\_____ | | +---------------+----+------+-----+-------------------+-----+ |sending channel|port|KICKED|VOICE|coding informations|Timer| +---------------+----+------+-----+-------------------+-----+ Figure 3 : Interaction receiver - Server. The flags KICKED and VOICE are used if Floor Control operations are performed, and are set to 0 by default, and the coding informations are optional. This cache is used by the server to store all the informations for a group, but the receivers have to maintain the same cache, but limited to one applicative group. This cache is updated thanks to the messages sent on the control channel. The message INFO_RESP is an UDP paquet with as payload this protocol's header with a SDP description describing the session and the sources. The SDP part contains the group identifier, the dates of beginning and end of validity of the session, and a list of zero or more channels and ports used by the sources to send data to the group, and possibly more information about these sources which the receivers could need. When a receiver receives a paquet INFO_RESP, if it hasn't done yet, it joins the control channel, and does the same with the channels used by the sources which it has interest in. See Figure 3. Beck, et al. Expires novembre 30, 2003 [Page 11] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 +----------+ 1. INFO_REQ((S,G),...) +-----------+ | | ------------------------> | | | Receiver | | Controller | | | <------------------------ | | +----------+ 2. INFO_RESP(...) +-----------+ |\ /\ | \ / \ Channel | \ / \ (S,G) | \ /\ /\ | \ / \ / \ | \ | | +-------------------------------+ | 3. JOIN(S,G) +-------------+ | +----------+ | | | | | Source | | 4. if desired, joins the | | | sources announced in the +----------+ | INFO_RESP message. /\ | Channel / \ | (SRC,M) / \ | /\ /\ | / \ / \ | +-----+ Figure 3 : Interaction receiver - Server. 4.2.2 Source Advertising When a new source announces its activity to the server, it has to inform all the receivers. To do so, it forwards the message ON received from the source on the control channel. In the same way, when the server detects the explicit or implicit departure of a source, it forwards or sends, according to the case, a message OFF for this source on the control channel. Beck, et al. Expires novembre 30, 2003 [Page 12] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 5. Floor Control Capabilities This protocol provides the possibility to perform some control operations on an applicative group. These Floor Control operations are optionnal. In this section, we give two examples of such operations, the KICK and MUTE mechanisms, inspired by the control operations available in the IRC protocol [7][8][9][10][11]. 5.1 KICK The KICK operation consists in forbidding a source to send data to the group. As we are using channels, the server cannot block the traffic from the source, but it has the possibility to prevent the receivers from receiving it. Indeed, if a source isn't wanted anymore for a group, the flag KICKED is set in the entry corresponding from the server's cache, and a message KICK is sent on the control channel for this source. Then, all the receivers learn that the source isn't desired anymore and have the possibility to leave the corresponding channel, after having set the flag KICKED in their cache. As the source is still active, it sends periodically ON messages to the server, but as long as the flag KICKED is set for this source, the server doesn't forward these messages, but instead sends a KICK message. If the source is authorized to emit again, it is enough to withdraw the KICKED flag and to propagate a message ON for this source on the control channel, the receivers unsetting the KICKED flag in their cache will have the possibility to join again the corresponding channel if it has been left. This mechanism is transparent for the sources : this operation is done by the receivers which are supposed to leave the channel used by the source. 5.2 VOICE This mechanism is less violent than the KICK one. Here the source is not inevitably undesirable, but in order to save resources or to maintain session integrity, it is wished that only specified sources transmit data. To do so, the server sends a message MUTE containing the group identifier to the sources that shouldn't send data. These when they receive such a message, sent in unicast to an announced port UDP on the source (the address is known from the channel used to send data to), stop sending data on their channels, but keep doing the other Beck, et al. Expires novembre 30, 2003 [Page 13] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 stuff like sending periodical ON messages to the server. To authorize the source to emit again, a message UNMUTE containing the group identifier is send to the source. If a source has been asked to mute, the flag VOICE is set in the corresponding entry in the server's cache, and this flag is removed if the source is authorized to send data to the group. As long as the flag MUTE is set, the server periodically sends MUTE message to the source. This operation is totally transparent for the receivers, unlike the KICK one where they have to perform JOIN and LEAVE actions. But this operation needs the cooperation of the source which has to stop sending data to the group. That implies that sources also run a process which listens on this port and performs the needed operations if MUTE or UNMUTE messages are received. 5.3 Timers To perform these several operations, both the source and the controler have to keep running timers, in order to take care of the validity of KICK and MUTE messages. If the timer associated to the MUTE message expires, the source decides that it can send data again, removes the MUTE flag and sends again on its data channel. A receiver has to run a timer giving the validity of a KICK message. If this timer runs out, the VOICE flag is removed and the channel data corresponding to the source is joined (if it was left). In the same way, the server has to maintain two timers giving the duration before the next sent of a KICK or MUTE message. The timers used for KICK and MUTE periodical messages are the same as the timer used for the ON message. Beck, et al. Expires novembre 30, 2003 [Page 14] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 6. Messages Formats One possibility could be to use SAP messages with a SDP description as payload. However, it has only one bit of type message, which gives us only the possibility to code 2 messages, but we have at least 10 different messages to specify. Instead, we propose the following 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=1 |A| Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | T | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 : Message Format. V: Version Number (3 bits). The current version number is 1. A: Address Type (1 bit). If this bit is 0, then the description in the payload is made for an IPv4 group, else if it is set at 1, it is an IPv6 group. R: Reserved (32 bits). Reserved for further extensions. T: Type of the message (5 bits). Specifies the message type, which can be OFF (00000), ON (00001), MUTE (000010), UNMUTE (00011), ALIVE (00100), KICK (00101), INFO_REQ (00110), INFO_RESP (00111), ON_ACK (01000) or OFF_ACK (01001). The payload is an SDP description of the group and/or the source. As we are using SSM channels, the description made for the group or the source is based on the draft [5]. The payload's length isn't fixed, it depends on the informations given. For example, if the payload is used in a message 0FF to describe the group and the channel used by the source to send data to the applicative group, it will be shorter than if it used in a message INFO_RESP to describe all the active sources for a group. Thanks to the use of SDP description, it is possible to merge several source description in only one ON message, which can be useful for sending periodic ON messages for a group on its control channel. In the same way, we can imagine a mechanism which would permit to merge several protocol messages in the same IP packet. Beck, et al. Expires novembre 30, 2003 [Page 15] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 7. Source's States In this section, we describe the different states in which a source can be, depending on the action realized thanks to this protocol. We will distinguish the ASM over SSM emulation part and the Control operations. 7.1 ASM over SSM emulation states The different states in which a source can be in this case are : o ON_SENT : the source has sent a message ON to the server and waits for the ON_ACK o ACTIVE : the source has received the acknowledgement, notifying that it has been recorded as active and announced so, in response on the ON message it sent. o OFF_SENT :the source has sent a OFF message to announce its departure and is waiting for the acknowledgement. o INACTIVE : the source has never been active or has sent a OFF message and has received the corresponding OFF_ACK. The following states diagram describes the different states and the transition between them for the ASM over SSM emulation part, which means the source advertising. Beck, et al. Expires novembre 30, 2003 [Page 16] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 +-------------------+ | | | INACTIVE |<-----------+ +---->| | | | +-------------------+ | | | | | | sends ON | time out | | | | \/ | | +-------------------+ | | | | | +-----| ON_SENT | | | | | +-------------------+ | | | receives OFF_ACK | receives ON_ACK | | | \/ | +-------------------+ | | | | | ACTIVE | | +---->| | | | +-------------------+ | | | | | | sends OFF | time out | | | | \/ | | +-------------------+ | | | | | +-----| OFF_SENT |------------+ | | +-------------------+ Figure 5 : States Diagram for ASM over SSM emulation. 7.2 Floor Control states If the optional Floor Control operations are performed, some new states are introduced. The different states in which a source can be in this case are : o ACTIVE : the source is normally active. o MUTED : The source has been asked by the server to stop sending data on its channel. o KICKED : The source has been KICKED by the controller (but it is Beck, et al. Expires novembre 30, 2003 [Page 17] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 still active). o INACTIVE : The source has announced that it isn't active anymore. The MUTE state is transparent for the receivers, the muted source's channel (multicast tree) is kept. This state is only available for sources. In the same way, the KICKED state has only sense for the receivers, the channel of a kicked source is removed (actually it is virtually removed by the controler's KICK message, the source keeps its data channel and keeps on sending data on it). We can imagine that we send a message KICK to the source to advertise it that it has been kicked from the session, but it isn't an obligation. the INACTIVE state is reached when the receiver has received the OFF message forwarded on the control channel. The following states diagram describes the different states and the transition between them for the Floor Control operations. +-------------------+ +---------| |---------------+ MUTE | | ACTIVE | | received | +---->| |<-----------+ | | | +-------------------+ | | KICK received | | | | | | UNMUTE ON | | | | received received | | \/ | | \/ +-----------------+ +-----------------+ | | | | | MUTED | | KICKED | | | | | +-----------------+ +-----------------+ | | | | OFF | | OFF received | +-------------------+ | received | | | | | | INACTIVE |<-----------+ +---->| | +-------------------+ Figure 6 : States Diagram for Floor Control. Beck, et al. Expires novembre 30, 2003 [Page 18] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 8. Breakdowns and Consequences The master controller S sends on its control channel periodical ALIVE messages to show that it is always active. This message is a UDP packet with this protocol's header and a SDP description containing the group identifier for which it is the controller. If the backup controller S' doesn't receive any ALIVE message from S on (S,G) after the supposed time, it considers that S is down and begins sending ALIVE packets and source advertising. A source which was kicked by the other controller will be announced as active the next time it sends a message ON unless the new one kicks it. In the same way, a source that has been asked to mute, after the timer of the validity of the MUTE message has expired, will begin to send data again. To avoid this situation, it is possible to distribute this by adding a KICK flag in each receiver's cache. Then, if the master controller kicks a source, it announces it with a message KICK, which causes this KICK to be set in all receivers, including the second master. This flag would be valid until a ON message for this source is sent. Such a mechanism gives us at the application level the possibility for the application based on this protocol to ask the user if he still wants to receive data from the source even if the controller recommands to kick it, or if he wants to follow the controller's order in case of a MUTE message. Supposing that the master controller S breaks down, S' detects it and begins assuming this role as already described earlier. A receiver that has already joined the group is a member of both control channels, and then receives the control data on (S',G'), and except the time until S' takes the control, nothing special happens. In the same way, a receiver that wants to join the session joins both control channel, and has the informations he needs from S'. Beck, et al. Expires novembre 30, 2003 [Page 19] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 9. Timers and their Default Values The messages ON, KICK and MUTE are sent periodically in order to add robustness to our protocol. Therefore, we have to use several timers to define the validity of the different states and informations. In this section, we describe the different timers used in our protocol and their default value. Some of them are configurable, the other ones depend on each others. 9.1 ON Validity This timer describe the validity of a source entry in the server's cache. It is the reference used to define most of other timers. If we allow its value to being configurable, we could be distribute it to the sources and the receivers thanks to the ON message. Default : 15 seconds. 9.2 ON Forwarding This timer describes the period the server uses to send ON messages on the control channel. Default : 1/3 * the ON Validity. 9.3 ON Cycle The ON Cycle is the period between two ON messages sent by a source. In order to be robust to one message ON lost, we must have 2 * the ON Cycle > ON Validity Default : 1/3 the ON Validity. 9.4 ON Ack The ON Ack is the time the source waits for the acknowledgement of an ON message. Default : 1/3 the ON Validity. 9.5 ON Src The ON Src is the time of validity of a ON message for a receiver. Default : the ON Validity. 9.6 OFF Ack The OFF Ack is the time the source waits for the acknowledgement of an OFF message. Default : 1/3 the ON Validity. 9.7 Kick It is the time of validity of a KICK message sent by the server, and is used at the receiver's level. Default : ON Validity. Beck, et al. Expires novembre 30, 2003 [Page 20] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 9.8 Mute It is the time of validity of a MUTE message sent by the server, and is used at the source's level. Default : ON Validity. 9.9 ALIVE It is the time of validity of an ALIVE message sent by the server, and is used at the receiver's level. Actually, it only makes sense for the other controlers if we have redundancy in order to add robustness. Default : 2 * the ON Validity. 9.10 ALIVE Cycle It is the time between two ALIVE messages sent by the server. Default : 3/4 * ON Validity. Beck, et al. Expires novembre 30, 2003 [Page 21] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 10. Security Considerations At this moment, this protocol does not provide security mechanism at all. The only security warrants are based on IP. Because this protocol is based on top of a connectionless protocol (UDP), it's very easy for someone to abuse the security mechanisms offered by IP with techniques like IP spoofing. This is why is it's very important on the receiver part to bind on the two part of the (S,G) control channel. According to the SSM service model, and how the SSM multicast tree construction is done at the IP level, it is more difficult to spoof a channel than an IP. More security mechanisms could be imagined, like using a single session identifier per group which is only distributed between the controllers. But the security problem isn't limited to the controller. We can imagined that a source usurps another's identity and carries out false advertisements for this one. By doing so, a source can be announced as no more active whereas it still sends data. To avoid this, we could use an appropriate authentification mechanism, which can be done thanks to the acknowledgment messages for example. Beck, et al. Expires novembre 30, 2003 [Page 22] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 References [1] Holbrook, H., "A channel model for multicast", August 1991 - 2001. [2] Chesterfield, J. and E. Schooler, "An Extensible RTCP Control Framework for Large Multimedia Distributions", april 2003. [3] Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", oct 2000. [4] Handley, M. and V. Jacobson, "Session Description Protocol", apr 1998. [5] Quinn, B. and R. Finlayson, "Session Description Protocol (SDP) Source Filters", may 2003. [6] Fenner, B., Haberman, B., Holbrook, H. and I. Kouvelas, "Multicast Source Notification of Interest Protocol (MSNIP)", june 2003. [7] oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", may 1993. [8] Kalt, C., "Internet Relay Chat Protocol: Architecture", apr 2000. [9] Kalt, C., "Internet Relay Chat Protocol: Channel Management", apr 2000. [10] Kalt, C., "Internet Relay Chat Protocol: Client Protocol", apr 2000. [11] Kalt, C., "Internet Relay Chat Protocol: Server Protocol", apr 2000. [12] Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", may 2003. Beck, et al. Expires novembre 30, 2003 [Page 23] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 Authors' Addresses Frederic Beck LSIIT PŸle API, bureau C444 Boulevard S‰bastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 86 EMail: beck@clarinet.u-strasbg.fr URI: http://clarinet.u-strasbg.Fr/~beck/ Micka‹l Hoerdt LSIIT PŸle API, bureau C444 Boulevard S‰bastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 86 EMail: hoerdt@clarinet.u-strasbg.fr URI: http://clarinet.u-strasbg.Fr/~hoerdt/ Jean-Jacques Pansiot LSIIT PŸle API, bureau C447 Boulevard S‰bastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 84 EMail: pansiot@clarinet.u-strasbg.fr URI: http://clarinet.u-strasbg.Fr/~pansiot/ Beck, et al. Expires novembre 30, 2003 [Page 24] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Beck, et al. Expires novembre 30, 2003 [Page 25] Internet-Draft Source Discovery Protocol in SSM Networks June 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Beck, et al. Expires novembre 30, 2003 [Page 26]