INTERNET-DRAFT 21 October 1999 Mark Handley ACIRI Colin Perkins UCL Edmund Whelan UCL Session Announcement Protocol draft-ietf-mmusic-sap-v2-03.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 document is a product of the Multiparty Multimedia Session Control working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at confctrl@isi.edu and/or the authors. Abstract This document describes version 2 of the multicast session directory announcement protocol, SAP, and the related issues affecting security and scalability that should be taken into account by the implementors of multicast session directory tools. 1 Introduction In order to assist the advertisement of multicast multimedia conferences and other multicast sessions, and to communicate the relevant session Handley/Perkins/Whelan Page 1 INTERNET-DRAFT 21 October 1999 setup information to prospective participants, a distributed session directory may be used. An instance of such a session directory periodically multicasts packets containing a description of the session, and these advertisements are received by potential participants who can use the session description to start the tools required to participate in the session. This memo describes the issues involved in the multicast announcement of session description information and defines an announcement protocol to be used by session directory clients. Sessions are described using the session description protocol which is described in a companion memo [4]. 2 Terminology A SAP announcer periodically multicasts an announcement packet to a well known multicast address and port. The announcement is multicast with the same scope as the session it is announcing, ensuring that the recipients of the announcement can also be potential recipients of the session the announcement describes (bandwidth and other such constraints permitting). This is also important for the scalability of the protocol, as it keeps local session announcements local. A SAP listener learns of the multicast scopes it is within (for example, using the Multicast-Scope Zone Announcement Protocol [5]) and listens on the well known SAP address and port for those scopes. In this manner, it will eventually learn of all the sessions being announced, allowing those sessions to be joined. The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT', `SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this document are to be interpreted as described in [1]. 3 Session Announcement As noted previously, a SAP announcer periodically sends an announcement packet to a well known multicast address and port. There is no rendezvous mechanism - the SAP announcer is not aware of the presence or absence of any SAP listeners - and no additional reliability is provided over the standard best-effort UDP/IP semantics. That announcement contains a session description and SHOULD contain an authentication header. The session description MAY be encrypted although this is NOT RECOMMENDED (see section 7). A SAP announcement is multicast with the same scope as the session it is announcing, ensuring that the recipients of the announcement Handley/Perkins/Whelan Page 2 INTERNET-DRAFT 21 October 1999 can also be potential recipients of the session being advertised. There a number of possiblities: IPv4 global scope sessions use multicast addresses in the range 224.2.128.0 - 224.2.255.255 with SAP announcements being sent to 224.2.127.254 (note that 224.2.127.255 is used by the obsolete SAPv0 and MUST NOT be used). IPv4 administrative scope sessions using administratively scoped IP multicast as defined in [7]. The multicast address to be used for announcements is the highest multicast address in the relevant administrative scope zone. For example, if the scope range is 239.16.32.0 - 239.16.33.255, then 239.16.33.255 is used for SAP announcements. IPv6 sessions are announced on the address FF0X:0:0:0:0:0:2:7FFE where X is the 4-bit scope value. For example, an announcement for a link-local session assigned the address FF02:0:0:0:0:0:1234:5678, should be advertised on SAP address FF02:0:0:0:0:0:2:7FFE. SAP announcements MUST be sent on port 9875 and SHOULD be sent with an IP time-to-live of 255. If a session uses addresses in multiple administrative scope ranges, it is necessary for the announcer to send identical copies of the announcement to each administrative scope range. It is up to the listeners to parse such multiple announcements as the same session (as identified by the SDP origin field, for example). The announcement rate for each administrative scope range MUST be calculated separately, as if the multiple announcements were separate. Multiple announcers may announce a single session, as an aid to robustness in the face of packet loss and failure of one or more announcers. The rate at which each announcer repeats its announcement MUST be scaled back such that the total announcement rate is equal to that which a single server would choose. Announcements made in this manner MUST be identical. If multiple announcements are being made for a session, then each announcement MUST carry an authentication header signed by the same key, or be treated as a completely separate announcement by listeners. An IPv4 SAP listener SHOULD listen on the IPv4 global scope SAP address and on the SAP addresses for each IPv4 administrative scope zone it is within. The discovery of administrative scope zones is outside the scope of this memo, but it is assumed that each SAP listener within a particular scope zone is aware of that scope zone. A SAP listener which supports IPv6 SHOULD also listen to the IPv6 SAP addresses. Handley/Perkins/Whelan Page 3 INTERNET-DRAFT 21 October 1999 3.1 Announcement Interval The time period between repetitions of an announcement is chosen such that the total bandwidth used by all announcements on a single SAP group remains below a preconfigured limit. If not otherwise specified, the bandwidth limit SHOULD be assumed to be 4000 bits per second. Each announcer is expected to listen to other announcements in order to determine the total number of sessions being announced on a particular group. Sessions are uniquely identified by the combination of the message identifier hash and originating source fields of the SAP header (note that SAP v0 clients always set the message identifier hash to zero, and if such an announcement is received the entire message MUST be compared to determine uniqueness). Announcements are made by periodic multicast to the group. The base interval between announcements is derived from the number of announcements being made in that group, the size of the announcement and the configured bandwidth limit. The actual transmission time is derived from this base interval as follows: 1.The announcer initialises the variable tp to be the last time a particular announcement was transmitted (or the current time if this is the first time this announcement is to be made). 2.Given a configured bandwidth limit in bits/second and an announcement of ad_size bytes, the base announcement interval in seconds is interval =max(300; (8*no_of_ads*ad_size)=limit) 3.An offset is calculated based on the base announcement interval offset= rand(interval* 2=3)-(interval=3) 4.The next transmission time for an announcement derived as tn =tp+ interval+ offset The announcer then sets a timer to expire at tn and waits. When this timer expires, the announcement is transmitted. If, at some time tc AT&T Center for Internet Research at ICSI, International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, CA 94704, USA Colin Perkins Department of Computer Science, University College London, Gower Street, London, WC1E 6BT, UK Edmund Whelan Department of Computer Science, University College London, Gower Street, London, WC1E 6BT, UK References [1] S. Bradner. Key words for use in RFCs to indicate requirement levels, March 1997. RFC2119. [2] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer. OpenPGP message format, November 1998. RFC2440. [3] P. Deutsch and J.-L. Gailly. Zlib compressed data format specification version 3.3, May 1996. RFC1950. [4] M. Handley and V. Jacobson. SDP: Session Description Protocol, April 1998. RFC2327. [5] M. Handley, D. Thaler, and R. Kermode. Multicast-scope zone announcement protocol (MZAP), February 1999. Work in progress. Handley/Perkins/Whelan Page 15 INTERNET-DRAFT 21 October 1999 [6] R. Housley. Cryptographic message syntax. Work in progress, April 1999. draft-ietf-smime-cms-13.txt. [7] D. Mayer. Administratively scoped IP multicast, July 1998. RFC2365. [8] D. Mills. Network time protocol version 3, March 1992. RFC1305. Handley/Perkins/Whelan Page 16