Internet DRAFT - draft-beck-mboned-ssm-source-discovery-protocol
draft-beck-mboned-ssm-source-discovery-protocol
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]
