[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03 04 05 06 RFC 2974

Internet Engineering Task Force                                MMUSIC WG
Internet Draft                                          Maryann P. Maher
draft-ietf-mmusic-sap-v2-00.txt                                      ISI
16 November 1998                                           Colin Perkins
Expires: May 30, 1998                                                UCL



                Session Announcement Protocol: Version 2


Status of this Memo


   This document is an Internet Draft. 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. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern
   Europe), ftp.nic.it (Southern Europe), munnari.oz.au (Pacific Rim),
   ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).

Abstract

   This document describes modifications and enhancements to SAP, the
   session directory announcement protocol, for support of IPv6
   conferencing environments. Along with support for IPv6, a couple new
   features are also introduced.  This document compliments [SAP], which
   fully describes SAP in the context of IPv4. Readers are assumed to be
   familiar with [SAP].

   Note: At this time, this document presents an initial set of ideas
   aimed solely at starting discussion within the working group. We
   await the RFC publication of [SAP] before finalizing any protocol
   specifications.

   This document is a product of the Multiparty Multimedia Session
   Control (MMUSIC) working group of the Internet Engineering Task
   Force. Comments are solicited and should be addressed to the working



                                                                [Page 1]


Internet-Draft               SAP Version 2                      Nov 1998


   group's mailing list at confctrl@isi.edu and/or the author.



   1.  Overview

   This document describes a new version of SAP, the session directory
   announcement protocol, for support of IPv6 conferencing environments.
   SAP is a protocol used for handling multicast and unicast session
   description packets and defines an encapsulating packet format to be
   used by session directory clients. As currently defined, only IPv4
   session announcements are supported mainly due to the fact that an
   IPv4 address field is contained in the SAP packet header.  This docu-
   ment describes the modifications to SAP for supporting IPv6 session
   announcements and introduces some additional new features. The two
   new features described in this document are:

      1) a MIME Content-Type specifier, and

      2) a URL scheme for referencing SAP announcements.

   Note: At this time, this document presents an initial set of ideas
   aimed solely at starting discussion within the working group. We
   await the RFC publication of [SAP] before finalizing any protocol
   specifications.


   2.  Modifications to the SAP Packet Format

   Current SAPv1 data packets are of the following format:

    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 | MT  |E|C|   auth len    |        msg id hash            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      originating source                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                optional authentication header                 |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       optional timeout                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     optional random field                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          text payload                         |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



                                                                [Page 2]


Internet-Draft               SAP Version 2                      Nov 1998


   In order to support session directory clients in IPv6 environments,
   the SAP packet format must be modified to contain a 128-bit IPv6
   source address instead of the 32-bit IPv4 address.

   Therefore, SAP v2 data packets are of the following format:

    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| MT|E|C|   auth len    |        msg id hash            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                      originating source                       |
   |                             ....                              |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                optional authentication header                 |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       optional timeout                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   optional random field                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        text payload                           |
   |                             ....                              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Note: the version number in the packet header has NOT changed.

   A       Address type: 0 = IPv4, 1 = IPv6

   If the A bit is 0, the orig source contains a 32-bit IPv4 address. If
   the A bit is 1, the orig source contains a 128-bit IPv6 address.


   3.  Scoping SAP Announcements

   A SAP client that announces a conference session periodically multi-
   casts an announcement packet to a well known multicast address and
   port.  The well known IPv6 SAP address is FF0X:0:0:0:0:0:2:7FFE,
   where X is the 4-bit scope value. The following scope values are
   currently defined in IPv6:








                                                                [Page 3]


