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

Re: Thoughts about layering multi-addressing

Hi Pekka,

thanks for describing this so clearly... some comments/questions below...

El 18/08/2005, a las 17:03, Pekka Nikander escribió: 

Approach one:  Annotate ULIDs with locators

                 ^  v
                 |  |  ULIDs (annotated with locators)
             +----------+
             |  shim6   |
             +----------+
                 |  |
                 ^  v  Locators (and only locators)

In outgoing packets, the optional locator annotation could indicate the locators that the transport prefers to use, if they are available according to the shim6 knowledge. In incoming packets, the locator annotation indicates the locators as found in the incoming packets. ULIDs that don't understand the annotations continue to function according to the current "theory".

Approach two: Send locators up but annotate them with ULIDs

                 ^  v
                 |  |  Locators (annotated with ULIDs)
             +----------+
             |  shim6   |
             +----------+
                 |  |
                 ^  v  Locators (and only locators)

While the information content here is the same as in the previous case, the difference lies in what transports see by default. This might work better with unmodified or minimally modified multi-homing aware transports, such as SCTP and DCCP.


In any of these approaches, the locator annotated for outgoing packets are a suggestion of they must be honored? i mean, i guess this is related with how does the shim informs the ULP that a given locator is no longer reachable, right?

The architecturally guiding principle in this is to keep IP only aware of the plain set of locators associated with each ULID, the required encapsulation/marking information (such as the flow label), and nothing else. Annotating the ULIDs with locators (or vice versa) allows more capable transport protocols to keep track of them and associate path-related parameters such as RTT, bandwidth estimate, etc, separately with each locator pair. This allows the transport-related functionality to remain located at the transport layer. At the same time, any changes in the locator set need to be secured only at the shim layer, i.e. only once per each ULID pair rather than separately for each transport connection.

In addition to this basic mechanism, some transport may need to figure out the complete set of locators available. However, are there any other functions that would be needed? For example, if the transport can give outgoing locators as hints to the shim-layer, it does not need to tell the shim-layer to deprecate any locators even though it suspects that some of they may not work any more. Indeed, telling shim to prefer some over others may be dangerous since different locator pairs may work for different transports, due to the Internet not being fully transparent any more.

Hence, my question is if the transport are likely to need anything else than the following:
- both ULIDs and locators in incoming packets
- ability to define locators for outgoing packets
- what happens if the locators are not available any
more? Host-internal ICMP-like response?

coming back to this point.. by locators you mean locator pair, right? i mean the shim should inform the ULP that a given locator pair is no longer reachable, right?

  - ability to get the full set of locators related
    to a given ULID
Anything else?


I wonder if it wouldn't be useful to allow the ULP to inform the shim about some sort of preferences w.r.t. which alternative locator pair to try with in case of an outage.

I mean, the question is if it wouldn't be interesting to let the ULP to inform about which locator to try if an outage occur. This may make some sense in the case that the different access links have different characteristics and that each app has a strong preference on which links to use.
A somehow related aspect was brought up the other day by Iljitsch, w.r.t. to returning to the initial locator once that the failure has been repaired.

Regards, marcelo

One other practical problem here is to figure out how to make this all work with high speed servers, which are likely to have IP and TCP implemented with firmware at the NIC. (Kudos to Christian for pointing this out.)

--Pekka Nikander