Subject: SAP

From: [email-masked] (Raphael Massin)
Date: Wed, 10 Mar 1999 13:54:45 +0100

Hello all,

I am looking for the draft about SAP 'Session Annoucement Protocol'.
Maybe it expired because i can't find it at ftp.ietf.org/internet-drafts

Can you tell me where i will find it, please ?

Regards,

	Raphael

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Sandrine Roth <[email-masked]>
Date: Fri, 12 Mar 1999 09:57:58 +0100

> This message came from the IETF IPTEL Working Group Mailing List.

See attachment SAP v2

Regards,

Sandrine

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 [email-masked] 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 <[email-masked]>
   USC/ISI
   4350	N. Fairfax Drive, Suite	620
   Arlington VA	22203

   Colin Perkins <[email-masked]>
   Department of Computer Science
   University College London
   Gower Street
   London WC1E 6BT

							        [Page 6]

---

From: Colin Perkins <[email-masked]>
Date: Fri, 12 Mar 1999 17:01:27 +0000

>> Can you tell me where i will find it, please ?

The SAP v2 draft provides a few extensions to the base SAP spec, but is not
complete by itself. The main spec has expired, but I have a copy online at
http://www.cs.ucl.ac.uk/staff/c.perkins/internet-drafts/draft-ietf-mmusic-sap-00.txt

There will be a merger of the base spec, security and v2 drafts in the
not-too-distant future.

Cheers,
Colin

---------