Internet-Draft               SAP Version 2                      Nov 1998


           Value  Scope                  Recommended Bandwidth Limit
          ------ -----------            -----------------------------
            0x1   Node-local                  n/a
            0x2   Link-local                  20 Kbps
            0x5   Site-local                  10 Kbps
            0x8   Organization-local          1 Kbps
            0xE   Global                      200 bps

   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 being advertised.  Having
   a scope field within the address itself removes the need to carve out
   scope ranges within the multicast address space or scope addresses
   according to a corresponding TTL.  Therefore, unlike in IPv4, TTL-
   scoped announcements do not exist in IPv6 environments.  The scope
   value to be used in the well-know SAP address is simply the same used
   in the multicast address assigned for the session.

   For example, an announcement for a link-local session assigned the
   multicast address of FF02:0:0:0:0:0:1234:5678, should be advertised
   on SAP address FF02:0:0:0:0:0:2:7FFE. (Note: Issues related to IPv6
   multicast address allocation are being addressed in the MALLOC work-
   ing group.)

   In the table above, recommended bandwidth limits are given for ses-
   sions within the defined scopes. The total bandwidth to be used for
   SAP announcements should be one-fourth of the session bandwidth,
   though this may be inappropriate for some uses.




   4.  SAP Payload

   In previous versions of SAP, the payload was required to be a session
   description in the SDP format [RFC2327]. With the introduction of new
   session description formats, such as SMIL [SMIL], it is believed that
   that restriction is no longer appropriate. SAP v2 therefore allows
   for other content to be carried. That content should begin with a
   MIME Content-Type specifier.

           Content-Type: application/sdp

           v=0
           o=...

   If the content type is "application/sdp" the MIME header may be omit-
   ted, for backwards compatibility with SAP v1 applications. If any



                                                                [Page 4]


Internet-Draft               SAP Version 2                      Nov 1998


   other content is carried the MIME header MUST be present.


   5.  SAP URL scheme

   In certain cases, it is desirable to reference a SAP announcement.
   For example, if it is desired that a new participant join an existing
   session yet it is not known if that participant is within the scope
   of the announcement then an explicit reference to the announcement
   will enable them to determine if it can be received. Providing the
   session description contained within that announcement merely allows
   them to join the session, when they then notice that the media
   streams are not visible.  Moreover, the addresses contained in a ses-
   sion description for one scope may not be valid outside that scope
   zone.

   We therefore define a URL scheme for SAP announcements.  The combina-
   tion of msg-id-hash and originating-source fields in the SAP header
   is sufficient to identify a particular announcement.

   sap:msg-id@orig-source

   TBD: What is the effect of 10.x.x.x assignments on this?


   6.  Compatibility

   SAPv2 announcement are backwards compatible with SAPv1 provided that
   IPv4 sessions are announced, and that the payload is SDP with the
   content-type omitted.

   If IPv6 announcements are made, they will be discarded by SAPv1 tools
   since they represent illegal MT values in that protocol.

   If the Content-Type header is present in the payload, the announce-
   ment is invalid in SAPv1. Those tools require that SDP is used, hence
   the payload for a SAPv1 announcement MUST start with "v=".


   7.  Security Considerations

   SAP contains mechanisms for ensuring integrity of session announce-
   ments, for authenticating the origin of an announcement and for
   encrypting such announcements. The strengths and limitations of these
   mechanisms are described in the 'Security Considerations' section of
   [SAP]. Those considerations apply to this document as well.





                                                                [Page 5]


Internet-Draft               SAP Version 2                      Nov 1998


   8.  Acknowledgements

REFERENCES

   [SAP] Handley, M.J., Session Announcement Protocol, draft-ietf-
       mmusic-sap-01.txt, work in progress.

   [ADDARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing Archi-
       tecture", RFC 2373, July 1998.

   [IPV6] Deering, S., and R. Hinden, Editors, "Internet Protocol, Ver-
       sion 6 (IPv6) Specification", RFC 1883, December 1995.

   [MASGN] Hinden, R., and S. Deering, "IPv6 Multicast Address Assign-
       ments", RFC 2375, July 1998.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
       Requirement Levels", BCP 14, RFC 2119, March 1997.

   [SMIL]

   [RFC2327] Handley, M., and Jacobson, V., "SDP: Session Description
       Protocol", RFC2327, April 1998.

Author's Address

   Maryann P. Maher <maher@isi.edu>
   USC/ISI
   4350 N. Fairfax Drive, Suite 620
   Arlington VA 22203

   Colin Perkins <c.perkins@cs.ucl.ac.uk>
   Department of Computer Science
   University College London
   Gower Street
   London WC1E 6BT















                                                                [Page 6]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/