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

Detailed approaches for demux

Hi,

This is an attempt to wrap up part of the exchange we have about context tags. I have tried to write down how the detailed procedure for using the flow label would look like (based on Pekka S. initial mail).

It is a long mail, sorry for that, but i hope it helps to understand the complexity of the solutions and the trade offs involved.

Flow Label Approach

Goal: use the Flow Label of the IPv6 header to demultiplex incoming SHIM data packets. Demux operation consists in translating the address (locators) contained in the source and destination address fields upon reception to the addresses used when the communication was established (ULIDs). In few words, demux is translating locators to ULIDs in incoming packets. Note that demux is only required after a rehoming event, after which the locators differ from the ULIDs. Before the rehoming, the demux operation is null.

Requirements:
R1: Given a source and a destination address, the flow label value must remain constant during the lifetime of the communication. In other words, when the initiator host establishes the communication, it includes a flow label value. such value must remain unchanged during the lifetime of the communication. However, note that: First, for each direction of the communication the flow label may be different, i.e. packets flowing in different direction of a communication can carry different flow label values. Second, after a rehoming event, it is acceptable that the flow label value changes. This is because a rehoming event implies a change in the addresses carried in packets, so the requirement to preserve the same flow label does not hold. This seems reasonable since a rehoming event implies a change in the path, so it seems reasonable to expect changes in the way packets are treated along the path.

R2: SHIM context delayed establishment must be supported. This means that is must be possible to setup a regular (non SHIM) IPv6 communication between two SHIM enabled hosts and later on, establish a SHIM context for that communication, so that it can benefit from the SHIM features. This implies that it is not possible to assume that SHIM signaling packets are exchanged during the establishment of the communication.

R3: Dynamic locator set must be supported. This means that the locator set available for a SHIM context can change during the lifetime of the communication, and in particular during the lifetime of the SHIM context. This means that it is not possible to assume that the locator set available for a context can be known beforehand.

Corollaries:

R1 & R2 imply that the flow label value used for packet carrying the addresses used for establishing the communication (ULIDs) are assigned by the transmitter of the packets i.e. that if the communication is established using IPA and IPB, then the flow label of packet flowing from IPA to IPB is defined by IPA before sending the first packet (and the same in the other direction)

Flow label based mechanism

(This is basically what was described by Pekka S. in his first mail)

Initiator I with addresses S1,...,Sn
Receiver R with addresses R1,...,Rj

Initiator I sends the first packet of the communication and associates the flow label value fi. The flow label value selected is reserved and not used for any other communication. (This means that as long as the communication exists or the SHHIM context exists, this value is not used for any other communication, if it is possible, see below).

When establishing the SHIM context, use the same flow label value.

When re-homing, also use the same flow label value with alternative locators.

Demux at the receiver side is performed based on (flow label, src, dst)

The problem is what happens when a host run out of available flow label values and need to start repeating. Note well that this happens when the host has 1.048.576 (2^20) simultaneous communications.

If a repeated value is used in a communication with a different node, then no problem, since the addresses will never collide.

So, the first measure to avoid problems is to avoid re-using flow label values for communications with the same host whenever is possible.
However, this is not always possible because the initiator may not be aware that two communications are established with the same node.

So, the problem occurs when the same value is used for the same host.
This may occur because the initiator may not be aware that two different addresses belong to the same receiver.
For example, consider the following case:
I establishes a communication with R1 using S1 as source address and assigns the flow label value f1.
Next, I runs out of flow label values, and need to start repeating values.
At this point, I establishes a communication with R2 using S2.
Since the Destination address R2 has not been previously used, I has no means to know that is the same host, so I assigns the flow label value f1.
When the SHIM contexts are established for each of the communications, the resulting contexts are:

SHIM context for the first communication:
ULIDs: I1,R1
Flow Label: f1
Locator set for I1: I1,...,In (or a subset)
Locator set for R1: R1,...,Rj (or a subset)

SHIM context for the second communication:
ULIDs: I2,R2
Flow Label: f1
Locator set for I2: I1,...,In (or a subset)
Locator set for R2: R1,...,Rj (or a subset)

The problem is that the tuple (flow label, src, dst) does not provide enough information for proper demux

The possible solution for this is not to allow overlapping locator sets when the same flow label value is being used in the two contexts.
This means that in the previous case, when the context are established, the nodes avoid adding locators to the locator sets that would result in overlapping src,dst address pair combinations.

So, if we apply this to the previous example, the result is:

First communication: I1,R1

Second communication: I2,R2

At some point, I decides to create a SHIM context for the first communication, so it proposes through SHIM signaling, the following context parameter:

ULIDs: I1,R1
Flow Label: f1
Locator set for I1: I1,...,In

Upon reception of such information, the receiver R replies proposing the following locator set for the context:

Locator set for R1: R1,R3...,Rj (R2 is not included so that I2, R2 is not valid combination for this context)

Next, the initiator establishes the SHIM context for the second communication, proposing the following parameters:

ULIDs: I2,R2
Flow Label: f1
Locator set for I2: I1,...,In (or a subset)

At this point the receiver replies proposing the following locator set:

Locator set for R2: only R2 because all the remaining combinations are included in the SHIM context of the first communication.

Through these means, proper demux can be guaranteed.

I think this provides proper demux functions.
The problems that i see with this approach are:
- Complexity
- In some corner cases, some communications will end up with limited fault tolerance because of a reduced set of locators.


Extension Header/DST option Approach

We could compare this with a solution based on carrying the context tag in an extension header/dst option.

The solution could be something like this:

The initiator establishes a communication. No SHIM context tag is assigned.

When the context is established, a receiver-based context tag allocation procedure is used, so that each side informs the peer a unique context tag that has to be used for sending packets that carry locators that differ from the ULIDs. Context tag can be of 128 bits, so to make sure that we never run out of them. (maybe a lower value would provide similar guarantees)

I think this would work too. Clearly, this is simpler. Clearly, it introduces more overhead.

However, the differences are more relative in the current case. I mean, in the general case, we won't run out of flow label values, so it normally will be like using an unique context tag. OTOH, normally, there won't be outages, so, no extension header will be included in packets.

Regards, marcelo