rfc2974.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,012 行 · 第 1/3 页

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.

   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.

   Ensuring that a description is not used by a potential participant
   outside the session scope is not addressed in this memo.

   SAP announcements MUST be sent on port 9875 and SHOULD be sent with
   an IP time-to-live of 255 (the use of TTL scoping for multicast is
   discouraged [7]).

   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, et al.               Experimental                      [Page 3]

RFC 2974             Session Announcement Protocol          October 2000


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 announcers 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 initializes 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.  At time
   tn the announcer SHOULD recalculate the next transmission time.  If
   the new value of tn is before the current time, the announcement is
   sent immediately.  Otherwise the transmission is rescheduled for the
   new tn.  This reconsideration prevents transient packet bursts on
   startup and when a network partition heals.




Handley, et al.               Experimental                      [Page 4]

RFC 2974             Session Announcement Protocol          October 2000


4  Session Deletion

   Sessions may be deleted in one of several ways:

   Explicit Timeout The session description payload may contain
      timestamp information specifying the start- and end-times of the
      session.  If the current time is later than the end-time of the
      session, then the session SHOULD be deleted from the receiver's
      session cache.

   Implicit Timeout A session announcement message should be received
      periodically for each session description in a receiver's session
      cache.  The announcement period can be predicted by the receiver
      from the set of sessions currently being announced.  If a session
      announcement message has not been received for ten times the
      announcement period, or one hour, whichever is the greater, then
      the session is deleted from the receiver's session cache.  The one
      hour minimum is to allow for transient network partitionings.

   Explicit Deletion A session deletion packet is received specifying
      the session to be deleted.  Session deletion packets SHOULD have a
      valid authentication header, matching that used to authenticate
      previous announcement packets.  If this authentication is missing,
      the deletion message SHOULD be ignored.

5  Session Modification

   A pre-announced session can be modified by simply announcing the
   modified session description.  In this case, the version hash in the
   SAP header MUST be changed to indicate to receivers that the packet
   contents should be parsed (or decrypted and parsed if it is
   encrypted).  The session itself, as distinct from the session
   announcement, is uniquely identified by the payload and not by the
   message identifier hash in the header.

   The same rules apply for session modification as for session
   deletion:

    o Either the modified announcement must contain an authentication
      header signed by the same key as the cached session announcement
      it is modifying, or:

    o The cached session announcement must not contain an authentication
      header, and the session modification announcement must originate
      from the same host as the session it is modifying.






Handley, et al.               Experimental                      [Page 5]

RFC 2974             Session Announcement Protocol          October 2000


   If an announcement is received containing an authentication header
   and the cached announcement did not contain an authentication header,
   or it contained a different authentication header, then the modified
   announcement MUST be treated as a new and different announcement, and
   displayed in addition to the un-authenticated announcement.  The same
   should happen if a modified packet without an authentication header
   is received from a different source than the original announcement.

   These rules prevent an announcement having an authentication header
   added by a malicious user and then being deleted using that header,
   and it also prevents a denial-of-service attack by someone putting
   out a spoof announcement which, due to packet loss, reaches some
   participants before the original announcement.  Note that under such
   circumstances, being able to authenticate the message originator is
   the only way to discover which session is the correct session.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | V=1 |A|R|T|E|C|   auth len    |         msg id hash           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   :                originating source (32 or 128 bits)            :
   :                                                               :
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    optional authentication data               |
   :                              ....                             :
   *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
   |                      optional payload type                    |
   +                                         +-+- - - - - - - - - -+
   |                                         |0|                   |
   + - - - - - - - - - - - - - - - - - - - - +-+                   |
   |                                                               |
   :                            payload                            :
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 1: Packet format

6  Packet Format

   SAP data packets have the format described in figure 1.

   V: Version Number. The version number field MUST be set to 1 (SAPv2
      announcements which use only SAPv1 features are backwards
      compatible, those which use new features can be detected by other
      means, so the SAP version number doesn't need to change).




Handley, et al.               Experimental                      [Page 6]