Network Working Group                                   Ross Finlayson
Internet-Draft                                          Live Networks
Expire in six months                                       1997/01/12

               The Multicast Attribute Framing Protocol

                        <draft-finlayson-mafp-00.txt>

. 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
   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.''

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa) , nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast ), or
   ftp.isi.edu (US West Coast).

. Abstract

The Internet has recently seen the emergence of applications that involve
the ongoing transmission, or "pushing", of structured data from a server to
one or more client nodes.  Most current applications send this data using
unicast communications - usually over TCP connections.  However, similar
applications can also be implemented using multicast-based protocols.
Multicast not only improves the scalability of this particular class of
application, but also makes possible an additional class of application in
which the participants can act as peers - sending data as well as receiving.

This Internet Draft describes the "Multicast Attribute Framing Protocol"
(MAFP) - a generic, attribute-based data representation, intended for a wide
variety of multicast-based applications.  It is currently being used to
implement the "multikit" generic multicast session browser
(http://www.lvn.com/multikit).  This draft describes an early version of
MAFP that is likely to undergo substantial changes in the future.  However,
it is being described now, in the hope that it will promote open discussion
of this and similar protocols - ideally leading to the adoption of an open,
interoperable standard for this class of application.

. Introduction

MAFP is used to describe one or more objects that are being transmitted or
'announced' over the Internet, typically to a multicast address.  (Other
transmission mechanisms are possible, however, including unicast (UDP or
TCP), or even email.)  These announced objects are called "programs" (by
analogy with TV programs, not computer programs).

Each program is announced to a specific "directory".  That is, an
announcement in MAFP consists of both the program being announced, and the
directory to which it is being announced.  More than one program can - and
typically will - be announced to the same directory (in separate
announcements).  If the announcements are being made using multicast, then
the directory will be associated with this multicast address.

A program is described primarily as a set of "attributes" (name-value
pairs).  MAFP does not define any semantics for these attributes; the names
and values can be treated merely as opaque strings.  (Future documents may
define attribute profiles for specific applications.)

In addition to attributes, some program descriptions may also contain IP
address, port, and TTL ("time to live") parameters.  Recipient(s) may use
these parameters for additional communication (usually in a manner defined
by the attributes).  These parameters are distinguished from attributes;
this allows firewalls or proxies to perform appropriate checking and/or
translation, without having to understand anything about the attributes
themselves.

MAFP was inspired in part by SDP [2] - a format designed specifically for
announcing multimedia sessions (primarily, over the MBone).  MAFP, however,
extends the SDP model in the following ways:
        - directories are 'first-class' objects, and can be 'announced' just
like any other session
        - sessions can have arbitrary attributes (not just the fixed set of
attributes that were defined for SDP)
        - SDP's session bundling mechanism is generalized: Any arbitrary
collection of sessions can be combined and announced as a single 'bundle'

MAFP describes the layout (within a packet) of a "program announcement".
MAFP is independent of the underlying transport protocol, which may have
only "best efforts" datagram semantics (e.g., UDP), or may provide some
degree of reliable delivery.  The only requirement is that a program
announcement either be delivered entirely, or not at all.  (Future versions
of MAFP, however, may also allow announcements to be fragmented in ways that
might be exploited by underlying transport protocols [3].)

Section 4 describes the syntax of a MAFP "program announcement".  In section
 we give an example of a MAFP announcement.  We close with an outline of
possible future directions for this protocol.

. The Syntax of a MAFP Packet

4.1 Basic Lexical Structure and Syntax

The lexical structure of the current version of MAFP is based upon that of
the Tcl scripting language [4].  Future versions of MAFP will be more
language-independent.

A MAFP program announcement is a character string, possibly terminated by a
NUL character (i.e., value zero) or a LF (ASCII 0x0a).  It consists of a
"list" in the Tcl sense - i.e., a sequence of string "elements", each
separated by white-space.  Tcl's quoting rules apply to elements - in
particular, elements that contain white space are enclosed in braces {}.

A MAFP program announcement is given by the following BNF grammar :

<PROGRAM ANNOUNCEMENT> ::= <version> <command> \
        <directory id> <PROGRAM DESCRIPTION>

<PROGRAM DESCRIPTION> ::= \
        <program id> <parent id> <expiration date> <PROGRAM SPECIFIER>

<PROGRAM SPECIFIER> ::= \
        "general" <ATTRIBUTE PAIRS>
|       "channel" <GROUP EID> <ATTRIBUTE PAIRS>
|       "bundle" <MEMBER DESCRIPTIONS> <ATTRIBUTE PAIRS>

<MEMBER DESCRIPTIONS> ::= \
        <PROGRAM DESCRIPTION> "|"
|       <MEMBER DESCRIPTIONS> <PROGRAM DESCRIPTION> "|"

<ATTRIBUTE PAIRS> ::= \
        <empty>
|       <ATTRIBUTE NAME> <ATTRIBUTE VALUE> <ATTRIBUTE PAIRS>

<ATTRIBUTE NAME> ::= <string>
<ATTRIBUTE VALUE> ::= <string>

<GROUP EID> ::= <IP ADDRESS> <PORT> <SCOPE>
<IP ADDRESS> ::= x.y.z.w (i.e., a 'dotted quad' IPv4 address)
<PORT> ::= \
        a string representing a decimal integer in the range 0 through 65535
<SCOPE> ::= <TTL> <encryption key>
<TTL> ::= \
        a string representing a decimal integer in the range 0 through 255

The terminal symbols "general", "channel", "bundle", and "|" appear exactly
as shown (without the enclosing quote symbols).

The remaining (nonobvious) nonterminal symbols - <version>, <command>,
<directory id>, <program id>, <parent id>, <expiration date>, and
<encryption key> - are described below

4.2. <version>

The current version of MAFP is 1, represented by the character '1' (ASCII
0x31).  To allow for possible future versions of MAFP that may use a raw
binary encoding, this must be the first character in the packet, and must be
immediately followed by a space (ASCII 0x20).

4.3. <command>

The <command> describes the nature of the announcement, and thus the action
to be taken by each receiver.  Currently only one command is defined: "d".
This is interpreted as follows:
        - If the receiver has no current record of the announced program, then it
should create such a record, unless it also has no current record of the
'parent' program (see below).
        - If the receiver has a current record of the announced program, then it
should update its existing record with the information from the
announcement.  Any new attributes defined in the announcement are added to
the existing record, but any attributes in the existing record that are not
redefined in the announcement should remain.

4.4. Program Ids

<directory id>, <program id>, and <parent id> are each "program ids": unique
identifiers that denote, respectively:
        - the directory to which the announcement is being made,
        - the program that is being announced, and
        - the parent of the program that's being announced, or "{}" (the empty
string) if the program has no parent.
The "parent" mechanism is used to implement a simple attribute inheritance
hierarchy.  Any attributes of the parent that are not redefined in an
announcement of the child are inherited by the child.

