idnits 2.17.1 draft-ietf-mmusic-sap-v2-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 17 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 46 instances of too long lines in the document, the longest one being 4 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 4 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 116 has weird spacing: '...d on an addre...' == Line 191 has weird spacing: '...(eg: if a new...' == Line 551 has weird spacing: '... Format speci...' == Line 616 has weird spacing: '...ability and c...' == Line 778 has weird spacing: '...Deutsch and J...' == (2 more instances...) == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (23 August 1999) is 9013 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2440 (ref. '2') (Obsoleted by RFC 4880) ** Downref: Normative reference to an Informational RFC: RFC 1950 (ref. '3') ** Obsolete normative reference: RFC 2327 (ref. '4') (Obsoleted by RFC 4566) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 1305 (ref. '8') (Obsoleted by RFC 5905) Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT 23 August 1999 3 Mark Handley 4 ACIRI 5 Colin Perkins 6 UCL 7 Edmund Whelan 8 UCL 10 Session Announcement Protocol 11 draft-ietf-mmusic-sap-v2-02.txt 13 Status of this memo 15 This document is an Internet-Draft and is in full conformance with all 16 provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering Task 19 Force (IETF), its areas, and its working groups. Note that other groups 20 may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months and 23 may be updated, replaced, or obsoleted by other documents at any time. It 24 is inappropriate to use Internet-Drafts as reference material or to cite 25 them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This document is a product of the Multiparty Multimedia Session Control 34 working group of the Internet Engineering Task Force. Comments are 35 solicited and should be addressed to the working group's mailing list at 36 confctrl@isi.edu and/or the authors. 38 Abstract 40 This document describes version 2 of the multicast session directory 41 announcement protocol, SAP, and the related issues affecting security 42 and scalability that should be taken into account by the implementors 43 of multicast session directory tools. 45 1 Introduction 47 In order to assist the advertisement of multicast multimedia conferences 48 and other multicast sessions, and to communicate the relevant session 49 setup information to prospective participants, a distributed session 50 directory may be used. An instance of such a session directory periodically 51 multicasts packets containing a description of the session, and these 52 advertisements are received by potential participants who can use 53 the session description to start the tools required to participate 54 in the session. 56 This memo describes the issues involved in the multicast announcement 57 of session description information and defines an announcement protocol 58 to be used by session directory clients. Sessions are described 59 using the session description protocol which is described in a companion 60 memo [4]. 62 2 Terminology 64 A SAP announcer periodically multicasts an announcement packet to 65 a well known multicast address and port. The announcement is multicast 66 with the same scope as the session it is announcing, ensuring that 67 the recipients of the announcement can also be potential recipients 68 of the session the announcement describes (bandwidth and other such 69 constraints permitting). This is also important for the scalability 70 of the protocol, as it keeps local session announcements local. 72 A SAP listener learns of the multicast scopes it is within (for example, 73 using the Multicast-Scope Zone Announcement Protocol [5]) and listens 74 on the well known SAP address and port for those scopes. In this 75 manner, it will eventually learn of all the sessions being announced, 76 allowing those sessions to be joined. 78 The key words `MUST', `MUST NOT', `REQUIRED', `SHALL', `SHALL NOT', 79 `SHOULD', `SHOULD NOT', `RECOMMENDED', `MAY', and `OPTIONAL' in this 80 document are to be interpreted as described in [1]. 82 3 Session Announcement 84 As noted previously, a SAP announcer periodically sends an announcement 85 packet to a well known multicast address and port. There is no rendezvous 86 mechanism - the SAP announcer is not aware of the presence or absence 87 of any SAP listeners - and no additional reliability is provided 88 over the standard best-effort UDP/IP semantics. 90 That announcement contains a session description and SHOULD contain 91 an authentication header. The session description MAY be encrypted 92 although this is NOT RECOMMENDED (see section 8). 94 A SAP announcement is multicast with the same scope as the session 95 it is announcing, ensuring that the recipients of the announcement 96 can also be potential recipients of the session being advertised. 97 There are four possiblities: 99 IPv4 global scope sessions use multicast addresses in the range 100 224.2.128.0 - 224.2.255.255 with SAP announcements being sent 101 to 224.2.127.254 (note that 224.2.127.255 is used by the obsolete 102 SAPv0 and MUST NOT be used). 104 IPv4 administrative scope sessions using administratively scoped 105 IP multicast as defined in [7]. The multicast address to be 106 used for announcements is the highest multicast address in the 107 relevant administrative scope zone. For example, if the scope 108 range is 239.16.32.0 - 239.16.33.255, then 239.16.33.255 is used 109 for SAP announcements. 111 IPv6 sessions are announced on the address FF0X:0:0:0:0:0:2:7FFE 112 where X is the 4-bit scope value. For example, an announcement 113 for a link-local session assigned the address FF02:0:0:0:0:0:1234:5678, 114 should be advertised on SAP address FF02:0:0:0:0:0:2:7FFE. 116 Directory sessions are announced on an address which is itself announced 117 by a SAP announcement. See section 6 for details for directory 118 sessions. 120 SAP announcements MUST be sent on port 9875 and SHOULD be sent with 121 an IP time-to-live of 255. 123 If a session uses addresses in multiple administrative scope ranges, it is 124 necessary for the announcer to send identical copies of the announcement to 125 each administrative scope range. It is up to the listeners to parse such 126 multiple announcements as the same session (as identified by the SDP origin 127 field, for example). The announcement rate for each administrative scope 128 range MUST be calculated separately, as if the multiple announcements were 129 separate. 131 Multiple announcers may announce a single session, as an aid to robustness 132 in the face of packet loss and failure of one or more announcers. The rate 133 at which each announcer repeats its announcement MUST be scaled back such 134 that the total announcement rate is equal to that which a single server 135 would choose. Announcements made in this manner MUST be identical. 137 If multiple announcements are being made for a session, then each 138 announcement MUST carry an authentication header signed by the same 139 key, or be treated as a completely separate announcement by listeners. 141 An IPv4 SAP listener SHOULD listen on the IPv4 global scope SAP address 142 and on the SAP addresses for each IPv4 administrative scope zone 143 it is within. The discovery of administrative scope zones is outside 144 the scope of this memo, but it is assumed that each SAP listener 145 within a particular scope zone is aware of that scope zone. A SAP 146 listener which supports IPv6 SHOULD also listen to the IPv6 SAP addresses. 147 Support for directory sessions is OPTIONAL. 149 3.1 Announcement Interval 151 The time period between repetitions of an announcement is chosen 152 such that the total bandwidth used by all announcements on a single 153 SAP group remains below a preconfigured limit. If not otherwise 154 specified, the bandwidth limit SHOULD be assumed to be 4000 bits 155 per second. 157 Each announcer is expected to listen to other announcements in order 158 to determine the total number of sessions being announced on a particular 159 group. Sessions are uniquely identified by the combination of the 160 message identifier hash and originating source fields of the SAP 161 header (note that SAP v0 clients always set the message identifier 162 hash to zero, and if such an announcement is received the entire 163 message MUST be compared to determine uniqueness). 165 Announcements are made by periodic multicast to the group. The base 166 interval between announcements is derived from the number of announcements 167 being made in that group, the size of the announcement and the configured 168 bandwidth limit. The actual transmission time is derived from this 169 base interval as follows: 171 1.The announcer initialises the variable tp to be the last time 172 a particular announcement was transmitted (or the current time 173 if this is the first time this announcement is to be made). 175 2.Given a configured bandwidth limit in bits/second and an announcement 176 of ad_size bytes, the base announcement interval in seconds is 178 interval = max(300; (8*no_of_ads*ad_size)/limit) 180 3.An offset is calculated based on the base announcement interval 182 offset = rand(interval* 2/3)-(interval/3) 184 4.The next transmission time for an announcement derived as 186 tn = tp + interval + offset 188 The announcer then sets a timer to expire at tn and waits. When 189 this timer expires, the announcement is transmitted. 191 If, at some time tc 753 AT&T Center for Internet Research at ICSI, 754 International Computer Science Institute, 755 1947 Center Street, Suite 600, 756 Berkeley, CA 94704, USA 758 Colin Perkins 759 Department of Computer Science, 760 University College London, 761 Gower Street, 762 London, WC1E 6BT, UK 764 Edmund Whelan 765 Department of Computer Science, 766 University College London, 767 Gower Street, 768 London, WC1E 6BT, UK 770 References 772 [1] S. Bradner. Key words for use in RFCs to indicate requirement levels, 773 March 1997. RFC2119. 775 [2] J. Callas, L. Donnerhacke, H. Finney, and R. Thayer. OpenPGP message 776 format, November 1998. RFC2440. 778 [3] P. Deutsch and J.-L. Gailly. Zlib compressed data format specification 779 version 3.3, May 1996. RFC1950. 781 [4] M. Handley and V. Jacobson. SDP: Session Description Protocol, April 782 1998. RFC2327. 784 [5] M. Handley, D. Thaler, and R. Kermode. Multicast-scope zone 785 announcement protocol (MZAP)(, February 1999. Work in progress. 787 [6] R. Housley. Cryptographic message syntax. Work in progress, 788 April 1999. draft-ietf-smime-cms-13.txt. 790 [7] D. Mayer. Administratively scoped IP multicast, July 1998. RFC2365. 792 [8] D. Mills. Network time protocol version 3, March 1992. RFC1305.