Subject: Re: Using DNS for SSM

From: ken lindahl <[email-masked]>
Date: Thu, 15 Feb 2001 15:24:55 -0800 (PST)

On Thu, 15 Feb 2001, Dino Farinacci <[email-masked]> wrote:
>>> 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
>
>    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

this has the distinct advantage of requiring only a single dns query to
to get the information, if you're going to add a new RR type, why not add
one that specifically has two fields in RDATA, one for source IP and one
for group ("channel") IP?

simpler still would be to simply have two A records:
   radio.example.com	A	10.1.1.1
   radio.example.com	A	232.1.1.1
and let the application determine which is source and which is group
based on the address range? (i'm prepared for someone to tell me that
there are resolvers out there that pass only on A record to the app.)

multiple sources is an easy extension: just add more A records with the
sources' IP addresses.

ken

---

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

>> there are resolvers out there that pass only on A record to the app.)

    Yes, this could work and if someone wanted the same source to send
    tv content, you'd have:

	tv.example.com A        10.1.1.1
	tv.example.com A        232.1.1.2

    and if this *only* existed:

	cartoons.example.com A  232.1.1.1
        movies.example.co m  A  232.1.1.1

    it would be ambiguous (and insufficient) to the application so it would
    be ignored.

    However, I was thinking that potential source mirroring would be used so

        radio.example.com AA         10.1.1.1.232.1.1.1
        radio.example.com AA         10.2.2.2.232.1.1.1
        radio.west.example.com A     10.1.1.1
        radio.east.example.com A     10.2.2.2

    might make sense and the members of the mirror would use consistent
    group addresses for the same content.

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 15 Feb 2001 15:58:09 -0800 (PST)

Can someone explain to me what the urgent need for SSM specific
channel addresses is ? I agree that it is a nice-to-have,
but such a mapping alone does not allow a user who wants
to receive a channel to simply type the address and then receive
the content.

In the first place, i think the question is: What is a simple
to remember URL scheme that is sufficient as a root pointer for
a receiver application to automatically get all the session
information needed to receive content. With just an S and a G
the application doesn't really stand much of a chance. 

In the web, a FQDN alone is sufficient, because everybody
makes the assumption that the access-scheme is HTTP. What
is the assumption you would want to make in the streaming media
case ? I wouldn't know one. I think the best way to actually
solve this issue is to think about some simplification for
mappings from URLs onto SDP files, because the SDP file is
the only standardised and accepted way to transimit sufficient
information (S,G,port,protocol, etc) for a receiver application
to be able to receive content. I don't see why in the process
of finding a simplified FQDN->URL->SDP mappings you would need
to come up with new RR types or even with some new DNS schemes
to encode a channel.

Now i see a need for DNS encoding of Channels, but just in
the reverse direction: If you're running a network and see
(S,G) state, you'd probably like to get to the SDP file also
to learn about the characteristics of the content. But again,
just doing a (S,G)->FQDN mapping doesn't seem to get us 
much further towards FQDN->SDP.

Just my 2cents on this.

Toerless

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 Feb 2001 16:11:36 -0800

>> channel addresses is ? I agree that it is a nice-to-have,

    I don't see any urgency. What gave you that idea?

>> to receive a channel to simply type the address and then receive

    Sure it does. Just like most apps, you can type a DNS name or an address.
    The Schoch proposal is not forcing apps to use this.

    Toerless, are you proposing SDP attributes in a DNS record.   ;-)

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 15 Feb 2001 16:25:56 -0800 (PST)

>     I don't see any urgency. What gave you that idea?

Just all these mails ;-))

>     Toerless, are you proposing SDP attributes in a DNS record.   ;-)

I really haven't followed track on all the RR's being available,
there are just too many of them. Isn't there a RR mapping from
a DNS record to a URL and application-type of that URL ?

fashion.tv  IN URL  http:/fashion.tv/session.sdp application/x-sdp

