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

Re: shim header in every shimmed packet



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.