Subject: Using DNS for SSM

From: Jeff Schoch <[email-masked]>
Date: Wed, 14 Feb 2001 09:33:55 -0500 (EST)

Hi!

I've just submitted a draft which I think the SSM working group should be
interested in.  It can be found at:
http://www.ietf.org/internet-drafts/draft-schoch-dns-ssm-00.txt

It's a relatively short, five page read.  Please feel free to send any
comments to Sunny and me.  Thanks for you time and attention.

Jeff Schoch			[email-masked] 
Operations Engineering		703-689-7716

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 14 Feb 2001 11:09:03 -0600

Thus spake "Jeff Schoch" <[email-masked]>
> I've just submitted a draft which I think the SSM working group should
> be interested in.  It can be found at:

I don't see the rationale for making the source the primary key and the
channels the secondary keys.  I think apps will more likely know the
channel (DNS name) and want a listing of servers.

Have you considered using some variation of SRV records so that you can
specify port numbers per server?  Depending on how you do it, this would
eliminate the need for a magic ".mcast." in the hostname.

> Operations Engineering 703-689-7716

S

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        Network Design Consultant, GSOLE
   :|||:      :|||:       New office: RCDN2 in Richardson, TX
.:|||||||:..:|||||||:.    Email: [email-masked]

---

From: Jeff Schoch <[email-masked]>
Date: Wed, 14 Feb 2001 13:54:46 -0500 (EST)

By channel, you mean the Group, right?  The rationale is the assumption
that there will be more Groups than Sources.  This may not be a valid
assumption in all cases, but isn't a good chunk of the usefulness of
multicast protocols to allow fewer resources to provide more
services?  Using the hierarchy of most DNS lookups as they are used today
(right to left becoming more specific) it seemed logical to process the
records that way.

As for for the SRV records, we will explore that as a possibility to
somehow point to the Source.  We're going to test this out some.  But do
most clients support that type of record?  The information I saw stated
that some clients do not support SRV records (maybe Microsoft?).

In writing this draft, we were looking for solutions which call for the
least number of changes in existing infrastructures, and therefore if the
SRV record functionality would have to be changed in servers or clients,
this option would be less attractive.

Thank you for your input.  We will keep it in mind.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 14 Feb 2001 13:56:15 -0600

> By channel, you mean the Group, right?

Most of the drafts are using "channel" instead of "group" for SSM
addresses since group implies many senders.

> The rationale is the assumption that there will be more Groups than
> Sources.  This may not be a valid assumption in all cases, but isn't a
> good chunk of the usefulness of multicast protocols to allow fewer
> resources to provide more services?

I'm questioning whether a given service is more commonly identified by
the channel name or the source name/ip.  In most cases I can think of,
the app knows what service the user wants and needs to determine who
offers it; it's a rare case where it knows the source and not the
service.

> Using the hierarchy of most DNS lookups as they are used today

Right; I'm just thinking in a service-centric model instead of a
source-centric model.

> somehow point to the Source.  We're going to test this out some.

I was thinking something like:

$ORIGIN example.com.
; SOA, etc
video-1    A    232.1.2.3
rtp.udp.video-1    SRV    0 0 43210 server.example.com.
rtp.udp.video-1    SRV    10 0 34567 backup-server.example.com.
server    A    192.168.1.2
backup-server    A    192.168.3.4

Further distinctions might be needed for video/audio streams instead of
a generic "rtp" protocol type since the two streams usually come from
different ports and/or servers but would probably use the same channel
name.  Or perhaps the semantics should be modified such that *all* SRVs
for the priority level should be accessed, assuming there's one SRV for
each stream?

> But do most clients support that type of record?  The information I
> saw stated that some clients do not support SRV records (maybe
> Microsoft?).

Client apps will need to be retooled for IGMPv3 anyways, so adding SRV
support (just a different call to res_*) doesn't seem onerous.

> least number of changes in existing infrastructures, and therefore if
> the SRV record functionality would have to be changed in servers or
> clients, this option would be less attractive.

Recent BINDs handle SRV easily; older versions can pass them along but
can't parse zone files with them.  Microsoft's Active Directory uses SRV
records extensively.

I'm not sure backwards compatibility with clients is a large issue; how
many existing SSM clients (or even ISM clients) are out there?

S

---

From: Osnat Mokryn <[email-masked]>
Date: Thu, 15 Feb 2001 15:28:00 +0200 (IST)

On Wed, 14 Feb 2001, Stephen Sprunk wrote:

> > be interested in.It can be found at:
> > It's a relatively short, five page read.Please feel free to send any
> > comments to Sunny and me.Thanks for you time and attention.
> 
> channels the secondary keys.I think apps will more likely know the

I agree. 
Furthermore, I think that the domain name should not be changed. Instead
of using a new channel naming convention such as MCAST, or any other
string, I suggest to use the same domain name and change only the protocol
specifier, from HTTP to HTTPM. Thus, people who are used to the site 
http://www.example.com don't have to go to a new 'mcast.example.com' but
rather to a : httpm://www.example.com/url_name where url_name is the
multicast channel name. A specific software in the user's side recognizes
the 'httpm' specifier, and sends the entire URL to the DNS for
resolution, with the 'url_name' concatenated at the end :
<com><example><www><url_name>
Since the resolution process looks for the biggest prefix it can match, it
does not affect current DNS structure. All is needed is to have special
entries for each channel, as in your scheme, which consists of the full
domain name + url_name.

This also solves the problem of having more than one source per domain
name, without changing the domain name.
The mapping in this case is: domain name is the group, the URL is
the specific source (which conforms with reality, in my opinion).

I previously suggested this as part of an overall solution to use
multicast to distribute very hot web pages, as can be seen in DIMACS
technical report 2000-47.

-Ossi Mokryn.

> specify port numbers per server?Depending on how you do it, this would
> eliminate the need for a magic ".mcast." in thehostname.
> 

::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
 Osnat (ossi) Mokryn         :: tel: +972-2-6585770
 Computer Science Institute :: http://www.cs.huji.ac.il/~osnaty
 Hebrew University          :: [email-masked]
 Jerusalem, Israel          :: fax: +972-2-6585439
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 Feb 2001 14:50:35 -0800

>> http://www.ietf.org/internet-drafts/draft-schoch-dns-ssm-00.txt

    An even simpler approach would be to have DNS records like:

        radio.example.com  AA     10.1.1.1.232.1.1.1

    then 1) the application has the complete channel address for IGMPv3, and 2)
    you don't have to require application semantics for a DNS name.

    And we have existence proofs that adding new record types to DNS 
    (particularly simple ones) is not too much effort.

Dino