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]
