Re: shim header in every shimmed packet

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

On 12-okt-2005, at 15:29, marcelo bagnulo braun wrote:

> right, but as was noted, a single bit is not enough for demux, so  
> an alternative context tag is needed.

No, I don't believe this is necessarily the case. I can imagine  
different ways to accomplish this, but let me just describe the  
simplest one.

Hosts A and B communicate. A has addresses A1 and A2. In the case of  
B it's a bit more complex: B has ULID/locator addresses B1 and B2,  
but these aren't valid locators for each other: B1 has the  
alternative locator B1' and B2 has the alternative locator B2'.

The chosen ULIDs for a TCP session are A1-B1. However, at some point  
B1 fails and the communication is rerouted to A2-B1'. The context has  
tag X but therere is no shim header in the packets flowing from A to B.

When B receives a packet, it can recognize that this is a shimmed  
packet because the locator B1' is present. B then goes looking for a  
context with ULID B1 on B's side and locator A2 at the remote side.  
Since there is only one such context B finds the X context, rewrites  
the addresses and the packet is handed over to TCP.

Now if an application tries to set up a session from A2 to B1, when A  
tries to set up a new context Y B notices that this context and the  
existing A1-B1 can't be disambiguated without a shim header so it  
tells A to use the header for this context.

A2-B1' packets without a header are then still mapped to context X  
while packets belonging to context Y are recognizable as such by  
their context tag in the shim header.