Network Working Group M. Handley
Request for Comments: 2974 ACIRI
Category: Experimental C. Perkins
USC/ISI
E. Whelan
UCL
October 2000
Session Announcement Protocol
Status of this Memo
This memo defines an Experimental Protocol for the Internet
community. It does not specify an Internet standard of any kind.
Discussion and suggestions for improvement are requested.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2000). All Rights Reserved.
Abstract
This document describes version 2 of the multicast session directory
announcement protocol, Session Announcement Protocol (SAP), and the
related issues affecting security and scalability that should be
taken into account by implementors.
1 Introduction
In order to assist the advertisement of multicast multimedia
conferences and other multicast sessions, and to communicate the
relevant session 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
other session directories such that potential remote participants 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. Sessions are described using the session
description protocol which is described in a companion memo [4].
Handley, et al. Experimental [Page 1]RFC 2974 Session Announcement Protocol October 2000
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 are within the scope 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 are
within the scope of the session the announcement describes. There are
a number of possibilities:
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).
Handley, et al. Experimental [Page 2]RFC 2974 Session Announcement Protocol October 2000
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.
datatracker.ietf.org