A receiver application if presented with something like a domain name
could look it up, and if has such a URL RR with application type x-sdp,
then it would get the sdp file.via the URL given.

And if you have a (S,G) channel with S=1.2.3.4, G=5.6.7.8,
then you could do something along the lines of:

5.6.7.8.ipv4channel.4.3.2.1 IN PTR fashion.tv

Cheers
	Toerless

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 15 Feb 2001 16:27:02 -0800 (PST)

> 5.6.7.8.ipv4channel.4.3.2.1 IN PTR fashion.tv

Should be:

5.6.7.8.ipv4channel.4.3.2.1.in-addr.arpa. IN PTR fashion.tv

---

From: Ross Finlayson <[email-masked]>
Date: Thu, 15 Feb 2001 16:41:50 -0800

>     I don't see any urgency. What gave you that idea?

My reading of Toerless's message was that he was questioning the "need" at 
least as much as the "urgency".

As Toerless noted, knowing a SSM channel address (S,G) alone doesn't tell 
you much.  In order to be able to usefully receive the session, you still 
need additional information telling you something about the properties of 
the session (what media, what port(s), what format(s), etc.).  In other 
words, you need the SDP description.

Since we already have ways of delivering SDP descriptions (e.g., using 
HTTP, returning the application/sdp MIME type), and already have a way of 
describing SSM sessions (S,G, and everything else) in SDP, then why do we 
need to be able to look up SSM (S,G)s using DNS?

         Ross.

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 Feb 2001 17:13:49 -0800

>> least as much as the "urgency".

    Here's a basic need which I think would make managing multicast networks
    one step easier:

	mtrace radio.example.com

>> you much.  In order to be able to usefully receive the session, you still 

    Right, so what's your point. Did you think the DNS was suppose to solve 
    that?

    It's hard enough to remember source and group addresses when debugging
    problems in the network infrastructure without adding any more issues
    to the problem statement.

    Just the fact a network operator can ask over the phone, "what are you
    trying to get to and who are you?", and the answer is radio.example.com and
    customer.broken-dsl.com, would allow the netadmin to do:

        mtrace radio.example.com customer.broken-dsl.com

    would go a long way to isolating problems from the NOC.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 15 Feb 2001 17:15:47 -0800

>> I think this is quite simply a HOrRId idea! It has been ever since it was
>> proposed.

    Of course it is from someone who memorizes group addresses.  ;-)

Dino

---

From: [email-masked] (Jeremy Hall)
Date: Thu, 15 Feb 2001 20:03:40 -0500 (EST)

_J

---

From: [email-masked] (Jeremy Hall)
Date: Thu, 15 Feb 2001 21:09:47 -0500 (EST)

only a couple, I don't remember what cisco multicast is. actually I don't
remember hardly ANY except 224.2.186.225/26406 for KmGE

hmm 224.2.173.150 looks familiar.
_J

---

From: Jon Crowcroft <[email-masked]>
Date: Fri, 16 Feb 2001 08:07:36 +0000

224.5.17.11
was always one of my faves...

anyhow  dino's idea is kinda better than my v6 one:-)

In message <[email-masked]>, Jeremy Hall type

 >>>     Of course it is from someone who memorizes group addresses.  ;-)

 cheers

   jon

---

From: Beau Williamson <[email-masked]>
Date: Wed, 21 Feb 2001 09:33:34 -0800

>    would go a long way to isolating problems from the NOC.

Boy, this sort of thing would have come in handy in the past.  This has merit.

Beau Williamson

---

From: Hugh Holbrook <[email-masked]>
Date: Wed, 21 Feb 2001 15:28:18 -0800 (PST)

>    would go a long way to isolating problems from the NOC.

I can see that it would be nice to be able to mtrace using DNS name(s)
for SSM content rather than a bunch of random numbers.

