Subject: [magma] Re: mboned: Bidir-PIM and embedded-RP

From: David Meyer <[email-masked]>
Date: Tue, 6 Apr 2004 12:20:07 -0700

Dino/all,

On Tue, Apr 06, 2004 at 11:09:44AM -0700, Dino Farinacci wrote:
>> >> I have always liked this idea.  Do we also have a response message
>> >> that allows the first-hop router to acknowledge the source-join?
>> 
>>     In the spirit of IGMP/MLDv2 we should not have acks (and use the same
>>     robustness variable logic for the RTS packet). I propose a packet that 
>>     contains:
>> 
>>     o Source address
>>     o Group address
>>     o Holdtime
>>     o MD5 hash
>>     o Approximate IPD
>> 
>>     1) Source/Group address is in AFI format to support multiple address 
>>        families. You want the source address because you may allow a system
>>        to (with different source address in the IPv4/IPVv6 header) allow
>>        other servers on the LAN to source the data.       
>> 
>>     2) Holdtime can be sent with 0, when the source decides it wants to stop
>>        sending. Otherwise, it is the value for how long it plans on sending.
>>        But should not be authoritative. So if the source keeps sending past
>>        this time, the first-hop routers should consider the source still
>>        active.
>> 
>>     3) A MD5 hash to validate the source is *allowed* to send. since it is
>>        a local matter on the LAN, we can use configuerd shared-keys and not
>>        worry about key distribution. Then the routers will not create (S,G)
>>        state when there isn't a previous RTS sent. This will help on rogue
>>        and malicious sources.
>> 
>>      4) IPD is the approximate Inter-Packet Delay so for an ASM group the
>>         routers could decide to keep state longer. So if the IPD is 5 minutes
>>         the first-hop routers don't have to time out (S,G) state in their
>>         default of 3 minutes (or 210 seconds). A simple optimization.
>> 
>>      Anything else? It might be good to know when the source will start sending
>>      after the RTS message is sent. This allows the network to know what the
>>      state creation budget is. But this might be hard to convey down the
>>      protocol stack in the source host (maybe just have it configurable).
>>   
>>      But I think we should discuss this last point.

	A couple of things:

	(i).	First, I like the idea (and the packet you
		suggest). It also looks like MD5 is sufficient to
		protect against malicious addition and/or removal
		of state, and "validate" authorized senders
		(well, sort of; but still sufficient). 

	(ii).	With regard to the last point (when a source
		might start sending), a hint might be nice here
		(as you say, so a router might get a rough idea
		of the overall state creation budget); however,
		there are likely human factors issues (as well as
		the implementation issues you describe) that will
		make an accurate estimate difficult.

	(iii).	I also want to cut the folks over in magma into
		this discussion, so I am cutting the cc'ing them
		in the event they are not watching...

	Dave

_______________________________________________
magma mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/magma

---

From: David Meyer <[email-masked]>
Date: Tue, 6 Apr 2004 12:20:07 -0700

Dino/all,

	A couple of things:

	Dave

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 6 Apr 2004 16:24:04 -0700

>> 		make an accurate estimate difficult.

   Right, the keyword is "rough".

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 6 Apr 2004 16:24:04 -0700

Dino

---

From: Stig Venaas <[email-masked]>
Date: Wed, 7 Apr 2004 09:50:56 +0200

>    Right, the keyword is "rough".

Could you or someone give some rough estimate for how long time it
might take to build source branch from source to RPA if one does
as Lorenzo proposed, using DF-election? Just what the order of
magnitude is when there are say 5, 10 or 20 hops. It's only a few
seconds, isn't it?

I tend to agree getting some kind of signal back when the branch
is created is too complex, too much signalling. I did say how I
think it could be done, but I'm not sure I like it (:

If were talking about just a few seconds, it's not too hard for
an application to just wait a bit if it really cares about
initial losses. We have a problem if the time to build the branch
is close to the time we want as expiry, but it's much smaller,
isn't it?

Stig

---

From: Stig Venaas <[email-masked]>
Date: Wed, 7 Apr 2004 09:50:56 +0200

Stig

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 07 Apr 2004 11:11:46 +0200 (MEST)

> 		(well, sort of; but still sufficient). 

Don't we have another approach for the same purpose, instead of
changing igmp/mld? I'm a bit curious that changing igmp/mld not only
takes time but also is not greatly effective.
As some of you already thought, security definition or policy
configuration should also be considered for the point you've been
discussing here. But igmp/mld would not work for that purpose.

How about using new multicast session announcement for a data sender's
discovery/acknowledge/authentication/etc.?
I don't say we'd use/modify SAP for that purpose as it would not be
useful for general/common multicast (i.e. SSM) services - if exist -
in the Internet. This means in any case we need to develop a new
session (channel) announcement protocol/system/whatever for
SSM-capable network in near future. Hence it might be a good timing to
start the work including all thoughts you've discussed.
If there is a useful channel announcement system, it is easy for
multicast routers to collaborate with it and then any source can be
validated.

In fact I did a related work, so you can look at it if you are
interested in.
http://www-sop.inria.fr/planete/Hitoshi.Asaeda/papaer/SAINT2004.ps
(In this paper, we proposed using TCP for the communication between a
router and the channel announcement system in order to avoid major
protocol modification, but it would be possible to replace it to
another one.)

> 		make an accurate estimate difficult.

Exactly.
In any case all senders must *register* themselves when they send
their data or when they schedule sending the data. Using a channel
announcement system would be straightforward.

> 		in the event they are not watching...

I think most of us have been subscribing both, though.:)

Thanks.
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 07 Apr 2004 11:11:46 +0200 (MEST)

Exactly.

Thanks.
--
Hitoshi Asaeda

---

From: Hitoshi Asaeda <[email-masked]>
Date: Wed, 07 Apr 2004 12:11:20 +0200 (MEST)

> http://www-sop.inria.fr/planete/Hitoshi.Asaeda/papaer/SAINT2004.ps

Oops, not papaer but paper.
--
Hitoshi Asaeda

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 8 Apr 2004 23:12:00 -0700

>> magnitude is when there are say 5, 10 or 20 hops. It's only a few

    Assuming the DF election happens for the RP from the embed-RP group
    address only on the interfaces leading to the RP (as well as all the
    routers on the LANs leading to the RP), it will be equal to the offer
    period plus some noise for message propagation time and processing.

    The offer period of 100 ms times the DF election robustness variable which
    defaults to 3 is the amount of time you wait (300ms) before selecting a DF
    on the interface.

    So sum that up for each hop between the source and RP LAN. So for 20
    hops, it is a couple of a few seconds.

Dino

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 8 Apr 2004 23:12:00 -0700

Dino