Internet DRAFT - draft-hoerdt-mboned-multisource-ssm


Network and Protocol Team                                      M. Hoerdt
Internet-Draft                                                   F. Beck
Expires: novembre 30, 2003                                  J-J. Pansiot
                                                               June 2003

             Multi-source communications over SSM networks

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 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://

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on novembre 30, 2003.

Copyright Notice

   Copyright (C) The Internet Society (2003).  All Rights Reserved.


   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


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

   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

   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

   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


   [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

   [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 PŸle API, bureau C444
   Boulevard S‰bastien Brant
   Illkirch  67400

   Phone: (33) 3 90 24 45 86
   URI:   http://clarinet.u-strasbg.Fr/~hoerdt/

   Frederic Beck
   PŸle API, bureau C444
   Boulevard S‰bastien Brant
   Illkirch  67400

   Phone: (33) 3 90 24 45 86
   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
   PŸle API, bureau C447
   Boulevard S‰bastien Brant
   Illkirch  67400

   Phone: (33) 3 90 24 45 84
   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

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

   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

Hoerdt, et al.         Expires novembre 30, 2003               [Page 17]
Internet-Draft          ASM over SSM middleware                June 2003



   Funding for the RFC Editor function is currently provided by the
   Internet Society.

Hoerdt, et al.         Expires novembre 30, 2003               [Page 18]