Subject: RE: mboned: Interest in working on multicast address rendezvous?

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 27 Jan 2005 17:12:54 -0500

But this doesn't explain how one picks the multicast address to begin with, does it? Need some sort of multicast address autoconfiguration protocol, with duplicate address discovery.

There's also the question of how multicast routers within the routing domain are set. Which addresses are forwarded and over which ports.

Announcement seems the smaller of the two problems. Has SAP gone into disfavor?

Bert

> -----Original Message-----
> From: Beau Williamson [mailto:[email-masked]]
> Sent: Thursday, January 27, 2005 2:47 PM
> To: Pekka Savola; [email-masked]
> Subject: Re: mboned: Interest in working on multicast address
> rendezvous?
> 
> 
> Pekka,
> 
> I've had some discussions about this with Dave Thaler in the 
> past.  There 
> was some work done in the past on SADP (Session Address 
> Discovery Protocol) 
> that I thought was in the general direction of what was 
> needed although 
> maybe it needs some tweaking.
> 
> My idea was that we need to better establish at least two 
> well known scopes 
> for the smallest and largest scope WITHIN a PIM Domain (such as an 
> Enterprise).  You would then assign an SADP Scope Relative 
> address that 
> could be used by an application to discover what multicast 
> address was 
> being used for it's application.  The key is that you don't 
> want to depend 
> on a given SADP Server architecture having to exist prior to this 
> working.  Instead, you want the application developers to be 
> free to write 
> code so that their SERVERS listend to this scope relative 
> address and then 
> responded ONLY to SADP Requests for their application.  The 
> goal is to let 
> the application writers deploy their applications in networks 
> that have a 
> minimum infrastructure.
> 
> Hopefully some of the above makes sense.
> 
> Beau Williamson
> P.S.  I can contribute to this but don't have the cycles to 
> write an ID.
> At 1/27/2005 11:22 AM, Pekka Savola wrote:
> >Hello folks,
> >
> > From time to time, there has been more or less vigorous 
> discussion in so 
> > called "multicast address rendezvous", i.e., how does a multicast 
> > application (like one that has a static IANA assignment 
> today) pick the 
> > address for creating a new session, and how do the other 
> instances of the 
> > same application find that IP address.
> >
> >This was discussed as part of IMDOC at IETF59 though I don't 
> think there 
> >was much result from that (the last item on agenda):
> >  http://www.ietf.org/proceedings/04mar/172.htm
> >
> >This is also mentioned in section 4 (which might be going 
> away as it's a 
> >bit out of scope) of:
> >  draft-savola-mboned-addrarch-00.txt section 4.
> >
> >What I'd like is to have a couple of people (myself included 
> if needed :) 
> >to sit down, and try to write an I-D on the subject, exploring the 
> >problem, perhaps introducing some requirements, and maybe 
> even look at the 
> >solution space for a bit.
> >
> >Anyone interested?  I'd prefer to be only a contributor 
> myself, as I have 
> >a bit too many drafts out already, so if you'd like to 
> actively drive the 
> >effort, this is the chance of the lifetime.. ;-)
> >
> >--
> >Pekka Savola                 "You each name yourselves king, yet the
> >Netcore Oy                    kingdom bleeds."
> >Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >_______________________________________________________________
> >user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
> >web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
> _______________________________________________________________
> user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
> web archive:  http://darkwing.uoregon.edu/~llynch/mboned/
> 

_______________________________________________________________
user interface: http://darkwing.uoregon.edu/~llynch/mboned.html
web archive:  http://darkwing.uoregon.edu/~llynch/mboned/

---

From: Beau Williamson <[email-masked]>
Date: Thu, 27 Jan 2005 19:55:06 -0600

Manfredi,

The assumption here is that the application server is at the very least, 
under the administration control of some network 
administrator.  Admittedly, this is not always the case.  However, under 
this most basic of assumptions, the network administrator either configures 
the server with the desired address or assigns the address to the the owner 
of the server for configuration.

This is a HUGE step up from what we tend to have today and that is 
application developers simply obtaining an IP address via "Atmospheric 
Extraction" (AE) and hard coding it into their application so that they 
KNOW that they will work without any special need to configure every client 
workstation in the network with the assigned address.  This "AE" method is 
increasingly becoming more and more the norm and results in total chaos in 
our multicast enabled networks.  Often, as in the case of several popular 
software push applications (which I will not name), the addresses that are 
"AE" assigned fall into the Global address space and hence devastate any 
multicast scoping plans that the network administrators are trying to deploy.

So as a first step, I'd like to see some light-weight, SADP-like mechanism 
standardized that uses a well-know expanding scope search (e.g. link-local, 
site-local, org-local order) to locate the assigned address for the 
application.  Once we have that piece in the puzzle, we can move to having 
the Server make use of MADCAP sort of techniques for automatic allocation 
of an address.  Key to all of this is to get the application develops to 
STOP self-assigning addresses and (even-worse) hard-coding them into 
applications.

