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.

  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.

  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?

  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.

  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

  References

[] M. Handley and V. Jacobson, ``SDP: Session Description Protocol'',
    RFC2327, April 1998.

[] M. Handley, C. Perkins and E. Whelan, ``SAP: Session Announcement
    Protocol'', work in progress (internet draft), October 1999.

[] M. Handley, D. Thaler and R. Kermode, ``Multicast-Scope Zone
Announcement
    Protocol (MZAP)'', work in progress (internet draft), June 1999.

Perkins                                            Page 4