One document matched: draft-ietf-mmusic-sap-v2-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-23 17:27:11 |