At present, MAFP does not define the structure of program ids; they can
merely be considered opaque strings.  Specific applications that use MAFP
may impose some structure on program ids - e.g., to ensure global
uniqueness.  Future versions of MAFP might also impose some structure -
e.g., to embed a public key representing the program's 'owner'.

The receiver should ignore an announcement if the <directory id> does not
correspond to the transmission mechanism (e.g., a multicast group address)
on which the announcement is being made.

4.5. <expiration date>

This field specifies the time at which the announced program will expire
(and can thus be removed from the receiver's records).  It is an integer in
"Unix time format": the number of seconds since 1/1/1970 UTC.

Note that, because of attribute inheritance,  a program's expiration date
should not exceed that of its parent.  If an announcement is received that
attempts to set a program's expiration date to a later time than that of its
parent, then the parent's expiration date should be used instead.

4.6. <encryption key>

In the future this field will be used to specify an encryption key for a
"channel" (see below).  Currently, the only value defined for this field is
the string "nokey", meaning: no encryption is performed.

4.7. Channels and Bundles

MAFP recognizes three distinct kinds of program: channels, bundles, and
'general' (everything else).

A channel has an associated IP address, port number, and TTL.  (A directory
is usually a channel.)

Bundles are used to implement a simple grouping mechanism.  An announcement
of a bundle includes each of its members.

. An Example

The example below illustrates the announcement of a program - specifically a
bundle "prog2" with two members: (i) a channel "prog4" (note the multicast
address, port, and TTL), and (ii) a 'general' program (i.e., neither a
channel nor a bundle) "prog6".  (The announcement is being made to the
directory "prog1".)

Each of the three programs (the bundle and its two members) has an attribute
named "anAttributeName"; the channel has an additional attribute named
"anotherAttributeName".  Note the use of braces to 'quote' multi-word
attribute values.

The line breaks in this example are for clarification only.  Newline
characters must *not* appear in an actual "on-the-wire" announcement.

 d prog1
    prog2 prog3 857203200 bundle
        prog4 prog5 857203200 channel
            238.236.141.215 50470 127 nokey
            anAttributeName {This is an attribute of the channel} |
        prog6 prog7 857203200 general
            anAttributeName {This is an attribute of the 'general' program}
            anotherAttributeName foobar |
        anAttributeName {This is an attribute of the 'bundle'}


. Possible Future Directions

(In no particular order)

- Make the syntax less dependent on one particular programming language (Tcl)
- Use NTP time format (instead of Unix)?
- Define attributes as (name, type, value) triples, rather than (name,
value) pairs?
- Leverage off MIME for the syntax of attributes?
- Define a compression scheme, to efficiently support low-bandwidth links
- Allow program announcements to be digitally signed, for integrity
- Try to be as consistent as possible with SAP [5], and/or any reliable
multicast protocols that emerge from the IRTF's "reliable multicast" working
group [6].
- Define a MIME content type for MAFP program descriptions.  This would
allow a MAFP program to be defined in an email message, or returned by a Web
server.
- I18N
- Support IPv6 addresses as well as IPv4

. References

[] "multikit" - a distributed, multicast-based directory browser
        http://www.lvn.com/multikit/
[2] M Handley, V. Jacobson.  SDP: Session Description Protocol
        draft-ietf-mmusic-sdp-02.txt
[3] David D. Clark, David L. Tennenhouse.  Architectural Considerations for
        New Generation Protocols.  SIGCOMM 1990.  ("Application Layer Framing")
[4] Tcl/Tk
        http://www.sunlabs.com/research/tcl/
[5] M Handley.  SAP: Session Announcement Protocol
        draft-ietf-mmusic-sap-00.txt
[6] IRTF "reliable multicast" working group
        rm-request@mash.cs.berkeley.edu