Thoughts about layering multi-addressing

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

[Disclaimer: I am badly behind my reading of shim6 list.  Please keep  
me in CC: in this particular discussion.]

This is related to the AP I got together with some other people, as  
recorded in the minutes:

> Pekka Nikander, John Loughney and Christian Huitema to prepare some  
> initial ideas (slide pack / draft) on a bi-directional SHIM / ULP  
> API that would include the ability for the ULP to obtain/share  
> locator pair path info and then express a locator pair preference  
> to the SHIM (i.e. keep the notion of binding sessions at the  
> transport level but allow ULP signaling to include Loc Pair  
> preferences to be expressed) in addition to sending the SHIM the  
> trigger / heartbeat information associated with the current  
> locator   pair.

According to my own notes, also Iljitch was volunteering to work on  
this.

So, before I/we start writing a draft in this space, I'd like to poll  
the WG opinion on the viability of the basic approach, as outlined  
below.  Note that this is an area where I really think that running  
code or simulations would help.  We also need to get some transport  
area people involved.

Getting to the subject, the current "theory" of shim6 implementation  
seems to be that the shim6 layer rewrites the locators to identifiers  
for incoming packets and vice versa for outgoing packets.  While that  
may be fine in the short run for TCP and UDP, we seem to want a  
different approach for SCTP, probably also for TCP in the longer run,  
and maybe even for UDP.

The current "theory" can be visualised as follows:

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

There are couple of other approaches, both of which seem to be  
architecturally compatible, AFAICT, but also create the kind of  
enriched interface (not really an API) between the shim6 layer and ULs.

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.

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?
  - ability to get the full set of locators related
    to a given ULID
Anything else?

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