[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