So I'm trying to imagine how all of this fits together.  How does the
customer get the SSM DNS name so that it can tell the NOC?  Would the
DNS name be stored in the SDP record?  Or is the idea that the
application does a reverse lookup on the address pair in the SDP
record?  Or does this information come from somewhere else?

I'm not sure it's really necessary to have channels represented as
first-class objects in the DNS, though.  I think it would be nice if
we could get the benefits of simple channel names without requiring a
new RR and associated upgrade to bind.  Here's an idea that relies on
a naming convention for channels that achieves the same purpose, at
least for mtrace.  A simple change to mtrace would support the exact
syntax that you suggest without requiring any DNS changes at all.

So you invoke mtrace like this

      mtrace kqed.radio.example.com  customer.broken-dsl.com

The first thing that mtrace does is to resolve kqed.radio.example.com
and get back an A record that says that kqed.radio.example.com maps to
232.1.2.3.  mtrace knows this is an SSM destination address and then
strips off the component of the DNS name (kqed) to find the DNS name
of the source, radio.example.com which it then resolves to get the
source address.  I just wrote a perl script in about ten minutes that
does this.

If a content provider doesn't want to have a four-component name for
all of its SSM content, then it can use a PTR record to make
kqed.example.com be an alias for kqed.radio.example.com.

Given this, I'm not seeing a strong case for having a new RR.

Thoughts?

-Hugh

> Date: Wed, 21 Feb 2001 09:33:34 -0800
> From: Beau Williamson <[email-masked]>
> Cc: [email-masked]
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 Feb 2001 15:51:32 -0800

>> customer get the SSM DNS name so that it can tell the NOC?  Would the

    They move their cursor over the URL in their browser.

>> source address.  I just wrote a perl script in about ten minutes that

    We've been doing this for years already! But with SSM the group address
    is local to the source and is only significant to the source.

Dino

---

From: Hugh Holbrook <[email-masked]>
Date: Wed, 21 Feb 2001 18:44:35 -0800 (PST)

>     They move their cursor over the URL in their browser.

I'm not sure I get it.  Where in the URL would the SSM DNS name
appear?  Are you suggesting that kqed.radio.example.com resolves to
*both* the unicast address of a web server that is serving up an sdp
record *and* to the AA record, in which case we have a URL like this:

   http://kqed.radio.example.com/multicast-sessions/someSdpRecord.sdp

And a zone file something like this?

   kqed.radio.example.com CNAME radio.example.com
   kqed.radio.example.com AA 232.1.2.3.172.20.59.67

Or is the idea that browsers would understand AA records, or something
else?

-Hugh

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 21 Feb 2001 19:54:39 -0800

>> record *and* to the AA record, in which case we have a URL like this:

    The link can be the AA record.

Dino

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 22 Feb 2001 01:13:35 -0800

>     The link can be the AA record.

I don't get it.

Ok, let me try to summarize what i think:

What do we need to anchor channels into the DNS so that we find
all the information we want and in any resolver direction we
need it ?

a)   An easy to remember FQDN.
     
     - Just a question of how much you pay -