Beau Williamson
At 1/27/2005 04:12 PM, Manfredi, Albert E wrote:
>But this doesn't explain how one picks the multicast address to begin 
>with, does it? Need some sort of multicast address autoconfiguration 
>protocol, with duplicate address discovery.
>
>There's also the question of how multicast routers within the routing 
>domain are set. Which addresses are forwarded and over which ports.
>

---

From: Pekka Savola <[email-masked]>
Date: Fri, 28 Jan 2005 13:51:19 +0200 (EET)

Hi,

On Thu, 27 Jan 2005, Beau Williamson wrote:
> the Server make use of MADCAP sort of techniques for automatic allocation of 
> an address.  Key to all of this is to get the application develops to STOP 
> self-assigning addresses and (even-worse) hard-coding them into applications.

This is solving a slightly different (subset) problem as the one I've 
been considering.

That is, this only works for multicast applications insider _one_ 
smaller-than-global scope (there are many of those, of course).  If 
this was the problem we needed to solve, having IANA do manual 
allocations for group addresses inside each smaller scope would have 
been a solution (there are others, and better ones, such as you 
describe).  It is a good question whether this would be a sufficient 
step at the moment.

Unfortunately, a big issue at IETF59 seemed to be those applications 
which cover more than just one administrative scope, so you need to 
use global addresses.

But I think both problems could be solved in a reasonable manner. (My 
next mail.)

---

From: Beau Williamson <[email-masked]>
Date: Fri, 28 Jan 2005 10:09:09 -0600

At 1/28/2005 05:51 AM, Pekka Savola wrote:
>This is solving a slightly different (subset) problem as the one I've been 
>considering.

Maybe, but I think they may be closer than you think.

>smaller-than-global scope (there are many of those, of course).  If this 
>was the problem we needed to solve, having IANA do manual allocations for 
>group addresses inside each smaller scope would have been a solution 
>(there are others, and better ones, such as you describe).  It is a good 
>question whether this would be a sufficient step at the moment.

Manual IANA allocations for these "smaller-than-global" scopes is, IMHO, 
not an option.  This is because we are talking about scopes that fall 
inside of private PIM-SM domains, i.e. Enterprise networks, most of which 
have adopted the 239/8 address range as Private space.

These Enterprise networks have built (or are planning on building) their 
own custom admin. scoping plans within the Enterprise network.  Therefore 
IANA should NEVER manually assign addresses within this scope beyond Scope 
Relative addresses.  To do so would mean the 239/8 address space is no 
longer "private".

>Unfortunately, a big issue at IETF59 seemed to be those applications which 
>cover more than just one administrative scope, so you need to use global 
>addresses.

Understood.  However, I'll bet you one of you favorite beverages that the 
reason that applications pick a global address is NOT with the intention of 
operating across a single scope.

In fact, it has been my experience that these applications just simply need 
a well-known multicast address to operate so they:

1a) Perform the "Atmospheric Extraction" (AE) address assignment 
calculation from on of the many global ranges, or

1b) Take the time and effort to get IANA to assign them an address.

2) Hard code the address into their application.

In the case of option 1a, this pretty much ALWAYS results in a global 
address because typically application developers KNOW that 239/8 is private 
address space that will be used inside of the Enterprise network. Thus, 
they avoid this range.

In the case of option 1b, this results in a global address by default since 
IANA does not allocate (and never should) address space from the 239/8 
range. (If they ever did, it would make as much sense as them allocate 
unicast addresses out of the private unicast range.)

Remember, in most cases these applications have been sold to users that 
have NOT been running any multicast in their networks. Thus the scope of 
nearly all deployments of these applications has been 99.99% link-local in 
scope.  Given that sort of maximal limited scope environment, just about 
any ole AE derived address WAS just fine and allowed these applications to 
be sold, work and be profitable.

Enter IP Multicast stage left.  Enterprise network now needs to support a 
multicast video application which plays nice and has the ability for the 
network admin to configure the address(es) to use.  Plans are made, scopes 
are defined, boundaries configured and 239/8 address ranges assigned (often 
in some very bizarre ways that indicate the network admin is clueless about 
multicast, but I digress.)

The big day comes. (Actually, night would be more likely since these sort 
of changes are done out of hours.) The air is electric with anticipation. 
The "switch" is thrown. PIM Control packets begin to course through the 
network at just under the speed of light. High up in his NOC, the chief 
network admin laughs maniacally and cries, "Give my Multicast Monster 
LIFE!" (apologies to Mel Brooks) as the newly deployed multicast video 
application awakens and begins to deliver the desired video to all corners 
of the network.

But wait all is not right in the Enterprise.  What's all this other 
crap!?  Look at all of this other multicast state being generated. Where is 
this coming from?

