F. Beck M. Hoerdt J-J. Pansiot LSIIT June 2003
All Rights Reserved.
Beck, et al.
Expires novembre 30, 2003
[Page 1]
This document presents a protocol performing source discovery and control in SSM Networks in the case of highly dynamic arrival/ departure of the sources.
Abstract
Copyright (C) The Internet Society (2003).
Copyright Notice
This Internet-Draft will expire on novembre 30, 2003.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt.
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."
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.
This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
Status of this Memo
Source Discovery Protocol in SSM Networks draft-beck-mboned-ssm-source-discovery-protocol-03.txt
Network and Protocol Team Internet-Draft Expires: novembre 30, 2003
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 1 Source Discovery Protocol in SSM Networks
Expires novembre 30, 2003
Introduction . . . . . . . . . . . . . . . . . . . . Motivation and Goals . . . . . . . . . . . . . . . . Problem Overview . . . . . . . . . . . . . . . . . . Problems To Solve . . . . . . . . . . . . . . . . . Solution Proposed . . . . . . . . . . . . . . . . . ASM over SSM Emulation . . . . . . . . . . . . . . . Protocol Description for Source-Thread Interaction . With a New Source . . . . . . . . . . . . . . . . . With an Existing Source . . . . . . . . . . . . . . Protocol Description for Receiver-Thread Interaction Floor Control Capabilities . . . . . . . . . . . . . KICK . . . . . . . . . . . . . . . . . . . . . . . . VOICE . . . . . . . . . . . . . . . . . . . . . . . Timers . . . . . . . . . . . . . . . . . . . . . . . Source’s States . . . . . . . . . . . . . . . . . . ASM over SSM emulation states . . . . . . . . . . . Floor Control states . . . . . . . . . . . . . . . . Breakdowns and Consequences . . . . . . . . . . . . Timers and their Default Values . . . . . . . . . . ON Validity . . . . . . . . . . . . . . . . . . . . ON Forwarding . . . . . . . . . . . . . . . . . . . ON Cycle . . . . . . . . . . . . . . . . . . . . . . ON Src . . . . . . . . . . . . . . . . . . . . . . . Kick . . . . . . . . . . . . . . . . . . . . . . . . Mute . . . . . . . . . . . . . . . . . . . . . . . . ALIVE . . . . . . . . . . . . . . . . . . . . . . . ALIVE Cycle . . . . . . . . . . . . . . . . . . . . Scalability consideration . . . . . . . . . . . . . Messages Formats . . . . . . . . . . . . . . . . . . Protocol’s Message Format . . . . . . . . . . . . . Encoded Source and Group Address Formats . . . . . . Encoded Source Address . . . . . . . . . . . . . . . Encoded Group Address . . . . . . . . . . . . . . . Security Considerations . . . . . . . . . . . . . . Acknowledgments . . . . . . . . . . . . . . . . . . References . . . . . . . . . . . . . . . . . . . . . Authors’ Addresses . . . . . . . . . . . . . . . . . Intellectual Property and Copyright Statements . . .
Beck, et al.
1. 2. 3. 3.1 3.2 4. 4.1 4.1.1 4.1.2 4.1.3 5. 5.1 5.2 5.3 6. 6.1 6.2 7. 8. 8.1 8.2 8.3 8.4 8.5 8.6 8.7 8.8 9. 10. 10.1 10.2 10.2.1 10.2.2 11. 12.
Table of Contents
Internet-Draft
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 4 5 5 5 7 7 7 8 9 12 12 12 13 14 14 14 17 18 18 18 18 18 18 18 18 19 20 22 22 24 24 25 26 27 28 29 30
[Page 2]
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
June 2003
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 2
Source Discovery Protocol in SSM Networks
June 2003
Beck, et al.
Expires novembre 30, 2003
[Page 3]
This paper describes a protocol which could be used in such an architecture to achieve the source discovery in a SSM Network.
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.
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.
1. Introduction
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 3 Source Discovery Protocol in SSM Networks
June 2003
Beck, et al.
Expires novembre 30, 2003
[Page 4]
On the implementation viewpoint, this architecture MUST be portable, independent of the IP version stack used and easy to use for an application developer.
For application performances and ease of portability , the architecture MUST be as transparent as possible compared to the classical ASM model.
Second, this proposition MUST be scalable regarding the number of announced sources and fault tolerant regarding the sources dynamics. This means using soft-state retransmission and UDP for control messages.
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.
2. Motivation and Goals
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 4
Source Discovery Protocol in SSM Networks
June 2003
Sender Advertising
o
Beck, et al.
Expires novembre 30, 2003
[Page 5]
This control channel identifies the multicast group, and runs on top
This solution uses at least a channel per source, and a global channel, called control channel, which is used for relaying various administration information and source advertising for the group.
3.2 Solution Proposed
We will now explain a solution, based on sender advertising.
Session Relaying
o
To achieve these goals, we have two choices as exposed in [1]:
Consequently, the receivers MUST have a way of discovering the active sources and being informed of the arrival of new ones.
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.
Firstly, in the ASM model described by Deering, a multicast group is only identified by its 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 where only S is allowed to put data in. 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.
We aim to use channels in multi-sender applications, but to do so, we have several problems to solve.
3.1 Problems To Solve
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 inspired by Hugh W. Holbrook’s thesis [1].
3. Problem Overview
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 5 Source Discovery Protocol in SSM Networks
June 2003
Beck, et al.
Expires novembre 30, 2003
[Page 6]
This paper describes a protocol which could be used between the sources or the receivers and the controller in SSM Networks to manage sources.
This thread is run at the application level of the OSI model, because it takes care of the interaction between the network and the applications used in multicast sessions. The advantage of having this thread 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 group management at the application layer. Moreover to manipulate UDP socket is very easy and allows quick implementation on the hosts.
As it is possible for the same controller to have authority for several groups, it has been decided to use a single thread that takes care of multiple groups. This thread 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 control channel. One control channel correspond to one ASM group at the network level. This thread 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.
of UDP for sending data. Therefore, to announce a group, it is only 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 various operation for this group, like advertising new sources, giving the list of the existing ones on demand and optionally making some network floor control.
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 6
Source Discovery Protocol in SSM Networks
June 2003
Beck, et al.
Expires novembre 30, 2003
[Page 7]
Once this message ON has been treated, the thread announce the source to the receivers and optionnaly send an ON_RESP to the new source to inform it about various session parameters, depending on the group management politics. 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.
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.
When a new source wants to announce itself, it MUST begin by informing the thread. The thread then stores the information about the source in its cache. To achieve robustness and scalability, this announcement is sent periodicaly with a message composed of the protocol header with a optionnal SDP payload [3][4][5]. We call this message ON. It is sent to the UDP socket of the controller’s thread. 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.
4.1.1 With a New Source
Now we will describe the interaction between a source for a group, and the controller (that means the thread responsible of source announcing ) for this group. We’ll only take a look at the source advertising, the group management control is optionnal and is described in Section 5.
4.1 Protocol Description for Source-Thread Interaction
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. ASM over SSM Emulation
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 7 Source Discovery Protocol in SSM Networks
June 2003
Beck, et al.
Expires novembre 30, 2003
[Page 8]
A source can also explicitly announce that it stops its activity by sending a message OFF to the thread, 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
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.
Periodically, a source MUST send a message ON to the thread, in order to inform it that it is still active, and the thread forwards this message on its control channel to the receivers. For each source, the thread keeps a timer ON validity which gives the time the source entry in his cache is valid. If the thread 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.
4.1.2 With an Existing Source
Figure 1 : Interaction Source - Thread for a message ON.
+-------+ +---->| Cache | 2. Cache | +-------+ update | | | 1. ON((S,G),..) +--------+ +--------+ /\ 3b. ON_RESP /\ / \ / \ Channel / \ / \ (SRC,M) /\ /\ /\ /\ / \ / \ 3a. Forwarding ON message / \ / \ | | Channel | -> +----------+ | 4. if desired, joins (S,G) +----| Receiver |-------------+ (SRC,M) +----------+
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 8
June 2003
This is the case with BYE packets from RTCP protocol.
Source Discovery Protocol in SSM Networks
We call this message a message INFO_REQ.
Source Discovery Protocol in SSM Networks
June 2003
Beck, et al.
Expires novembre 30, 2003
[Page 9]
The thread 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 thread has authority, sends him a unicast message on a known port from the receiver. This message is an UDP paquet with a payload containing the protocol header and the group identifier, which is the
4.1.3.1 Information Request
Beck, et al.
Expires novembre 30, 2003
[Page 10]
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.
This cache is used by the thread to store all the informations for a group, but the receivers have to maintain the same cache, but limited the joined applicative group. This cache is updated thanks to the messages sent on the control channel.
4.1.3 Protocol Description for Receiver-Thread Interaction
Here we describe the interaction between a receiver and the group’s thread. 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.
Figure 3 : Interaction receiver - Thread.
| | +---------------+----+------+-----+-------------------+-----+ |sending channel|port|KICKED|VOICE|coding informations|Timer| +---------------+----+------+-----+-------------------+-----+
FLAGS _____/\_____
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 :
+---------------+----------------------+---+---------+------+-------+ |control channel|second control channel|...|beginning|ending|sources| +---------------+----------------------+---+---------+------+-------+
If the thread 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), 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 :
When the thread 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 sources and enough informations for the receiver to join the corresponding channels if wanted.
couple (S,G).
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt
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.
Page 9
Figure 2 : Interaction Source - Thread for a message OFF.
+-------+ +---->| Cache | 2. Cache | +-------+ update | | 1. OFF((S,G),..) +--------+ +----------+ \ / | 4. leaves (S,G) +----| Receiver |------+-------+ (SRC,M) +----------+ / \
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 payload containing 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. If the messages OFF is lost, the source timer will expire in the Controller cache and a OFF messages will be sent in the control channel.
multicast.
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 10
Source Discovery Protocol in SSM Networks
June 2003
Beck, et al.
Expires novembre 30, 2003
[Page 11]
In the same way, when the thread 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.
When a new source announces its activity to the thread, it has to inform all the receivers. To do so, it forwards the message ON received from the source on the control channel.
4.1.3.2 Source Advertising
Figure 3 : Interaction receiver - Thread.
+----------+ 1. INFO_REQ((S,G),...) +-----------+ | | ------------------------> | | | Receiver | | Controller | | | Number of sources 0 100 200 300 400 500 600 * = IPv6. + = IPv4.
In the worst case, if there are N synchronized sources announcing themselves and located at 100 differents hosts and that all the messages arrive together at the controller, the maximum bandwidth required is a simple linear function, N*158 for IPv6 and N*90 for IPv4.
If we take the messages defined in Section 10, an ON message which contains one channel will take 158 bytes on the wire, considering that the source is transmitting on Ethernet and IPv6 and that the announced channel is IPv6. With IPv4 it will take 90 bytes considering that the announced channel is IPv4.
We consider here the problem of bandwidth scalability at the controller in the worst case with the default timers values. What is the amount of required download bandwidth at the controller point in function of the number of synchronized announcing sources ?
An important question is the scalability of this architecture, especially at the controller point. The controller is acting as a sort of Rendez vous point ala PIM, and a relay node for control messages between sources and receivers in the emulated ASM group. It is then a central point of failure, sensible to the bandwidth generated by the differents announcing sources.
9. Scalability consideration
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 20
Source Discovery Protocol in SSM Networks
June 2003
Beck, et al.
Expires novembre 30, 2003
[Page 21]
worst case and that applications with more that 100 applicatives sources at the same time are very specific and will be certainly based on the ASM network service model. Moreover thanks to the acknowledgement mechanism, it is possible to rate limit the sources at the controller. Note a that once the messages arrives at the controller, it has complete control over the bandwidth usage of its control channel.
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 21
Expires novembre 30, 2003
[Page 22]
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_RESP (01000).
Type of the message (5 bits).
Beck, et al.
T:
The current version number is 1.
V: Version Number (3 bits).
Figure 4 : Message 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 | T | Nb src | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Control Channel | +-+ | Data Channel [1] | +-+ | Data Channel [2] | +-+ . . . . . . +-+ | Data Channel [Nb src] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The sources and group addresses are described using the format described above. There is the format used by the protocol’s messages.
10.1 Protocol’s Message Format
One possibility could be to use SAP messages with as payload. However, it has only one bit of type gives us only the possibility to code 2 messages, least 10 different messages to specify. Instead, following format.
June 2003
a SDP description message, which but we have at we propose the
Source Discovery Protocol in SSM Networks
10. Messages Formats
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 22
Source Discovery Protocol in SSM Networks
June 2003
G : The Group Address : it’s the multicast address used by the controller to send data to, and it is described as specified in Section 10.2.2
*
M : The Group Address : it’s the multicast address used by the source to send data to, and it is described as specified in Section 10.2.2
*
Beck, et al.
Expires novembre 30, 2003
[Page 23]
The port isn’t specified, as, for implementation facilities, it has been decided to use the same port that the one that is announced with
The payload is an SDP description of applicative data for the session. For example, the port used can be described in this payload.
Payload
SRC : The Address of the source : it’s the unicast address of the source, and it is described as specified in Section 10.2.1
*
Following this field, there are [Nb src] Data Channels (SRC,M) descriptions. These are composed of :
Data Channel
The Control Channel is used with the port to identify the emulated group.
S : The Address of the controller : it’s the unicast address of the controller, and it is described as specified in Section 10.2.1
*
This field describes the control channel (S,G), which identifies the emulated group. This description is composed of :
Control Channel
Reserved for further extensions.
Reserved (80 bits).
Number of sources described in the message. This field announces the number Data Channels in the message which follows it. This number can be set from 0 (if no sources are described for the group) to 255 (which is in this version the maximum sources which can register for a group).
Nb src: Number of sources (8 bits).
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 23 Source Discovery Protocol in SSM Networks
June 2003
Beck, et al.
Expires novembre 30, 2003
[Page 24]
The mask length field is 8 bits. The value is the number of contiguous one bits left justified used as a mask which, combined with the Source Address, describes a source subnet. With minimal
Mask Len
Transmitted as zero, ignored on receipt.
Reserved
The type of encoding used within a specific Address Family. The value ‘0’ is reserved for this field, and represents the native encoding of the Address Family.
Encoding Type:
Values of 0-127 are as assigned by the IANA for Internet Address Families in [13]. Values 128-250 are reserved to be assigned by the IANA for PIM-specific Address Families. Values 251 though 255 are designated for private use. As there is no assignment authority for this space, collisions should be expected
Addr Family:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Reserved | Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
An Encoded-Source address takes the following format:
10.2.1 Encoded Source Address
10.2 Encoded Source and Group Address Formats
As it is possible in a source’s channel description to specify a network mask, it is possible to merge several channels which are following each other in the addresses (for example (192.168.1.2, 224.1.2.2) and (192.168.1.2, 224.1.2.3) can be described as (192.168.1.2, 224.1.2.2/31) ).
the control channel address. The same port is then used by the sources to send data to in their data channels, the controller to send data to in its control channel and to communicate in unicast between the controller and either the sources or the receivers.
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 24
Source Discovery Protocol in SSM Networks
June 2003
Ignored upon receipt.
Beck, et al.
Expires novembre 30, 2003
Contains the group address.
Group Multicast Address
[Page 25]
The Mask length field is 8 bits. The value is the number of contiguous one bits left justified used as a mask which, combined with the group address, describes a range of groups. It is less than or equal to the address length in bits for the given Address Family and Encoding Type. If the message is sent for a single group then the Mask length MUST equal the address length in bits for the given Address Family and Encoding Type. (e.g. 32 for IPv4 native encoding, 128 for IPv6 native encoding).
Mask Len
Transmitted as zero.
Reserved
Described above.
Encoding Type:
Described above.
Addr Family:
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Addr Family | Encoding Type | Reserved | Mask Len | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Group Multicast Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-...
An Encoded-Group addresses take the following format:
10.2.2 Encoded Group Address
The source’s address.
Source Address
implementation, the mask length MUST be equal to the mask length in bits for the given Address Family and Encoding Type (32 for IPv4 native and 128 for IPv6 native).
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 25 Source Discovery Protocol in SSM Networks
June 2003
Beck, et al.
Expires novembre 30, 2003
[Page 26]
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.
More security mechanisms could be imagined, like using a single session identifier per group which is only distributed between the controllers.
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.
11. Security Considerations
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 26
Source Discovery Protocol in SSM Networks
June 2003
Beck, et al.
Expires novembre 30, 2003
[Page 27]
Thanks to Stig Venaas for the valuable provided discussions and his ideas about ASM, SSM and the control channel.
12. Acknowledgments
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 27
Quinn, B. and R. Finlayson, "Session Description Protocol (SDP) Source Filters", may 2003. Fenner, B., Haberman, B., Holbrook, H. and I. Kouvelas, "Multicast Source Notification of Interest Protocol (MSNIP)", june 2003. oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", may 1993. Kalt, C., "Internet Relay Chat Protocol: Architecture", apr 2000. Kalt, C., "Internet Relay Chat Protocol: Channel Management", apr 2000. Kalt, C., "Internet Relay Chat Protocol: Client Protocol", apr 2000. Kalt, C., "Internet Relay Chat Protocol: Server Protocol", apr 2000. Fenner, B. and D. Meyer, "Multicast Source Discovery Protocol (MSDP)", may 2003. "IANA, "Address Family Numbers", linked from http:// www.iana.org/numbers.htm", august 2003.
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[Page 28]
Handley, M. and V. Jacobson, "Session Description Protocol", apr 1998.
[4]
Expires novembre 30, 2003
Handley, M., Perkins, C. and E. Whelan, "Session Announcement Protocol", oct 2000.
[3]
Beck, et al.
Chesterfield, J. and E. Schooler, "An Extensible RTCP Control Framework for Large Multimedia Distributions", april 2003.
[2]
June 2003
Holbrook, H., "A channel model for multicast", August 1991 2001.
Source Discovery Protocol in SSM Networks
[1]
References
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 28
Source Discovery Protocol in SSM Networks
Beck, et al.
Expires novembre 30, 2003
Phone: (33) 3 90 24 45 84 EMail:
[email protected] URI: http://clarinet.u-strasbg.Fr/~pansiot/
Jean-Jacques Pansiot LSIIT Pt l e API, bureau C447 Boulevard Si b astien Brant Illkirch 67400 FRANCE
Phone: (33) 3 90 24 45 86 EMail:
[email protected] URI: http://clarinet.u-strasbg.Fr/~hoerdt/
Mickak l Hoerdt LSIIT Pt l e API, bureau C444 Boulevard Si b astien Brant Illkirch 67400 FRANCE
Phone: (33) 3 90 24 45 86 EMail:
[email protected] URI: http://clarinet.u-strasbg.Fr/~beck/
Frederic Beck LSIIT Pt l e API, bureau C444 Boulevard Si b astien Brant Illkirch 67400 FRANCE
Authors’ Addresses
Internet-Draft
[Page 29]
June 2003
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 29 Source Discovery Protocol in SSM Networks
June 2003
All Rights Reserved.
Beck, et al.
Expires novembre 30, 2003
[Page 30]
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
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
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.
Copyright (C) The Internet Society (2003).
Full Copyright Statement
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.
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.
Intellectual Property Statement
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 30
Source Discovery Protocol in SSM Networks
June 2003
Beck, et al.
Expires novembre 30, 2003
[Page 31]
Funding for the RFC Editor function is currently provided by the Internet Society.
Acknowledgement
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Internet-Draft
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 31 iW
Jul 04 2003 14:30:40 draft-beck-mboned-ssm-source-discovery-protocol-03.txt Page 32
