Network Working Group Ross Finlayson Internet-Draft Live Networks Expire in six months 1997/01/12 The Multicast Attribute Framing Protocol 1. 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). 2. 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. 3. 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 5 we give an example of a MAFP announcement. We close with an outline of possible future directions for this protocol. 4. 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 : ::= \ ::= \ ::= \ "general" | "channel" | "bundle" ::= \ "|" | "|" ::= \ | ::= ::= ::= ::= x.y.z.w (i.e., a 'dotted quad' IPv4 address) ::= \ a string representing a decimal integer in the range 0 through 65535 ::= ::= \ 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 - , , , , , , and - are described below 4.2. 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. The 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 , , and 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 does not correspond to the transmission mechanism (e.g., a multicast group address) on which the announcement is being made. 4.5. 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. 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. 5. 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. 1 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'} 6. 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 6. References [1] "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