Re: Using DNS for SSM

["Stephen Sprunk" <ssprunk@cisco.com>]

Thus spake "Jeff Schoch" <jschoch@sprint.net>
> 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 to left becoming more specific) it seemed logical to process
the
> records that way.

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

> 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.

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.

> 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.

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

     |          |         Stephen Sprunk, K5SSS, CCIE #3723
    :|:        :|:        Network Design Consultant, GSOLE
   :|||:      :|||:       New office: RCDN2 in Richardson, TX
.:|||||||:..:|||||||:.    Email: ssprunk@cisco.com