Re: Using DNS for SSM

[Toerless Eckert <eckert@cisco.com>]

On Wed, Feb 21, 2001 at 07:54:39PM -0800, Dino Farinacci wrote:
> >> 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:
> 
>     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
          radio.example.com A 232.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
          
	  radio.example.com  AA     10.1.1.1.232.1.1.1
     
     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