HTTP/1.1 200 OK Date: Mon, 08 Apr 2002 23:54:10 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 19 Nov 1997 18:30:00 GMT ETag: "2e996a-3385-34733028" Accept-Ranges: bytes Content-Length: 13189 Connection: close Content-Type: text/plain Network Working Group Ross Finlayson Internet-Draft Live Networks Expire in six months 1997/11/19 The UDP Multicast Tunneling 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 Many Internet hosts - such as PCs - while capable of running multicast applications, cannot access the MBone because (i) the router(s) that connect them to the Internet do not yet support IP multicast routing, and (ii) their operating systems cannot support a tunneled implementation of IP multicast routing. The ''UDP Multicast Tunneling Protocol'' (UMTP) enables such a host to establish an 'ad hoc' connection to the MBone by tunneling multicast UDP datagrams inside unicast UDP datagrams. By using UDP, this tunneling can be implemented as a 'user level' application, without requiring changes to the host's operating system. It is important to note, however, that this tunneling mechanism is *not* a substitute for proper multicast routing, and should be used *only* in environments where multicast routing cannot be used instead. This document describes this protocol, as is currently implemented by the liveGate multicast tunneling server (http://www.lvn.com/liveGate). 3. Overview UMTP operates using (unicast) UDP datagrams between pairs of nodes - each pair forming the endpoints of a "tunnel". Each datagram is either a "command" (e.g., instructing the destination endpoint to join or leave a group address & port), or "data": an encapsulated multicast UDP datagram, including a (group, port) tuple. For each (group, port) being tunneled, a tunnel endpoint can act either as a "master" or a "slave". A tunnel master (for a particular (group, port)) periodically sends a JOIN_GROUP command to the remote endpoint (a slave), instructing it that this (group, port) is still of interest, and should be tunneled (or continue to be tunneled). A slave will stop tunneling a (group, port) if it either (i) receives a LEAVE_GROUP command from the master, or (ii) has not received any JOIN_GROUP commands for some period of time (currently, 60 seconds). Typically, a host that is trying to access the MBone (e.g., a PC) will be a master, and its remote endpoint (a host already on the MBone) will be a slave. (It is also possible, however, for both endpoints of a tunnel to be masters.) Whenever a tunnel endpoint - whether a master or a slave - receives a multicast UDP datagram addressed to a (group, port) that is currently being tunneled, it encapsulates this datagram and sends it (as a unicast datagram) to the other end of the tunnel. Conversely, whenever a tunnel endpoint receives, over the tunnel, an encapsulated multicast datagram for a (group, port) of interest, it decapsulates it and resends it as a multicast datagram (with a TTL that was specified as a parameter in the encapsulation). A node (typically a slave server) can be the endpoint of several different UMTP tunnels - i.e., each with a different endpoint master. Although, superficially, such a system appears similar to a multicast<->unicast reflector, it differs in two ways: (i) The tunneling is application-independent, and handles any (UDP) multicast packets (ii) After traversing a tunnel, a decapsulated packet is delivered to the endpoint's application(s) via multicast, not unicast. This allows regular multicast-based applications to make use of a UMTP tunnels (subject to some restrictions described below). 4. Restrictions UMTP allows a multicast-capable - but otherwise non-MBone-connected - host to run multicast-based applications. Such applications, however, must satisfy the following conditions: 1/ Their multicast packets must all be UDP - not 'raw' IP 2/ The UMTP implementation (i.e., a tunnel endpoint) must have a way of knowing each (group, port) that the application uses. 3/ The application must not rely upon the source address of its incoming multicast packets being different for different original data sources. In particular, the application must not use source addresses to identify these original data sources. Most multicast-based applications - especially those based on RTP [2] - satisfy these requirements. If the multicast-based applications are launched from a separate 'session directory' application, then the UMTP implementation may be built into the session directory. For some multicast applications, however, the (group, port) is not specified in advance, but instead is determined by the application itself - e.g., by querying a separate 'licensing' server. Depending on the host operating system, a separate UMTP implementation might not be able to independently determine this (group, port). In this case, UMTP could not be used, unless it were incorporated into the application itself. These application restrictions reinforce the point that UMTP should be used *only* if full multicast routing cannot be provided instead. 5. Packet Format, and Command Codes The payload of each UMTP datagram - i.e., excluding the outer UDP header - consists of an 8-octet header, followed optionally (in the case of a "DATA" command) by data. The header format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |version|command| TTL | port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (IPv4) multicast address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ "version" - the protocol version - is currently zero. The following "command"s are currently defined: 0 (unused) 1 DATA 2 JOIN_GROUP 3 LEAVE_GROUP 4 TEAR_DOWN 5 PROBE 6 PROBE_ACK 7 PROBE_NACK 8-15 (unused) Note: UMTP is defined only for IPv4. (In IPv6, native multicast routing will be ubiquitous.) 6. Protocol Operation For the purposes of describing the protocol, a tunnel endpoint has the following state: - a set E of allowable tunnel endpoints (each defined by a unicast address & port) - a set G of active (group, port) tuples. Each such tuple, g, is also tagged with: - a flag F_g with one of two values: {"master", "slave"} - a subset E_g of E: the tunnels that are members of g - a default TTL T_g (the TTL to use if one is not otherwise known) Also, for each tunnel endpoint, the following events of note may occur: 1/ The local node requests the joining of a (group, port) g, with default TTL t 2/ The local node requests the leaving of a (group, port) g 3/ The local node sends a multicast packet to a (group, port) g, with TTL t 4/ A (non-local) multicast packet arrives for a (group, port) g, with source address s 5/ A 'JOIN_GROUP timeout' occurs on a (group, port) g 6/ A tunneled UMTP packet arrives, with source address s Each of these events is handled as follows: 1/ The local node requests the joining of a (group, port) g, with default TTL t add g to G; set F_g to "master"; set T_g to t for each tunnel endpoint e in E_g, send, at 15 second intervals, a JOIN_GROUP(group, port, t) command to e 2/ The local node requests the leaving of a (group, port) g ignore this if g is not a member of G; otherwise: if F_g is "master" for each tunnel endpoint e in E_g, cancel the ongoing periodic JOIN_GROUP commands send a LEAVE_GROUP(group, port) command to e (The TTL field in the packet is unused) (optional: Repeat this send several times) remove g from G 3/ The local node sends a multicast packet to a (group, port) g, with TTL t ignore this if g is not a member of G; otherwise: for each tunnel endpoint e in E_g, send a DATA(group, port, t-1) command to e, with the original packet's data appended 4/ A (non-local) multicast packet arrives for a (group, port) g, with source address s IMPORTANT (see below): If s is one of the endpoints e in E: send a TEAR_DOWN command to e (the address, port, TTL fields are unused) remove e from E otherwise: ignore this if g is not a member of G; otherwise: if the TTL t of the incoming packet is not known: set t to T_g for each tunnel endpoint e in E_g, send a DATA(group, port, t-1) command to e, with the original packet's data appended 5/ A 'JOIN_GROUP timeout' occurs on a (group, port) g ignore this if g is not a member of G; otherwise: if F_g is "slave" remove g from G 6/ A tunneled UMTP packet arrives, with source address s Handle the packet, based on the "command" field: DATA(group, port, t) ignore this if s is not one of the endpoints e in E; otherwise: set g to (group, port) ignore this if g is not a member of G; otherwise: multicast the encapsulated data to (group, port), with TTL t (optional: Instead limit the TTL; see below) for each tunnel endpoint e in E_g, EXCEPT for s send a DATA(group, port, t-1) command to e, with the original packet's data appended JOIN_GROUP(group, port, t) ignore this if s is not one of the endpoints e in E; otherwise: set g to (group, port) ignore this if g is not a multicast address; otherwise: if g is not already a member of G: add g to G; set F_g to "slave"; set T_g to t if F_g is "slave": set a 'JOIN_GROUP timeout' to occur in 60 seconds time (replacing any existing such timeout) LEAVE_GROUP(group, port) ignore this if s is not one of the endpoints e in E; otherwise: set g to (group, port) ignore this if g is not a member of G; otherwise: if F_g is "slave" remove g from G TEAR_DOWN ignore this if s is not one of the endpoints e in E; otherwise: remove e from E PROBE if s is an endpoint e in E: replace the packet's "command" field with PROBE_ACK, and send it back to s else: replace the packet's "command" field with PROBE_NACK, and send it back to s PROBE_ACK, PROBE_NACK Ignore this packet (unless we have recently sent a PROBE) Note: The PROBE command is one that a node can (optionally) use to determine whether a prospective endpoint exists, and if so, whether it would accept us as an endpoint. 7. Loop Detection and Avoidance A data loop may occur if the two endpoints of a UMTP tunnel are connected by multicast, or via another UMTP tunnel elsewhere. Each UMTP implementation must take steps to prevent a loop from occurring: - When multicasting a decapsulated DATA packet, a UMTP implementation should choose a TTL that's no larger than necessary. It must also ensure that if this packet is then re-received (via loop-back), it is not resent back over the tunnel. - If a UMTP implementation receives a multicast packet whose source address is also the endpoint of a tunnel, it must immediately shut down this tunnel (& send a TEAR_DOWN command to the endpoint) - Each end of the tunnel should periodically send a short 'status' packet - containing its unicast address - to a common multicast address, and also listen on this address, checking the contents of each received status packet. Should it the contents of its original status packet, it must immediately shut down all of its tunnels. (Note: These are the same loop detection techniques used by "mTunnel" [3] - a similar multicast tunneling system, developed independently.) 8. Security Considerations Each UMTP implementation should specify, in advance, its set of allowable endpoints (E), and thus should not permit arbitrary nodes to form tunnels. Nonetheless, because endpoints are currently authenticated on the basis of source addresses, this version of the protocol is susceptable to source address spoofing. (For example, periodic JOIN_GROUP commands with a spoofed source address could be used to direct a high-bandwidth multicast feed across a tunnel.) Future versions of this protocol should use an additional mechanism (such as a 3-way handshake) to authenticate endpoints. 9. References [1] The "liveGate" multicast tunneling server http://www.lvn.com/liveGate/ [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996. [3] Parnes, P., "mTunnel" http://www.cdt.luth.se/~peppar/progs/mTunnel/