a.1) If User tells this FQDN to his ISP, then the ISP
     wants to get just the (S,G) information to do for example
     mtrace (S,G) (R)    [R being the receiver]

     Schoch^2: 2 RRs

          example.com       A  10.1.1.1

     Disadvantage: The user can not type in "radio.example.com"
     into his browser and get an info page about that channel
     anymore because it's gone for a multicast group address
     (232.1.1.1).
   
     Dino: AA RR

     Disadvantage: New RR type ?
     
     Q: Isn't there an IPv6 address range globally assigned
        that could map IPv4 (S,G) pairs ? If there is none,
	why don't we define one. Then we could use that AAAA
	RR type. 
     
     Disadvantage: Ugly. But a cool hack, ain't it ? ;-)

     How about: "prepend media channel FQDNs":

         wb20.example.com     A  10.30.5.4   ! Just the webserver
	                                        for the radiostation
						channel
         
	 mediachannel1.wb20.example.com   A 10.1.1.1
	                                   A 232.1.1.1

	 mediachannel2.wb20.example.com   A 10.1.1.1
	                                   A 232.1.1.5
         
	 audio.wb20.example.com  IN CNAME mediachannel1.wb20.example.com
	 video.wb20.example.com  IN CNAME mediachannel2.wb20.example.com

     Find (S,G) information:
       a) Check out that the FQDN has exactly TWO IN A RRs.
          If it has, and one is a unicast address and the other
	  a multicast address, we're set.
       b) If not, prepend "mediachannel1" to the RR and try (a) again.
     
     List all (S,G) channels for a session:
     If the URL starts with mediachannel<n> already, just
     replace <n>. If not, then strip the first part of the 
     FQDN and replace with mediachannel1 and check again.
     This allows for common cnames like "audio.wb20.example.com"
     and "video.wb20.example.com" to be used and still find the
     generic "mediachannel<n>" names.

a.2) More general, if you have an easy to remember name for
     some "channel" or "session" you would like to have it point
     to all the stuff you may want to know:
     - If i want to start a receiver application, what do
       i have to expect for traffic ?
     - Which ports is the traffic on ?
     - If i want to learn more about it, where i look ?
     - ...
     
    The only source of information that's standardized enough
    and will answer most of these questions is a sessions SDP
    file (or whatever proprietary equivalents there are).

    Proposal:

       radio.example.com TXT "application/sdp=http://www.example.com/sdp/radio.sdp"
       FQDN TXT "mimetype=url"

    Tools/applications that want to get to session description
    from a FQDN would look up TXT records in RFC1464 style
    (var=value), and look up those where the "var" is a 
    MIME type indicating a session decription type known
    to the Tool/application. When it finds such a TXT RR,
    it will try to retrieve the URL indicated in the TXT RR
    to retrieve everything it ever wanted to know about the
    session.

    If the actual session is itself using non-SDP (proprietary)
    session description formats, then there should be one
    TXT RR for this session description and another one for
    a SDP translation of all the session information that can
    be translated into SDP, so that standard tools are not
    expected to be able to understand non-standard session
    descriptions.

    To cope with the mediachannel/video/audio stuff, an application
    that tries to find the SDP TXT RR will need to:
    a) If the FQDN does not have a the TXT RR, then
       check if it's got exactly two A RRs. If yes, then
       remove the first part of the FQDN and look again
       (eg: got video.wb20.kqed.com, strip video, and look again).

b)  If an administrator wants to figure out what a specific
    (S,G) or (*,G) state in his router is, a reverse
    address resolution towards the easy to remember FQDN is
    helpfull to get from there to the session information:

    For an (S,G):

    <group-encoding>.<in-addr.arpa-source> PTR FQDN

    Proposal:

    232.1.1.1.ipv4-group.1.1.1.10.in-addr.arpa PTR radio.example.com

    [Note: It doesn't really matter how the group-encoding
     is done, as long as there is a standard]
    
    For a (*,G):

    <in-addr.arpa-group> PTR FQDN

    19.23.57.233.in-addr.arpa PTR FQDN

    [Note: We would expect this (*,G) reverse mapping to
     only work for GLOB addresses, and other addresses that
     have a static owner. Other group addreses shouldn't be
     mapped into DNS]

--
Toerless

---

From: [email-masked] (Jeremy Hall)
Date: Thu, 22 Feb 2001 04:39:38 -0500 (EST)

Dino, you must be a BIND author.  Isn't this a bit excessive?

_J

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 22 Feb 2001 10:34:10 -0800

>> Dino, you must be a BIND author.  Isn't this a bit excessive?

    Hey, I'm not proposing this idea. Talk to the author of the ID. I'm just
    pointing out good and bad issues.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 22 Feb 2001 11:19:22 -0800

>> I don't get it.

    Toerless, see your patent for details.

Dino