[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Thoughts about layering multi-addressing
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
>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
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
>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
Those seem like good first cut requirements, some of the other
things are more optional features but support would be needed,
- 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
>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.)