It's our good old AE applications and (sometimes) OS's that have happily 
being using multicast in a link-local environment all these years that are 
now suddenly operating Enterprise wide.  No problem, we'll just find out 
what these applications are and reconfigure them to use an address in the 
appropriate scoped range to limit them to one of the many smaller scopes we 
have designed in our 239/8 scoping plan.

OH, NO!  These stupid applications are HARD CODED with global range 
multicast addresses.  There is little we can do except try to deal with 
each one, on a one by one basis making our nicely planned scoping plan go 
out the window.

Forgive my dramatic flare but I've seen the above scenario happen over and 
over and over again with Enterprise networks that enable multicast.  Most 
of which have NO desire to send or receive multicast to/from the 
Internet.  Their maximum scope of interest is the boundaries of the 
Enterprise network.

This is the problem I'd like us to address.  If we can find a way to 
address it within the framework of a larger global address allocation and 
scoping problem, then I'm happy with that.  However, I really don't think 
we have scoping problems outside of the Enterprise boundary.

Beau Williamson

---

From: John Kristoff <[email-masked]>
Date: Fri, 28 Jan 2005 15:06:20 -0600

On Fri, 28 Jan 2005 10:09:09 -0600
Beau Williamson <[email-masked]> wrote:

[...]
> Relative addresses.  To do so would mean the 239/8 address space is no 

If we could just have one block of group addresses, even if they are
not out of a reserved block from 239/8 (not all of 239/8 has been
allocated and scoped is not the same as private in my estimation), where
global application assignments can be made out of, that would be really,
really nice.  I'm not sure if all the vendors would go get assignments,
but I would certainly encourage them to.  Surely we can find 65536
group addresses (same amount as tcp/udp port assignments) somewhere
for this?

> scope.  Given that sort of maximal limited scope environment, just about 

I think in many cases they may have been sold to users that have not
been running multicast, but the apps do help drive multicast deployment
since the users want to use these things throughout their internetwork.

The entire 224/4 space is turning into a large swamp full of sub-blocks
that we're filtering and scoping to mitigate side effects of worms and
and random scans.  It doesn't seem to bother the vendors who've picked
something in one of the large swampland of scoped/filtered netblocks, so
let's pick a real, but single swampland netblock so we only have to scope
and from there here on out.

John

---

From: Beau Williamson <[email-masked]>
Date: Fri, 28 Jan 2005 18:36:57 -0600

>and from there here on out.

Yes, that has been proposed before and is a possibility in my 
mind.  However, here's the problem:

Say you get a xxx/16 or larger block out of the global space reserved for 
Scoped Addresses inside an Enterprise.  How do you carve up this space for 
various scopes???  You can't. That's because you have no idea how the 
Enterprise admin is going to scope his network.

All we know for sure is that the Enterprise admin is going to have a scope 
of the nature of the Local Scope (i.e. the smallest possible scope within 
an Enterprise) and a scope of the nature of the Org-Local Scope which is 
Enterprise wide.  (In the most degenerate case, these scopes are one and 
the same in size.) Anything in between these two extremes of scopes sizes 
is up to the Enterprise admin to determine and thus unknown.

Even if we pre-allocate this new address range into Local and Enterprise 
wide scope ranges (the two extremes above), how can the application 
developer know ahead of time which scope the Enterprise admin wants to run 
his application in so they can request IANA to assign them an address from 
the correct range???  Answer: He can't.  (Or at least I haven't figure out 
a way.)

The bottom line is that as far as I can see, you HAVE to have some 
light-weight SADP like mechanism no matter what you do.  This is so that 
the Enterprise admin can assign, control and map the application address 
into the desired scope range. At the same time, such a mechanism allows the 
developers to be independent of any specific network architecture 
requirements like having to have MADCAP servers or any other address 
assignment servers to be in place before the application can run.

If we don't go with this sort of SADP approach, we are back to building 
custom ACL's to cover the various addresses and the administration of 
scopes and their ranges goes down the porcelain fixtures.

Beau

---

From: John Kristoff <[email-masked]>
Date: Sun, 30 Jan 2005 21:29:41 -0600

On Fri, 28 Jan 2005 18:36:57 -0600

[...]

It's just one problem, but only if multiple scopes must be defined and
accompany this group addressing scheme.  I'm not really convinced this
is either necessary or required, at least in this case.

[...]
> scopes and their ranges goes down the porcelain fixtures.

We're doing that now, that is the problem.

John

---

From: Brian Haberman <[email-masked]>
Date: Mon, 31 Jan 2005 11:43:16 -0500

I will just point out that RFCs 3306 & 3307 solve this problem for
IPv6.  The application can request a specific group ID that is
irrespective of the scope of deployment (which is controlled by
the "scop" field in the IPv6 multicast address prefix.

We just have to make sure that the application developers are
aware of this new approach in IPv6.

I have to agree that the IPv4 case is quite complex and probably
needs some form of SADP mechanism.

Regards,
Brian