API for SHIM

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Hi,

I guess that one of the issues that are open for discussion is the API 
for shim. In order to continue the discussion on this, I have tried to 
identify the potentials options for an extended API for SHIM that have 
been brought up in the list

Here it is an initial version of the list from the stuff that i recall 
that have been discussed over the years here.

- The application should be able to tell the shim to
initiate a communication with a given peer and use
the shim for that.
There are several cases for this:
  - The connect-by-name case, where the application
    indicates that it wants to initiate a communication
    with a FQDN and the resolver obtain different IP
    addresses for that FQDN and tries to use them to
    establish the communication. Not sure if the shim
    needs to be involved for this
  - The connect to an ULID case. In this case the
    application decides to establish a communication
    with a given ULID and the shim may be required
    if the ULID is unreachable/unroutable. The shim
    will attempt to establish a context using the
    ULID selected by the application and using
    alternative locators. The question is how does
    the shim retrieves the alternative locators?
    The options for this may be to cache information
    obtained by the DNS (i.e. when the query for a
    FQDN returns multiple addresses, these are passed
    to the shim as a hint about alternative locators)
    The other option would be to use the reverse DNS,
    as suggested in draft-nordmark-shim6-esd-00.
  - In addition, the application may want to inform
    about locators that are not working, or in
    particular that the ULID is not reachable. This
    may be useful in the case that the application
    is triggering the shim context establishment
    because of a failure in an ongoing communication.


- The application should be able to inform the shim
  about the timeout values for detecting a failure,
  for sending keepalives, for starting the exploration
  procedure. In particular, the application should be
  able to suppress the keepalives

- The application should be able to inform the shim
  if hot stand-by is desired, so that alternative paths
  are being probed when the current locator pair is
  working.

- The application should be able to tell how aggressive
  the alternative path exploration procedure is desired
  i.e. the number of alternative path that are probed
  in parallel

- The application should be able to request not using
  the shim for this communication

- Forking related options. In particular, the
  application should be able to request the creation
  of a Forked Instance for a context, and should be
  able to set the preferences for that forked instance,
  the same as a regular context.

- The application should be able to inform that an outage
  has occurred. Also it should be able to inform that the
  performance of the current locator pair is not
  satisfactory any more and that the shim should launch
  exploration and an alternative locator pair that works
  better (for some definition of better that may be
  included in the request.

- The application should be able to select a locator pair.
  A particular case for this, is that application should
  be able to tell the shim that it prefers using the ULID
  pair as locator pair as long as they are working.

- The application should be capable of obtaining the
  locator sets, local and remote, available for a shim
  context. In addition, the application should be able to
  obtain the preferences for that locators as well as other
  information, such whether the locator is reachable or not.

- The application should be able to set the preferences for
  the locators, local and remote one and also to the
  preferences of the local locators that will be passed to
  the peer.

- Interaction between RFC3484 and the shim. In this case,
  the information available in the shim could be used to
  influence RFC3484 selection procedure, so that
  unreachable locators are avoided.

Others??

Regards, marcelo