INTERNET-DRAFT 22 October 1999 Colin Perkins University College London Interactions between SDP and multicast scoping draft-perkins-sdp-scoping-00.txt Status of this memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as work in progress. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this document is unlimited. Comments are solicited and should be addresses to the author and/or the MMUSIC working group's mailing list confctrl@isi.edu. Abstract An undesirable interaction between multicast scoping and SDP is noted. An extension to SDP to allow identification of the multicast scopes within which the session is valid is proposed. 1 Introduction A multicast scope zone is a region of the network where a multicast address range has been given a topological meaning. This has the consequence that a given multicast address may be used multiple times by disjoint users in different scope zones. Those users typically derive their knowledge of a multicast session from a description expressed in SDP [1]. Such a description contains the title of a session, information regarding the originator of the Perkins Page 1 INTERNET-DRAFT 22 October 1999 session, the media to use and the multicast addresses and ports. Those addresses are denoted by a `c=' line, of the form c=IN IP4 224.2.17.12/127 which contains a single IP address (multiple `c=' lines are used if the session needs more than one address). At present there is no means of identifying the administrative scope in which that address is valid. The consequence of this is that it is not possible to know - from a session description alone - if one can join a particular session. Indeed, it is possible that the addresses chosen for a session in one particular scope zone are being used for a totally different session in the scope where a user wishing to join the first session is located. This is clearly undesirable. The obvious solution to this problem is to include a globally unique name for the administrative scope zone within the session description. For example, one may use an `a=zone:' attribute in SDP: c=IN IP4 224.2.17.12/127 a=zone:foo This relys on administrative scope zones having a globally unqiue name, which is discussed below. An alternative is to ensure that a given SDP file is only available in the scope where it is valid. This may be achieved by announcing the session with SAP [2], since SAP announcements are sent on a per-scope multicast group. Of course, there are cases where the use of SAP is inappropriate (small, private sessions for example) so this is not a general solution. 2 Scope naming The Multicast Zone Announcement Protocol, MZAP [3], is used to inform users of the administrative scopes they are within. MZAP provides two ways of identifying a scope: o the scope name o the zone ID The scope name is defined, in MZAP, for ``human convenience'', and hence is not guaranteed to have any particular uniqueness. It cannot, therefore, be used as an identifier for the scope in session descriptions which are passed outside that scope. Perkins Page 2 INTERNET-DRAFT 22 October 1999 We also note that the scope name is optional in MZAP ZAM packets, hence scopes may exist without a textual name (and are identified by their zone ID and the first multicast address assigned to that scope). Use of the scope name as a globally unqiue identifier for an administrative scope zone would require o the scope name to be mandatory o an allocation policy for scope names The requirement for mandatory scope names is simple to achieve in MZAP. An allocation policy is harder to define, but it may suffice to prefix the scope name with the fully qualified domain name of the `owner' of the scope. This would need further consideration if this option is chosen. The zone ID is defined as follows [3]: ``...the lowest IP address used by any ZBR [zone border router] for a particular zone for sourcing MZAP messages into that scope zone. The combination of this IP address and the first multicast address in the scope range serve to uniquely identify the scope zone. Each ZBR listens for messages from other ZBRs for the same boundary, and can determine the Zone ID based on the source addresses seen. The Zone ID may change over time as ZBRs come up and down.'' Unfortunately, as noted, the zone ID may change over time. This represents a problem in its use as a global identifier for the scope, although once the zone border routers have converged on their definition of the zone ID it will not change unless the set of routers which form the boundary of the scope changes. Since we expect administrative scope zones to be relatively static in nature, this is not expected to be a problem. If the zone ID is expected to change during the lifetime of a typical session, it may be necessary to define an additional, globally unique, zone identifier within MZAP. Given these two options we recommend that the combination of zone ID and the first multicast address in the scope range is used as a unique identifer for the scope. This is shorter than the textual scope name (important when SDP is announced using SAP or other UDP based protocols), and avoids the need for a new allocation policy/registry for scope names. The `a=zone:' SDP attribute mentioned earlier hence needs to convery the following information: address family, zone ID and lowest multicast address in the range. For example: Perkins Page 3 INTERNET-DRAFT 22 October 1999 c=IN IP4 224.2.17.12/127 a=zone:IN IP4 224.2.17.0 128.16.64.32 An open issue is the scope assumed for session descriptions which don't contain an `a=zone:' attribute: global or local? 3 Conclusions We have identified an interaction between SDP and multicast scoping which can result in users of a session description using a multicast address which is invalid in the scope zone they are within. This can be avoided by including an identifier for the administrative scope zone in which the session is valid within the SDP. We present a defintion for that attribute. 4 Author's Address Colin Perkins Department of Computer Science University College London Gower Street London WC1E 6BT United Kingdom Email: c.perkins@cs.ucl.ac.uk 5 References [1] M. Handley and V. Jacobson, ``SDP: Session Description Protocol'', RFC2327, April 1998. [2] M. Handley, C. Perkins and E. Whelan, ``SAP: Session Announcement Protocol'', work in progress (internet draft), October 1999. [3] M. Handley, D. Thaler and R. Kermode, ``Multicast-Scope Zone Announcement Protocol (MZAP)'', work in progress (internet draft), June 1999. Perkins Page 4