Network and Protocol Team M. Hoerdt
Internet-Draft F. Beck
Expires: novembre 30, 2003 J-J. Pansiot
LSIIT
June 2003
Multi-source communications over SSM networks
draft-hoerdt-mboned-multisource-ssm-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
Classical multicast multi-sources applications use the Deering's [1]
ASM group communication model where anyone, including non-members,
can send packets with one local operation to a group identifier G
with best effort guarantees that its packet will be transmitted to
all group members: the network duplicates packets and manages the
dynamics of source and receivers. With the new Holbrook's [3] SSM
model it is the responsibility of applications to tell the network
who are their sources of interest. As a consequence, the SSM model
is well suited for TV-like (one to many) applications because there
is only one source to discover and it's supposed to be well known.
Hoerdt, et al. Expires novembre 30, 2003 [Page 1]
Internet-Draft ASM over SSM middleware June 2003
But there is still missing an SSM session layer or middleware for
applications helping multi-sources applications to discover the
presence/leaving source in case of SSM model. We give here a
possible implementation for this Source discovery session layer
according to the protocol defined in [5].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. ASM emulation over SSM network service . . . . . . . . . . . . 5
2.1 properties of Deering's ASM networks groups . . . . . . . . . 5
2.2 Different cases for emulation . . . . . . . . . . . . . . . . 6
3. Implementation consideration . . . . . . . . . . . . . . . . . 8
3.1 Sending to the group . . . . . . . . . . . . . . . . . . . . . 8
3.2 Receiving from the group . . . . . . . . . . . . . . . . . . . 9
4. Source discovery as a service . . . . . . . . . . . . . . . . 11
5. Porting ASM applications with this service . . . . . . . . . . 12
5.1 ASM emulation over UDP sockets . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . 17
Hoerdt, et al. Expires novembre 30, 2003 [Page 2]
Internet-Draft ASM over SSM middleware June 2003
1. Introduction
Today almost all unreliable multicast applications use the socket
abstraction with the MROUTE implementation from Steve Deering. It
means having an IP socket and manipulates it via setsockopt calls to
tell the network that the application is interested in an IP
multicast flow.
In the ASM service model without IGMPv3 [2] filtering, the flow is
identified by G, where anyone on the Internet can send. With IGMPv3,
applications can tell the network which are the sources of interest
or to exclude. On the same socket, with the current implementation /
specification it's not possible to specify the sources of interest
AND the sources to exclude, two sockets have to be created.
If a socket is in EXCLUDE{A} mode, all the sources, except A, will be
forwarded on the local network. If a socket is in INCLUDE{A}, only
the multicast data coming from source A will be forwarded on the
network. Both on the socket abstraction and on the network, EXCLUDE
mode have priority over INCLUDE mode, it means that if an application
wants to have an exact filter of allowed IPs sources to transmit in
the group G, it has to know all of them. This is difficult with
applications containing some kind of source dynamics.
With the ASM model [1], an application knows that a source exists
only after the first packet transmitted to the group on the network.
As a consequence if applications are not aware of this, it is very
easy to disturb an ASM group with unwanted data at least with
bandwidth hijacking. This is because control plane and data plane
are mixed with the ASM model and the network is responsible for
source discovery.
With the SSM model [3], the only existing socket mode is INCLUDE and
applications have to discover new sources on their own. A socket
which is in the state INCLUDE{A,B,C} for a group G, is a socket which
is listening for the channels (A,G), (B,G) and (C,G). It means that
applications have more control over their data reception and are
insured that only data coming from {A,B,C} and destined to the
channel G will be present on the network. It also means too that
there is a missing session layer for source discovery in the case of
multiple dynamic source applications.
We have defined a basic protocol of operation for this session layer
in [5]. We then define what a source discovery mechanism at the
application layer should be and call it "ASM emulation over SSM
service" in section 2. Then we take a look at implementation
considerations knowing that the main multicast implementation
existing today is the MROUTING or derived version from Steeve
Hoerdt, et al. Expires novembre 30, 2003 [Page 3]
Internet-Draft ASM over SSM middleware June 2003
Deering.
Hoerdt, et al. Expires novembre 30, 2003 [Page 4]
Internet-Draft ASM over SSM middleware June 2003
2. ASM emulation over SSM network service
First we recall what exactly a group in the ASM model is. Second we
consider the different cases to consider when doing ASM emulation
over SSM service.
2.1 properties of Deering's ASM networks groups
A network group in the ASM service model is a set of zero or more
binded interfaces to receive or send data to the same group
identifier G taken in the IP multicast address space. In this group,
we can distinguish:
- receive only interfaces (called passive members in the remainder
of this draft)
- send only interfaces (called actives members in the remainder of
this draft)
- both send and receive interface (called dual members in the
remainder of this draft).
In the ASM Deering model, we have a group identifier G which can be
composed of passive members, active members and dual members, there
IS NO distinction and any passive members can become active members
at any moment and vice versa. A dual member switches between the two
states in an undefined manner. In addition, there is no obligation
to join the group (i.e be a passive member) to send data to it: the
group is open.
A group in the SSM Holbrook's service model has more restrictions and
as a consequence more control. The group identifier is still taken
in the IP multicast address space (disjoint from the ASM address
space) BUT it only identifies a set of passive members where only one
host (not necessarily a passive member) is chosen freely by the
passive members to transmit packets. Even with this strong
hypothesis, the group is still open, according to Deering's
definition as the source do not necesseraly belong the the group.
It means that as in ASM, (S,G) and (S1,G) flows will be delivered to
the same set of passive members (we are not considering IGMPv3
filtering + ASM). In SSM, (S,G) and (S1,G) flows may refer to a
totally different set of passive members.
Considering this key difference, the challenge of ASM model over SSM
network service emulation can be defined as follows:
At any time, having a set of channels (S,G), (S1,G1) ... (Sn,Gn)
Hoerdt, et al. Expires novembre 30, 2003 [Page 5]
Internet-Draft ASM over SSM middleware June 2003
with G, G1, ... Gn referring to the same set S, S1, ... Sn of dual
members (hosts). This emulation must take into account the strong
hypothesis that dual members, passive members and actives members may
come and go at any time.
2.2 Different cases for emulation
We consider the differents degrees of being dynamic:
- dual members dynamics
- passive members dynamics
- active members dynamics
Case 1: Both passive and active static members
If we consider the simplifying hypothesis that the group is static,
(i.e. it is always composed of the same set of dual members during
the entire application duration.) Each member may know each other via
some simple static or administrative configuration.
Each S1, S2, ... Sn, dual member may synchronize on a common G and
join (S1,G), (S2,G), ... (S3,G) channels. Then, we have an ASM
model over SSM network service with the only difference that the
group is not open, it's restricted to S1, S2, ... Sn and no new
sources may appear. This solution is efficient in term of delay
because, after the setup of different source trees between each dual
member, senders "just send" and the paths from the senders to the
receivers are already established.
Case 2: Dynamic active members and static passive members
We consider a set of active source changing over time. This means
that the set of SSM channels change over the time. The passive
members are static. This case may not seem realistic but imagine an
application with a fixed set of passive members M1, M2, ... Mn
waiting for some data feed from different sources changing over the
time (which can be a subset of the passive members). In this case,
each passive member may be listening to a central authority
announcing the arrival/departure of new active members during the
session life-time.
Case 3: Dynamic passive members and static active members
We consider that the set of sources does not change over time. So,
at any time each passive member can join the (S1,G1), (S2,G1) ...
(Sn,Gn) channels from the set of active members and leave them when
Hoerdt, et al. Expires novembre 30, 2003 [Page 6]
Internet-Draft ASM over SSM middleware June 2003
they leave the emulated ASM group. As long as the passive members do
not have to communicate with each other (they are passive members) it
is a viable solution because the active members can still communicate
with the passive members via the channels.
Case 4: Both active and passive dynamic members
This is the most difficult case but the most realistic too,
especially when we consider that many control protocols (like RTCP)
require feedback from both parties. The set of sources change during
time and the set of receivers too. So at any time, each passive
member has to listen to some well known central dynamic live service
announcing the departure and arrival of sources. Contrary to case
two, a passive member may become an active member for any reason and
must contact this dynamic live service to announce its arrival. In
this case we have an ASM model over SSM network service with the only
difference that the end hosts are managing the active source
dynamicity in the group.
We have seen the main differences between ASM and SSM models, We
showed that in case of active members dynamicity there is a need for
source discovery mechanism placed somewhere at the end hosts, as we
consider that the network is only offering SSM network service model.
We now define an architecture for this dynamic source announce.
Hoerdt, et al. Expires novembre 30, 2003 [Page 7]
Internet-Draft ASM over SSM middleware June 2003
3. Implementation consideration
The basic idea is to use a well known IP control channel (S,G)
between the passive and active members where all control messages
are transmitted. Passive members listen to this control channel and
join the active data channels being announced there.
Active members announce themselves as active to S. and S announces
the new active members to (S,G). In the remainder of this paper, in
the (S,G) control channel, we will call S "the controller".
The announcement MUST not be implemented in the application but in a
sort of middleware to allow maximum reusability. We define the
behavior of this middleware here. The control channel architecture
MUST run on top of UDP for ease of implementation and portability.
As a consequence, the middleware must not only listen to the control
channel, but bind the control socket to the right UDP port. For the
application developers and especially for "ASM receiver only
applications", the primitives MUST be as to the RFC 1112 primitives
as possible.
3.1 Sending to the group
In the ASM model implementation, applications send UDP multicast data
the same way that they transmit unicast DATA except that the
destination is included in the 224/8 range for IPv4 or FF::/8 for
IPv6 : Senders "just send".
This paradigm cannot be straightforward applied with our architecture
and a new sender has to announce itself to the controller before it
can send to the set of passive member (i.e the passive members have
joined the data channels of the new source).
There can be some interaction between the controller and an
application. For example, a source may require an authorization
before it is announced in the control channel. In a simple
implementation, there may be no interaction at all. The most simple
interaction is to allow every sources to send to the group. With
this simple implementation there is the same behavior as in the ASM
model except that the passive members have the choice to join the
announced sources, depending of their bandwidth capabilities or their
interest to the content.
As a consequence, along with every new transmission to some (S1,G1)
channel where the data is destined to the same group of passive
members who have subscribed to the (S,G) control channel, the
middleware has to contact the controller S from (S,G) channel via
Hoerdt, et al. Expires novembre 30, 2003 [Page 8]
Internet-Draft ASM over SSM middleware June 2003
unicast. We define the call like this:
Register_a_source(<emulated ASM group address>, <New data source
channel info>)
Where the emulated ASM group address is an unique tuple (S,G,P) where
S is the address of the controller, G an identifier for the control
channel and P a port number where the middleware controller is
waiting for registration. This port may be chosen arbitrary by the
middleware as soon as it is correctly announced to new potential
sources before the group session start.
The new data source channel info contains enough information for a
remote host to receive data from this new source. This includes:
- The address of the new source (mandatory)
- The Channel identifier from the new source (mandatory)
- Transport information. (optional, may only be used by the
application)
The middleware is responsible for contacting the controller and
waiting for some error messages to warn the application.
An application may decide to start transmission to (S1,G1) before or
after the registration depending on the requirements. Note that with
MSNIP [4] the application can delay transmission until receivers are
present.
Note that this mechanism is very similar to the PIM-register
architecture, except from the fact that there is currently no
specification defined to communicate between the Rendezvous Point and
the Group creator and that we are placing these mechanisms at the end
hosts, which mean more flexibility for applications.
Moreover, The control plane of this mechanism is on top of UDP (for
ease of implementation and possibly multiple running controller per
hosts), and the data plane for receivers and sources is on top of IP.
It potentially allow every ASM over IP applications to be ported with
this sources discovery mechanism. Section Section 5 gives some
advices to port classical ASM applications over this service.
3.2 Receiving from the group
Classical ASM applications who want receive UDP multicast first tell
the network that they want to do it and after that call the recvfrom
primitive from the kernel to receive any packet destined to the
Hoerdt, et al. Expires novembre 30, 2003 [Page 9]
Internet-Draft ASM over SSM middleware June 2003
registered socket.
With the SSM emulation layer architecture, the middleware has to
register to the control channel (which identified the group) and wait
for info about it constantly and modifies the registered channels and
informs the socket application about source arrivals and departures
according to the rules given to the middleware. In [1] Deering
defined to new operations provided at the socket IP layer:
JoinHostGroup ( group-address, interface )
LeaveHostGroup ( group-address, interface )
With the source discovery middleware architecture, there is one
indirection:
We define the call to receive data as this:
JoinEmulatedASMGroup(s,<emulated Group address>,interface)
And the call to stop receiving data as this:
LeaveEmulatedASMGroup(s,<emulated Group address>,interface)
Where s is the socket abstraction from the application, and emulated
Group Address is the (S,G,P) group identifier and control channel
where S is the unicast address of the controller, G the control
channel identifier and P the same port identifier used by the
middleware to register a new source defined in the last section.
Register_a_source, JoinEmulatedASMGroup and LeaveEmulatedASMGroup
functions MUST return immediately (i.e., they are non-blocking
operations), indicating success or failure. Function may fail due to
an invalid emulated group address or interface identifier.
Register_a_source may fail due to lack of controller resources or
authentification failure or because the group is already registered
locally or in the controller cache. LeaveEmulatedASM Group may fail
because the host does not belong to the given emulated group on the
given interface. LeaveEmulatedGroup may succeed, but the membership
persists for the middleware, if more than one socket has requested
membership in the same group.
Hoerdt, et al. Expires novembre 30, 2003 [Page 10]
Internet-Draft ASM over SSM middleware June 2003
4. Source discovery as a service
With a good usage of these primitives, some provider can propose a
"Simple source discovery mechanism" based on these mechanisms. This
is important because a running application may not have enough
bandwidth to handle the entire control message burden generated by
this "ASM over SSM emulation".
Running as a service, it has to be usable for several groups and for
several types of applications, knowing that applications may be
listening or sending to several groups. As a service, it can be run
anywhere on the network (including on the local machine) and there
can be some administrative or technical limitations to the number of
served groups. As it is run as a service too, there has to be some
authentification mechanisms before the group creation to allow
someone to use this service.
As it runs as a service, we have to define the communication between
the application user group operator (which is different from the
controller) and the controller. This communication, composed of
administrative message, has to be as generic as possible since many
kinds of applications may use this service.
Hoerdt, et al. Expires novembre 30, 2003 [Page 11]
Internet-Draft ASM over SSM middleware June 2003
5. Porting ASM applications with this service
We consider here simple UDP applications with only one data socket
used for receiving and transmitting informations to an ASM group.
Many interdomain applications use this socket for communication. It
should be noticed that if the applications is running on top of UDP,
the receivers and the sources have to synchronize themselves on a
common port where the source are sending and the receiver have bound
their sockets.
5.1 ASM emulation over UDP sockets
To fully emulate the ASM emulation for a tuple (G,P) where G is an IP
address from the multicast range and P a port number (for RTCP for
example), an application developer has to call both
JoinEmulatedASMGroup and Register_a_source on a previously created
socket with the Emulated ASM Group composed of the tuple (S,G1,P)
where S is the IP or the DNS name of the controller, G1 an IP address
taken in the SSM address range and P the same port number as in ASM.
Practically, it means finding where the application joins the ASM
group, and replacing it with JoinEmulatedASMGroup and find where the
application sends data to the group and calling Register_a_source
before it. But note that Register_a_source should typically be
called only once.
Note that even if the application is running over UDP, the middleware
MUST NOT modify other socket behavior than its IP behavior. Even if
there is transport information contained in the registration phase,
they MUST only be used to inform the application.
For this implementation to be possible, host multicast
implementations MUST be able to bind a socket to multiple ports and
multicast addresses as the only access to the application from the
middleware is a data socket where multiple sources can send toward
multiple channels and port numbers.
A source may emit toward different channels for the same emulated ASM
group. It means calling Register_as_source with the same Emulated
address but indicating another channel possibly from a different
owner. It opens new possibilities not present in the ASM model.
There may be applications where the receivers know the sources but
sources don't know the receivers. There may be protocols who needs a
pure ASM behavior like the RTCP protocol. It is up to the
application developer to determine what the best appropriate mode is
in the operation of his application.
Hoerdt, et al. Expires novembre 30, 2003 [Page 12]
Internet-Draft ASM over SSM middleware June 2003
6. Security Considerations
Security considerations are analyzed in another document [5]
describing the protocol, and the messages of operations.
Hoerdt, et al. Expires novembre 30, 2003 [Page 13]
Internet-Draft ASM over SSM middleware June 2003
7. Acknowledgments
Thanks to Stig Venaas for the valuable provided discussions and his
idea about ASM, SSM and the control channel.
Hoerdt, et al. Expires novembre 30, 2003 [Page 14]
Internet-Draft ASM over SSM middleware June 2003
References
[1] Deering, S., "Host extensions for IP multicasting", STD 5, RFC
1112, August 1989.
[2] Cain, B., Deering, S., Kouvelas, I., Fenner, B. and A.
Thyagarajan, "Internet Group Management Protocol, Version 3",
RFC 3376, October 2002.
[3] Cain, B. and H. Holbrook, "Source-Specific Multicast for IP",
draft-holbrook-ssm-arch-03 (work in progress), November 2001.
[4] Fenner, B., "Multicast Source Notification of Interest Protocol
(MSNIP)", draft-ietf-magma-msnip-04 (work in progress), June
2003.
[5] Hoerdt, M., Beck, F. and JJ. Pansiot, "Source Discovery Protocol
in SSM Networks",
draft-beck-mboned-ssm-source-discovery-protocol-00 (work in
progress), June 2003.
Authors' Addresses
Hoerdt Mickael
LSIIT Ple API, bureau C444
Boulevard Sbastien Brant
Illkirch 67400
FRANCE
Phone: (33) 3 90 24 45 86
EMail: hoerdt@clarinet.u-strasbg.fr
URI: http://clarinet.u-strasbg.Fr/~hoerdt/
Frederic Beck
LSIIT
Ple API, bureau C444
Boulevard Sbastien Brant
Illkirch 67400
FRANCE
Phone: (33) 3 90 24 45 86
EMail: beck@clarinet.u-strasbg.fr
URI: http://clarinet.u-strasbg.Fr/~beck/
Hoerdt, et al. Expires novembre 30, 2003 [Page 15]
Internet-Draft ASM over SSM middleware June 2003
Jean-Jacques Pansiot
LSIIT
Ple API, bureau C447
Boulevard Sbastien Brant
Illkirch 67400
FRANCE
Phone: (33) 3 90 24 45 84
EMail: pansiot@clarinet.u-strasbg.fr
URI: http://clarinet.u-strasbg.Fr/~pansiot/
Hoerdt, et al. Expires novembre 30, 2003 [Page 16]
Internet-Draft ASM over SSM middleware 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
Hoerdt, et al. Expires novembre 30, 2003 [Page 17]
Internet-Draft ASM over SSM middleware 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.
Hoerdt, et al. Expires novembre 30, 2003 [Page 18]