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(, ) 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,,interface) And the call to stop receiving data as this: LeaveEmulatedASMGroup(s,,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 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/ 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/ Hoerdt, et al. Expires novembre 30, 2003 [Page 15] Internet-Draft ASM over SSM middleware June 2003 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/ 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]