[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flow label versus Extension header - protocol itself


El 05/05/2005, a las 1:37, Greg Daley escribió:

Hi Marcelo,

marcelo bagnulo braun wrote:
[cut]



Yes, this is the case.  If the existing 3697 (sender side) allocation
for flow labels is used, then explicit signaling to add each
<source,dest,label> to a multihoming context has to precede packet
delivery.

Maybe i am missing something here, but this is the case, independently of the mechanisms you choose to carry the context tag, because of security issues....
I mean when a node is adding a new locator into an established shim context, it must send an explicity message, informing of that new locator and including security information in order to validate this new locator. In this exchange used to add and verify the new locator, the receiver could inform the transmitter about the new flow label value (if needed)
So i would say that explicit signaling when adding a new locator is always needed. 

Yes, it's always needed, but the time ordering of the packets to do
the signalling may not be strict.

If the upper layer protocol is ESP with authentication (or AH), for
example, it will be possible to identify that the flow belongs to an
upper-layer data stream because of the SPI, and the fact that the
packet authenticates using the right HMAC.


Are you considering the situation where the verification of the new locator is done through IPSec?

I mean, so far, i think we had considered the case where the addition of new locators had its own security mechanism (different from IPSec) and that there was an explicit signalling message for adding new locators to the set, and that these messages carry their own authentication information.
I mean, i think it is important to properly define what scenarios are we considering...

This may not be palatable to all, but the possibility is there
(and may be dismissed later).

Packets sent before the signaling wouldn't be guaranteed to get
through, but if the actual signaling took computation time

Well, i my understanding data packets carrying new lcoators that have not been added to the locator set through proper signaling will be discarded... I mean this is similar to MIP RO, a CN won't understna packets coming from a CoA before the BU binding the new CoA to the HoA has been received and verified, right?

(or a longer, reliable signaling path), this is an optimization
which would work well for some data.

Please note that if strict ordering of signaling before packet
arrival is required, then receiver side flow label allocation
isn't required itself for ensuring decodability just based on
the IPv6 header.


I ma not sure i agree here

 Only unique-to-sender label allocation is
needed to avoid label collision,

right, but the problem here is how to deal with the case where the sender runs out of flow label values and he needs to start re-using flow labels. In this case, the receiver based flow label allocation mechanism that you suggested seems to provide an elegant solution to this problem.

regards, marcelo

since no label selected on the
host will collide with its own (going to any of its destinations),
and the <source, label> pair is sufficient to identify it
to the receiver.






a possible question would be if it would be possible to include the signalling in the same packet that carry the new locator as source address... i guess this depends on how you define the packet processing, but i guess it may be possible in any case. 

I'm not really fond of piggybacking data.

It's possible of course but has potential issues with MTU.

Separate signaling is also much easier to describe and
implement.

Greg