J. Schoch Internet Draft Sprint Document: draft-schoch-dns-ssm-00.txt S. Schoch Expires: August 2001 Juniper Networks February, 2001 Using Domain Name Services for Source Specific Multicast 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. Abstract One of the obstacles in implementing any version of Multicast is creating a method of advertising what is being "broadcast" on any particular "channel". This document defines a method for using the existing Domain Name Service (DNS)[RFC1034, RFC1035] infrastructure to assist in advertising Source-Specific Multicast [SSM] "channels" (S,G pairs). 1. Overview and Rationale Although there are many arguments about whether the "killer app" of the Internet is the World Wide Web (web browsing) or email, the popularity of either of these applications is very dependent upon DNS. Most Internet applications can technically run without DNS, but realistically humans find it much easier to remember names and words rather than the string of numbers that the Internet is really DNS for SSM February 2001 based upon. Source-Specific Multicast (SSM) is a protocol which allows a receiver to use the pairing of a Unicast Source address (S) and a Multicast Group address (G) in the 232/8 range to receive a unique "channel" in a one-to-many delivery application. This is an improvement over previous PIM-SM protocol in that an RP is no longer required to retrieve the Source information. It is very probable that using DNS to resolve SSM "channels" to the building blocks of the (S,G) would assist in the welcoming of the new technology. Such an implementation would be most practical if: -It requires very little or no changes in existing technologies. -It uses easily understandable algorithms. -It allows average people to remember their favorite SSM-enabled "channels" as easily as they remember favorite web sites. -It fits into a niche not filled by an existing implementation. This document proposes an implementation that should meet the above requirements in the following ways: -This implementation requires no changes in existing DNS, and only requires acceptance and changes in end user software. -The algorithms proposed are very similar to current DNS records used for WWW and email applications. -The use of DNS will implicitly allow for the ease of use by the general public. -Although DNS is being used by some well-known multicast sources, the authors are unaware of anyone using the following algorithm intended for SSM. 1.1. Assumptions The authors do not rule out the possibility of using this method for applications other than Source-Specific Multicast, however this document is meant to address issues solely related to SSM. Most of the implementation of this method will need to be done in the end- user software. This method generally assumes one source per content provider, but multiple source machines are also possible. This document will not make any changes to the way SSM works as a transport, or the way DNS works to resolve names to IP addresses, and therefore will not go into much detail of the inner working of SSM or DNS. This document will not address any issues of reverse DNS resolution for multicast address space. 2. Naming a Channel Calling a channel in SSM requires two pieces of information; the unicast IP address of the Source and the Multicast address of the Group to which the receiver wants to "listen". These two pieces are Schoch & Schoch Draft-Expires August 2001 DNS for SSM February 2001 usually joined as one expression in the form of (S,G) for Subscribe and Unsubscribe requests. Therefore, a DNS representation of this information must have one expression that contains both the Source and Group information. DNS is ideal for this because it routinely uses recursion to provide multiple pieces of information, and it can be used to provide clues about the services provided by a particular host. The host name www.example.com tells you that there is probably a web server that belongs to the owners of example.com, and through the magic of DNS you can find the IP address of www.example.com. Also, www.example.com can be on a totally different machine and IP address than ftp.example.com or mail.example.com, or even foo.www.example.com. An SSM channel might similarly be represented as radio.mcast.example.com. The format of this representation should be .. 2.1. A Convention for Naming SSM Sources The Source machine name MUST follow a specific convention. In this document, we will use a Source name of MCAST, although another string may be decided upon later. The Source MUST follow this convention because the string used to identify the Source (whatever it is finally decided to be), will become a delimiter for the end- user software. In our above model, the Source name would be mcast.example.com, and the Unicast IP address of the Source would be found by looking up the associated A record. In the case of multiple Sources, providers can use multiple sub domains to name their multiple servers. In this case, mcast.res.example.com is a different Source than mcast.atl.example.com, and therefore has a different Unicast IP address. Reverse DNS information can be stored using PTR records as in normal Unicast reverse lookups. 2.2. A Proposal for Naming SSM Groups There is no hard rule for naming the Group. However, in the interest of common sense, it is better to name the Group something relevant to the Channel content. In the above channel example of radio.mcast.example.com, "radio" is the name of the Group and probably is some form of streaming audio, and would resolve to the Multicast IP address of that Group. This document proposes no method of implementing reverse lookups on Multicast address space. Schoch & Schoch Draft-Expires August 2001 DNS for SSM February 2001 3. Resolving an SSM Channel The following steps are used to resolve a Channel name into the Source and Group that make it up. 1. Assuming a user wants to go to radio.mcast.example.com, he enters radio.mcast.example.com in his SSM-enabled software. 2. The software parses the name for the first instance of the string ".mcast.", and resolves mcast.example.com to the unicast address of the Source. Searching for the beginning and trailing periods in the string will help differentiate the Source from second or third level domain names. 3. The software stores this as the "S" of the (S,G) pair. 4. The software resolves the entire Channel name, radio.mcast.example.com, to the multicast Group address. 5. The software stores this as the "G" of the (S,G) pair. 6. Finally, the software Subscribes to the (S,G) pair that makes up the Channel using the methods normally used in SSM. 4. An Example Zone File The following illustrates how the above examples may be put into a DNS zone file for the example.com domain using BIND. These are meant to be illustrations only. Other formats may be used to enter the info into zone files, as long as they follow the guidelines set forth in section 2 above. ;SOA record information would be above this line ; ;First, define the Source address (S) of our server. mcast.example.com. IN A 10.10.10.42 ; ;Then, define the Group (G) addresses available on this server. radio.mcast.example.com. IN A 232.10.10.42 ;streaming audio tv.mcast.example.com IN A 232.20.20.42 ;streaming video stocks.mcast.example.com. IN A 232.30.30.42 ;stock updates weather.mcast.example.com. IN A 232.40.40.42 ;weather updates sports.mcast.example.com. IN A 232.50.50.42 ;sports updates 5. Security Considerations This document introduces no security considerations other than any already associated with DNS and SSM. Schoch & Schoch Draft-Expires August 2001 DNS for SSM February 2001 6. References [SSM] Holbrook, H., and Cain, B. "Source-Specific Multicast for IP," Internet Draft, November 2000. [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities," RFC 1034, November 1987. [RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification," RFC 1035, November 1987. 7. Author's Addresses Jeff Schoch Sprint 12490 Sunrise Valley Drive Phone: 1-703-689-7716 Reston, VA USA Email: jschoch@sprint.net Sunny Schoch Juniper Networks 11400 Commerce Park Drive Phone: 1-703-390-6816 Reston, VA USA Email: sunny@juniper.net Schoch & Schoch Draft-Expires August 2001