Re: Flow label - the problem

[Iljitsch van Beijnum <iljitsch@muada.com>]

On 24-apr-2005, at 5:28, Erik Nordmark wrote:

> > However, a good way to enforce this is to disallow overlap  
> > between  ULIDs and additional locators. So if a host sees prefixes  
> > A and B, it  forms four addresses:
> > A::ULID
> > A::locator-for-B
> > B::ULID
> > B::locator-for-A

> I wouldn't say that this is forbidding the applications from  
> selecting the ULID. Instead I view this as a different way to carry  
> information to the receiver to help it disambiguate the packets  
> (and what rewriting is needed before passing the packets to the  
> ULP); you are effectively carrying that information in the IP  
> address fields.

Right, and these are big and many bits in them can generally be  
filled in by the host so that could work very well.

> > Another way is to allow more than a single shim6 association at  
> > one  time between two hosts,

> I don't understand how this would work.
> Whether or not there is a single shim6 association isn't the key  
> issue.
> The issue is that the receiver will need to handle packets with the  
> same locator pair in them, where some of them need to have those  
> locators replaced with different ULIDs before passing them to the ULP.
> To do this there has to be something in the packet that can  
> distinguish the packets. Could be by effectively carrying the  
> disambiguating information in the address fields as you suggest  
> above, the flow label, or some separate context tag carried in the  
> packet. And this extra information can be skipped when the receiver  
> doesn't have to rewrite the address fields.

I was trying to address the issue on a conceptual level with the  
above and this:

> > or to have transport sessions with different  ULIDs within a  
> > single association. In this case there are four ways  to determine  
> > the right ULID set:

The difference is that either you send letters addressed to different  
people living at the same address in different envelopes, which has  
the upside that there doesn't have to be any demux info in the letter  
itself but the downside that there must be more demux info on the  
envelope and more envelopes, or you send all letters to one address  
in one envelope and demux the letters when they come out of the  
envelope.

For TCP/UDP/SCTP/RTP the port numbers can be used to demux, and the  
flow label can take the place of the port numbers as an optimization.