RE: Thoughts about layering multi-addressing

[<john.loughney@nokia.com>]

Pekka,

Couple points embedded:

>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.

I agree with this, I also wonder if anyone has any input from
how upper-layer protocols interact with SCTP.  I know this isn't
directly equivalent, but as SCTP is providing a handle to ULPs
which acts as a locator; SCTP provides path-probing and some other
features, I think that we might already have some insights into
what it does well & what can be improved.

>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.

I agree.  At least with SCTP, my guess is that it might want to use
multiple locators or handles to the shim layer.  I don't think that
we should force multi-homing aware transports into using a single
locator.

[text clipped]

>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.

I agree.  Geoff has said, in the past, that he sees some vertical
signaling needed; this also could be considered as part of the 
'rich API' for the shim layer.  

>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.

Pekka, who is doing the 'telling' to the shim layer?  If it is
the transport layer, then I think we are a bit safer, especially
if ULPs can fork-off of the main shim state if they realize
that the prefered locator pair isn't working for them.  Another
mechanism might be some sort of 'policy' object that gives a
preference or default for a locator.  My guess is that there
may be some overlap with the "Distribution of RFC 3484 address selection
policies"
thread in the IPv6 wg; basically being practical, multihoming support
in IPv6 seems especially critical in enterprise environments,
and I am sure that netadmins will want to inform users of
prefered paths.

>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?

Those seem like good first cut requirements, some of the other
things are more optional features but support would be needed,
IMO, for:

 - some level of failure detection, especially at interface 
   (for example, the ethernet cable is unplugged or the access
   router is out).  If I am not mistaken, this might be the
   level that Paul is getting at.
 - support for some simple policy mechanism or for signaling
   prefered locator.

>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.)

That's engineering!

John