Subject: [MULTIMOBSEC-API] api requirements

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 05 May 2006 15:18:40 +0900

Hi Miika and all,

I am sorry for being late (at least a week later than planned...)
but let me send you a draft which is a compilation of the requirements
for API identified/discussed on the SHIM6/multimobsec-api/BTNS
mailing list in the past.  Attached please find the document in
{txt,html,xml} format.

At the moment, the draft only contains the requirements for common
API for both SHIM6 and HIP, and some identified issues.  Most of the
items were from Marcelo's email about API for SHIM [1].  I hope this
is useful for identifying the requirements for API for (generic)
multihomed environemtn which is based on ID/Locator separation.
At the moment, as I failed to see relation to BTNS so no relation
is mentioned.  But I am open to discussion.

After we discuss and agree on requirements, we can work on specific
solutions.  Hope its useful and I appreciate your comments.  Especially
I would like you to check Section 5 and see if anything is missing.
Also, please feel free to modify the document.

[1] http://www.ops.ietf.org/lists/shim6/msg01191.html

Regards,
Shinta

_______________________________________________
MULTIMOBSEC-API mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/multimobsec-api

---

From: Miika Komu <[email-masked]>
Date: Fri, 5 May 2006 15:44:29 +0300 (EEST)

> [1] http://www.ops.ietf.org/lists/shim6/msg01191.html

Excellent! I will have a detailed look at the shim6 and btns requirements 
next week and give feedback.

-- 
Miika Komu              [email-masked]          http://www.iki.fi/miika/

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 8 May 2006 10:51:15 +0300

Here are some comments:

Network Working Group                                           TBD. TBD
Internet-Draft                                                       TBD
Expires: August 5, 2006                                    February 2006

                      Socket API for Multihome Shim

MB: s/multihome/multihomed?

...

Abstract

    This document specifies API for multihome shim layer.  The API aims

MB: s/multihome/multihomed

    to realize interactions between application and the multihome shim

MB: s/realize/enable

    layer for advanced locator management and interface to the essential
    information about failure detection and path exploration.

    This document is based on an assumption that a multhomed host is
    equipped with a 'shim' which maintains mapping of identifier and
    locator.  SHIM6 and HIP are the examples of the shim.  Hence, the API
    can be commonly used by SHIM6 and HIP.

...

3.  Terminology

    This document does not intend to give new definitions for technical
    terms that are relevant to multihomed environment but tries to
    inherit definitions provided in the existing documents as listed
    below:

    o  SHIM6 Protocol Specification[I-D.ietf-shim6-proto]

    o  HIP Architecture[I-D.ietf-hip-arch]

    o  Reachability Protocol (REAP)[I-D.ietf-shim6-failure-detection]

    For clarification, we provide definition for the terms that are
    frequently used in this document:

    o  Identifier (ID) - An identifier used by the application to specify
       the endpoint of the communication.  As addressed in [I-D.ietf-
       shim6-app-refer], application may refer to ID in different ways in
       different situations.  In case of SHIM6, the identifier is called
       ULID.  In HIP architecture, the endpoint of communication is
       represented by Host Identity Tag (HIT) which is a hash of the
       public key owned by the host.  By using HIT instead of public key
       for identifying the peer, legacy (non HIP-aware) application can
       also take advantage of HIP.

MB: Perhaps it would be more clear to explicitly state that in
HIP the identifier is the public key.

...
    o  Context - A state information to be shared by the two entities,
       which binds the ID and associated locators.  Note that the context
       can be uniquely defined by a pair of IDs.

MB: I not sure i understand this... i guess that in the case of forked
contexts in the shim, there are more than one context with
the same ulid pair...

       Hence, it could be
       possible for to hosts to establish multiple contexts that are
       based on different ID pairs.  Specific procedures to establish
       context is dependent on protocol of shim layer.

....
    o  Preferred Locator - The mostly preferred locator of the peer host
       identified by the ID.

MB: i don't understand this sentence..

       Note that preferred locator should be
       defined within a context.  As defined in [I-D.ietf-shim6-proto],
       prefered locator of a host whose ID is 'A' can be denoted as
       Lp(A).

....

4.  System Overview

                        +------------------------+
                        |       Application      |
                        +------------------------+
                                ^
                                | (via Socket API)
                                v
                +------------------------------------------+
                |               Socket Layer               |
                +------------------------------------------+
                                ^
        +-----------------------|---------------------------------+
        |                       v                                 |
        |   +-----------------------------+       +----------+    |  IP
        |   |            Shim             |<----->|   REAP   |    | Layer
        |   +-----------------------------+       +----------+    |
        |                       ^                      ^          |
        +-----------------------|----------------------|----------+
                                v                      v
                +------------------------------------------+
                |              Interface Layer             |
                +------------------------------------------+

MB: I am not sure what interface layer is...
perhaps some text would help...

    Figure-X illustrates the system overview.  Application can take
    advantage of the Socket API which can be used to interact with shim
    as well as REAP component.  The shim layer is somewhere between the
    IP layer and Transport Protocol Layer and it closely interacts with
    REAP component which is responsible for failure detection and
    reachability exploration.

TBD                      Expires August 5, 2006                 [Page 7]

Internet-Draft             Multihome Shim API              February 2006

5.  Requirements

    Following is a list of requirements from the application perspective.
    These requirements are based on discussions on the SHIM6 mailing
    list.  Besides, the list contains some issues raised during the
    technical discussions on the SHIM6 mailing list and some requirements
    are derived from Reachability Protocol document[I-D.ietf-shim6-
    failure-detection].

    o  Locator management - Locator management is primary role of the
       shim layer, which secures the delivery of IP packet to the peer.

MB: what do you mean by "secures" in this context?

       Although the shim layer is there to make the locator information
       invisible to the upper layer protocol, some advanced application
       may have desire to access the locator information.

       *  Application should be able to obtain list of locators of the
          host.  Ls(local) and Ls(remote).

       *  Application should be able to obtain preferred locator of the
          node.  Lp(local) and Lp(remote).

       [NOTE: The issue about locator management is well addressed in
       SHIM6 referrals document[I-D.ietf-shim6-app-refer]]

    o  Notification from application to shim layer about the outage.
       Application should be able to inform shim layer about outage in
       its communication.  REAP module may be triggered by this
       indication to invoke procedure of path exploration.  [NOTE: This
       is also addressed in section 5.2 of REAP specification]

MB: There were several discussions
on the ml whether positive or negative feedback would be more useful
i mean, here only negative feedback is considered, but it is
possible that positive feedback from the application is very
useful to supress the keepalives

    o  Hot-standby.  Application may request shim layer if hot-standby
       connection is needed.  Hot-standby is an alternative path (locator
       pair) which can be immediately replaced with the current locator
       pair.  Hot-standby may allow application to achieve better
       failover.

MB: i would put this more explicitly that here alternative paths known 
to be
working are availble

    o  Eagerness of locator exploration.  Application should be able to
       specify shim layer how aggressive it wants to search alternative
       path (e.g. specifying the number of concurrent attempts of
       discovering working locator pair) when an outage occurs on the
       path between the currently selected locator pair.

    o  Don't apply shim.  Application should be able to request shim
       layer not to apply ID/Locator adaptation but to apply normal IP
       processing at the IP layer.

TBD                      Expires August 5, 2006                 [Page 8]

Internet-Draft             Multihome Shim API              February 2006

    o  Providing locator information to application.  Application should
       be able to obtain information about the locator which was actually
       used to receive the packet.  With this information, application
       can verify if its preference on choice of locator is actually
       applied to its flow or not.

MB:locator or locator pair?

    o  Application should be able to specify if it wants to defer the
       context setup or it wants context establishment to be started if
       there is no available context.

MB:wouldn't this be shim6 specific?

MB: missing stuff:

- 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 select a locator pair.

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

TBD                      Expires August 5, 2006                 [Page 9]

Internet-Draft             Multihome Shim API              February 2006

6.  Issues of Handling Multiple Locators with Legacy Socket API

    In multihomed environment where either or both of the peers have
    multiple locators, there are some issues with legacy Socket API.

6.1.  Initial Contact

    When application to establish communication with its peer who happens
    to have multiple locators, there are some issues to consider.  In
    connection oriented communication, connect() system call is used to
    make the initial contact to the peer, which requires IP address and
    port number to specify the endpoint.  Hence, name-to-address
    resolution should be performed prior to connect().  Application needs
    to resolve IP address of the peer from its FQDN by any available
    name-to-address conversion method.  In typical case, the application
    receives information from resolver.  If the application ends up with
    receiving multiple IP addresses to reach the peer, there are several
    options to make the initial contact.  One option is to issue
    concurrent connect() with every locator of the peer, which is done in
    some applications today.

MB: actually the situation is more complex than this imho, since you
have also to consider the source addresses, so you end up with locator 
pairs
that need to be tried

    Another option would be to request shim
    layer for taking care of initial contact.  And behavior of shim layer
    will depend on the presence of the required context.  If there exists
    the context for the ID specified in the connect(),

MB: for the pair of IDs

    the initial
    contact can be made in accordance with the context information.
    Otherwise, shim layer should invoke context establishment with the
    peer ID specified in the argument for connect().  Additional efforts
    would be required in a case where the peer cannot be reachable by the
    ID (for example, ID is non-routable or non-IP reachable) but can be
    reached by alternative locator.  In particular, shim layer should
    somehow discover the alternate locator for the ID to establish
    context.  [I-D.nordmark-shim6-esd] addresses the possible approach to
    perform reverse DNS lookup from ID to FQDN, then perform forward
    lookup again to find the full-set of locators and ID.  However, this
    approach does not help the case where ID is not in form of IP address
    (e.g.  HIT in HIP case).

6.2.  Naming at Socket Layer

    getsockname() and getpeername() system calls are used to obtain the
    'name' of endpoint which is actually a pair of IP address and port
    number assigned to given socket. getsockname() is used when an
    application wants to obtain the local IP address and port number
    assigned for given socket instance. getpeername() is used when an
    application wants to obtain the remote IP address and port number.
    As IP address is the key information in the two system calls, there
    is a question if it should be identifier or locator when shim layer
    is present.

regards, marcelo

El 05/05/2006, a las 9:18, Shinta Sugimoto escribió:

> <multihome-shim-api.tgz>_______________________________________________

---

From: Jari Arkko <[email-masked]>
Date: Mon, 08 May 2006 14:37:04 +0300

The basic list of the requirements looks reasonable as
an optional extension of the socket API. But I wonder if
this cross-layer communication is really something that
happens not just between the shim and the app, but
between the shim, transport, and app (with possible
abstraction level changes in between). Do you see
a role for the transport layer to affect some of these
decisions?

--Jari

---

From: marcelo bagnulo braun <[email-masked]>
Date: Tue, 9 May 2006 16:44:48 +0300

El 09/05/2006, a las 10:11, Shinta Sugimoto escribió:

> Right, but I think we are not going to handle forked context in this
> API document as it's specific to SHIM6.

agree but shim context must be included in the generic context concept, 
right?

>   What I am trying to describe here
> is a generic concept of a context which holds a mapping of ID and 
> locator.

agree, but this does not mandates that there must be only one context 
by ulid pair used, right?

> When it comes to HIP, a HIP association is certainly more than a 
> binding of
> ID and locator, but we will be focusing on ID-locator binding aspect in
> this document.  Would following sounds better ?
>
> <t>Context - A state information shared by the two communicating 
> entities,
> which essentially stores a binding of ID and associated locators.  The
> context is maintained inside the host at shim layer and each context 
> can
> be uniquely identified by a pair of ID.</t>
>

why don't just remove the last part of the the last sentence? i.e.

<t>Context - A state information shared by the two communicating 
entities,
which essentially stores a binding of ID and associated locators.  The
context is maintained inside the host at shim layer.</t>

> would this sound better ?
>
> <t>Preferred Locator - The mostly preferred locator among the list of 
> available
> locators for the entity.</t>
>

ok, i understnad what you mean, i think

What about:

<t>Preferred (Source/Destination) Locator - The (source/destination) 
locator
currently used to send packets.</t>

...

> Maybe I should say 'assure' here.  I was trying to address that locator
> management is significant in a sense that it determines reachability to
> the peer.
>
> would following sound better ?
>
> <t>Locator management - Locator management is the primary role of shim
> layer in a sense that it determines reachability to the peer.</t>
>

but i guess that there is more than just reachability, right i mean 
there is also policy and preferences of both peers and different 
performance of the addresses and so on. I guess that locator management 
is about selecting which locator to use for a given context taking into 
account all these aspects

> I see.  What about following ?
>
> <t>Notification from application to shim layer about the status of
> communication.  There are mainly two aspects of the feedback that
> application or upper layer protocol may provide for shim layer:
> positive feedback and negative feedback.
>
>     <list style="symbols">
> 	<t>Positive feedback could be done in a way that application
> 	or upper layer protocol (e.g. TCP) may inform shim layer that its
> 	communication is going well and provide timeout values for detecting
> 	a failure, sending keepalives, and starting the exploration procedure.
> 	</t>
>

ok this sounds good
however, i would not include in this particular item the considerations 
about the application/transport providing timeout and other timers to 
the shim. I mean, this is about notifications of events (communication 
working fine event or communication broken event) which imho is 
conceptually different from communication parameters like timers...

> 	<t>On the other hand, application or upper layer protocol may also
> 	provide negative feedback for shim layer indicating that its
> 	communication status is not satisfactory.  In such case, shim layer
> 	may initiate keepalive or path exploration.</t>
>     </list>
> </t>
>
> Ok.
> <t>Hot-standyby.  Application may request shim layer if hot-standby
> connection is needed.  In this case, alternative paths are known to
> be working.  Hence it is possible for the host to immediately replace
> the current locator pair with the alternative locator pair.  
> Hot-standby
> may allow application to achieve better failover.</t>
>

ok

> Ok.
> Yes, it is.  We may eliminate this.
>
>> MB: missing stuff:
>>
> Ok, this is the positive feedback.  Understood.
>

that was not what i had in mind, actually, see above

> Well, doesn't this mean that we should specify API for
> handling forked context ?  Assuming that we let application
> to decide preferred locator for particular flow, that may end
> up in creating a context information which is specific to that
> application (or better to say process).  I think it's good to
> have such feature but my question is do we support it in common
> API ?  What do you think ?
>

good point.. i don't know really... perhaps include it as a discussion 
point?

> Ok. I will add this.

i guess this is the samecase than the previous one, whether it is ok 
for a particular app to define the preferences for the context...

> [snip]
> Correct. rephrased as follows.
>
> <t>When application to establish communication with its peer who
> happens to have multiple locators, there are some issues to consider.
> In connection oriented communication, connect() system call is used to
> port number to specify the endpoint.  Name-to-address resolution
> should be performed prior to connect().  Application needs to resolve
> IP address of the peer from its FQDN by any available name-to-address
> conversion method.  In typical case, the application receives 
> information
> from resolver.  If the application ends up with receiving multiple
> IP addresses to reach the peer, it should iterate each destination 
> address
> one-by-one.  It should also be noted that the host may also have 
> multiple
> source addresses.

i would add " The different resulting address pairs may have different 
reachability status so, in order to find a working address pair, it may 
be required to explore all available address pairs (as opposed to 
explore all available destination addresses)

regards, marcelo

---

From: Shinta Sugimoto <[email-masked]>
Date: Tue, 09 May 2006 16:11:59 +0900

Hi Marcelo,

Thank you for your quick feedback. Please find my comments inline.

On Mon, 8 May 2006 10:51:15 +0300

Ok.

Ok.

Ok.

> HIP the identifier is the public key.

Ok, I will rephrase the text in a way that essentially the public key is
playing the role to idenfity the host/endpoint and HIT serves as an identifier.

Right, but I think we are not going to handle forked context in this
API document as it's specific to SHIM6.  What I am trying to describe here
is a generic concept of a context which holds a mapping of ID and locator.
When it comes to HIP, a HIP association is certainly more than a binding of
ID and locator, but we will be focusing on ID-locator binding aspect in
this document.  Would following sounds better ?

<t>Context - A state information shared by the two communicating entities,
which essentially stores a binding of ID and associated locators.  The
context is maintained inside the host at shim layer and each context can
be uniquely identified by a pair of ID.</t>

<t>Preferred Locator - The mostly preferred locator among the list of available
locators for the entity.</t>

>        prefered locator of a host whose ID is 'A' can be denoted as

s/Interface/Link/

[snip]

    <list style="symbols">

Ok.

the current locator pair with the alternative locator pair.  Hot-standby

Ok.

Ok. I will add this.

[snip]

<t>When application to establish communication with its peer who
happens to have multiple locators, there are some issues to consider.
In connection oriented communication, connect() system call is used to
make the initial contact to the peer, which requires IP address and
port number to specify the endpoint.  Name-to-address resolution
should be performed prior to connect().  Application needs to resolve
IP address of the peer from its FQDN by any available name-to-address
conversion method.  In typical case, the application receives information
from resolver.  If the application ends up with receiving multiple
IP addresses to reach the peer, it should iterate each destination address
one-by-one.  It should also be noted that the host may also have multiple
source addresses.  Therefore, process of finding the working pair of
remote and local locators is complex.</t>

Ok.

[rest of the part snipped]

Regards,
Shinta

---

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 10 May 2006 00:24:21 +0900

Hello Jari,

Thank you for your feedback.  Please find my comments below.

On Mon, 08 May 2006 14:37:04 +0300
Jari Arkko <[email-masked]> wrote:

> abstraction level changes in between).

I think I understand what you mean.  Those interactions should
include something that could not be controlled by application but
by transport layer protocol itself.  For example, feedback (both
positive and negative, as mentioned in REAP draft) from transport
layer protocol to the shim layer should be directly passed from
transport layer to the IP layer.  When it comes to indications
from IP layer to upper layer protocol, occurrence of re-homing
event would be of interest for the ULP, especially TCP.  In the
past discussions on SHIM6 mailing list, some folks mentioned about
the possible behavior of TCP upon re-homing event (clear the status
of parameters and initiate slow-start etc.).  As you pointed out,
current API draft may be too much focusing on Socket API.  The
draft should also cover other forms of interactions between ULP
and shim layer, and I will take this into account.

> Do you see

I am not sure if I am answering your question, but let me address
what I have in mind so far... when it comes to effect that transport
layer protocol (I am actually referring to TCP) may have on shim layer.

One scenario would be that TCP layer may hold a specific requirements
given by the application for quality of e2e connection.  The quality
could be for instance RTT.  Let's assume that there is a Socket API
(setsockopt()) that allows application to specify satisfactory level
of RTT to given socket.  Such attribute could be stored by TCP in a
state information per socket.  As TCP maintains statistics on RTT by
itself, it may determine if the situation is satisfactory or not.
If not, TCP may urge shim layer to invoke path exploration or re-homing
(if/when alternate path is ready).  It may also be helpful to annotate
some information to the indication, giving the preference on
characteristics (quality) of the path.

Regards,
Shinta

---

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 10 May 2006 01:16:04 +0900

On Tue, 9 May 2006 16:44:48 +0300
marcelo bagnulo braun <[email-masked]> wrote:

> 
> El 09/05/2006, a las 10:11, Shinta Sugimoto escribis:
> 
> >> ...

Yes.  Would an assumption that a context can be uniquely identified by
ULID pair is not good ?  IMHO, we should better define how to uniquely
identify context.

> by ulid pair used, right?

Same discussion here, but I might be narrowing down definition of context
too much..  As I wrote above, IMHO it would be better to have a basic
rule to uniquely identify the context in a generic way (not specific to
SHIM6 or HIP).  Later we will define solutions, and I am sure that we will
be required to specify context in some case...
Do you think we don't need to specify how the context can be uniquely
identified in this doc ?

> why don't just remove the last part of the the last sentence? i.e.

ditto. (I am open to suggestion, so let me hear your opinion on my
question above)

> currently used to send packets.</t>

Ok, fine with me.

> account all these aspects

I see.  Rephrased as follows.

<t>Locator management - Locator management is a role of shim layer
to select a pair of locators for sending IP packet within given context.
The selection is made by taking miscellaneous conditions into account
such as application's preference and characteristics of path.</t>

> conceptually different from communication parameters like timers...

Ok.  I will separate the requirements.  One is below.  The other
is about ULP providing parameters (e.g. timer values) to shim layer
as you pointed out.

<t>Positive feedback could be done in a way that application or upper
layer protocol (e.g. TCP) may inform shim layer that its communication
is going well.</t>

> that was not what i had in mind, actually, see above

Now, I see.  So let me take the above item (as it is) in the
list of requirements.

> explore all available destination addresses)

Ok, thanks for providing the texts.

Regards,
Shinta

---

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 10 May 2006 09:56:38 +0300

Hi Marcelo,

I forgot to reply to some of your comments.  So please find my
additional comments.

[snip]

> good point.. i don't know really... perhaps include it as a discussion 

Ok, let's do that.

> for a particular app to define the preferences for the context...

Ah, yes.  We should treat this in a same way as previous item.
Maybe we should also consider/mention ULP's preference on locator
as well.  I mean, some ULP may have a particular request for shim
layer in locator selection.

Regards,
Shinta

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 10 May 2006 10:15:43 +0300

> Do you think we don't need to specify how the context can be uniquely

well, i think this is cumbersome, since we may have special handles as 
in the case of forked contexts... you could say that in general there 
would be one context per ulid pair, but that there may need for 
additional handles to support multiple contexts with the same ulid 
pair...

...

> such as application's preference and characteristics of path.</t>

i would add path reahability also...

...

ok

regards, marcelo

---

From: Miika Komu <[email-masked]>
Date: Fri, 12 May 2006 12:33:15 +0300 (EEST)

> API document as it's specific to SHIM6.

I would actually encourage to write about the forked context also to this 
document just see if it is useful with ED concept. When it is a separate 
and isolated section, it will be easy to move from one document to another 
if necessary.

Sorry for the delay. I'll send more comments today. I have read both shim6 
and btns drafts and I have some comments on them.

---

From: Miika Komu <[email-masked]>
Date: Fri, 12 May 2006 12:37:08 +0300 (EEST)

> and shim layer, and I will take this into account.

I think this draft should concentrate on the interactions between 
app<->shim and app<->transport. The common denominator should be really 
the application. shim<->transport interactions deserve a separate draft.

---

From: Jari Arkko <[email-masked]>
Date: Sun, 14 May 2006 18:22:03 +0300

Miika Komu wrote:

> app<->shim and app<->transport. The common denominator should be
> really the application. shim<->transport interactions deserve a
> separate draft.

That's fine.--Jari

---

From: Shinta Sugimoto <[email-masked]>
Date: Mon, 15 May 2006 15:19:59 +0300

On Sun, 14 May 2006 18:22:03 +0300

> > really the application. shim<->transport interactions deserve a

Ok, let's concentrate on (1) app <-> shim and (2) app <-> transport
in the API document.

Regards,
Shinta

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 19 May 2006 17:06:12 +0300

Hi,

I've updated the API draft reflecting comments that I
receieved from Marcelo, Miika, and Jari.  I hope I haven't
missed anything important, but if there is any please
let me know.

Attached please find the draft (.txt) as well as diff (.html)
from the previous version.  I hope we could move on defining
the solution (concrete socket API extensions) from now.

I appreciate your comments.

Regards,
Shinta

On Fri, 05 May 2006 15:18:40 +0900

---

From: marcelo bagnulo braun <[email-masked]>
Date: Mon, 22 May 2006 12:48:53 +0300

Hi Shinta,

i attach a commented version

most of the comments are editorial, but there are a few substantial 
comments

regards, marcelo

El 19/05/2006, a las 17:06, Shinta Sugimoto escribió:

> <draft-manyfolks-multihome-shim-api-00.txt><multihome-api- 
> diff.html>_______________________________________________

---

From: Miika Komu <[email-masked]>
Date: Mon, 22 May 2006 15:06:53 +0300 (EEST)

> most of the comments are editorial, but there are a few substantial 

Where, to be exact? I am mostly interested about the substantial changes.

Some ideas on section 7:

7.  Issues of Handling Multiple Locators with shim aware applications

As discussed earlier, I proposed to use sendmsg/recvmsg interface for 
receiving event information. However, it might be better to use NETLINK 
interface (RFC3549) for this. This way, it is easier to convert existing 
applications to become shim aware.

To "set" or "get" some non-event based information, the application can 
call getsockopt or setsockopt.

Any ideas, comments or objections? We need to figure out also the 
permissions - who is is allowed to do what.

---

From: Shinta Sugimoto <[email-masked]>
Date: Tue, 23 May 2006 11:22:30 +0300

Hi Marcelo,

Thank you for your comments.  I reflected most of your editorial
comments except some items that I need clarification.  Please find
my comments inline.

[snip]

> 1.  Introduction
> 
>    This document specifies socket API for multihomed shim layer.
> 
> MB: i would rephrase as
>    This document specifies a/the socket API for a multihoming shim layer.

done (with 'a').

> 
>    The
>    API aims to enable interactions between application and the multihome
> 
> MB: s/mulithome/multihoming

done.

>    shim layer for advanced locator management and interface to access
>    essential information about failure detection and path exploration.
> 
> MB: i would remove essential

'essential' removed.

[snip]

>    o  Endpoint Identifier (EID) - An identifier used by the application
>       to specify an endpoint of the communication.  As addressed in
>       [I-D.ietf-shim6-app-refer], application may handle EID in various
>       ways in different types of communication models such as long-lived
>       connection, callback, and referral.
> 
>       *  In case of SHIM6, the EID is called ULID.  ULID is chosen from
>          one of available locators on the host.
> 
>       *  In case of HIP, the EID is essentially a public key of the
>          host.  In order to preserve backward compatibility of legacy
>          application, hash of public key called Host Identity Tag (HIT)
>          is used by application as a handler of EID.
> 
> MB s/handler of/handle for the

done.

> 
> 
>    o  Locator - IP address actually used to deliver the IP packet.
> 
> MB: s/IP address/An IP address

done.

> 
>       Locator should be present in the source and destination field of
>       IP header of a packet that appears on wire.  Normally, locator is
> 
> MB: s/locator/a locator

done.

> 
>       assigned to the network interface of the host.  And the IP packet
>       destined to given locator is delivered to the network interface by
> 
> MB: s/to given locator/to a given locator

done.

> s/the network interface/to the correspondent network interface

done.

> 
>       the routing system.
> 
>    o  Shim - A conceptual layer inside the IP Layer which maintains
>       mappings of EID and locator.  An EID can be associated with more
> 
> MB: s/ mappings of EID and locator/ mappings between EIDs and locators

done.

> 
>       than one locators at a time when the host is multihomed.  From
>       network architecture perspective, shim should be even or lower
>       than the IPsec layer.  It should be noted that the term 'shim'
>       does not refer to specific protocol but refers to a generic
>       concept of a layer that enables separation of identifier and
>       locator.  SHIM6 and HIP are examples of the shim.
> 
>    o  Context - A state information to be shared by the peers, which
>       essentially stores a binding of EID and associated locators.  The
> 
> MB: s/binding of/ binding between the

done.

> 
> TBD                      Expires August 5, 2006                 [Page 5]
> 
> Internet-Draft             Multihomed Shim API             February 2006
> 
> 
>       context is maintained inside the host at the shim layer.
> 
> s/inside the host at the shim layer/ at the shim layer of the host

done.

> 
>    o  List of Locators - A list of available locators on the host.
> 
> MB: this sounds like the list of locators is only for the local host,
>  while the list of locators can also be for the remote host.
> I would say, the list of locators associated with a EID or something like this...
> 
>        The
>       list should be stored in a context, which tells all available
>       locators for the communication based on EID pair.
> 
> MB: the list of locators is asociated to a EID not to a EID pair or a context... 
> i mean there are TWO list of locators in a single context, one per EID of the context...

Correct.  rephrased as follows:

<t>List of Locators - A list of locators associated with an EID.
There are two lists of locators stored in a given context, one
is associated with local EID and the other is associated with
remote EID.  As defined in <>, list of locators associated with
an EID 'A' can be denoted as Ls(A).

>       As defined in
>       [I-D.ietf-shim6-proto], list of locators of a host whose EID is
>       'A' can be denoted as Ls(A).
> 
>    o  Preferred Locator - The (source/destination) locator currently
>       used to send packets.  As defined in [I-D.ietf-shim6-proto],
>       preferred locator of a host whose EID is 'A' can be denoted as
>       Lp(A).
> 
>    o  Reachability Detection - A procedure to detect reachability
>       between given locator pair.
> 
> MB: s/between given/between a given

done.

> 
> 
>    o  Path - A sequence of routers that an IP packet goes through to
>       reach the destination.
> 
>    o  Path Exploration - A procedure to explore available path for given
>       locator pairs.
> 
> MB: s/for given locator pairs/for a given set of locator pairs

done.

> 
> 
>    o  Outage - An incident meaning that the reachability among given
> 
> MB: s/among given/among a given

done.

>       locator pair is lost.  The outage could be caused by any kinds of
>       problems inside the routing infrastructure and problems of network
> 
> MB: s/of network/of the network

done.

> 
>       interface of the end hosts.
> 
>    o  Working Address Pair - An address pair is said to be working if
>       the packet containing the first address from the pair as source
>       address and the second address from the pair as destination
>       address can safely travel from the source to the destination, and
>       vice versa.
> 
> MB: remove and vice versa since the definition is an ordered address pair...

done.

> 
>   If the reachability is confirmed in both directions,
>       the address pairs is said to be bi-directional.  Otherwise, it's
>       unidirectional.
> 
>    o  REAP - A protocol for detecting failure and exploring reachability
>       in multihomed environment.  REAP is defined in[I-D.ietf-shim6-
>       failure-detection].
> 
>    o  Endpoint Descriptor (ED) - The representation of endpoints is
>       hidden from the applications.
> 
> MB: i am not sure what does this sentence means here
> 
>       ED is a "handle" or "pointer" to
>       the actual EID.  A given ED serves as a AID [I-D.nordmark-multi6-
>       noid].
> 
> MB: i haven't read the noid draft recently, but afair and AID was just as a ULID not a ED... (at least no more than a shim ULID)

I would leave definitions of ED to Miika.  Miika ?

from <draft-nordmark-multi6-noid-02.txt> Section 1.2:

>       Application identifier (AID)
>                   - an IP locator which has been selected for
>                     communication with a peer to be used by the upper
>                     layer protocol.  128 bits.  This is used for
>                     pseudo-header checksum computation and connection
>                     identification in the ULP.  Different sets of
>                     communication to a host (e.g., different
>                     connections) might use different AIDs in order to
>                     enable load spreading.

So, it sounds like notion of AID is similar to that of ULID in SHIM6
as Marcelo pointed out.

[snip]

>    These requirements are mainly identified during the discussions on
>    SHIM6 WG mailing list.  Some requirements are derived from
>    Reachability Protocol document[I-D.ietf-shim6-failure-detection].
> 
>    o  Locator management.  Locator management is role of shim layer to
> 
> MB: s/of shim/of the shim

done.

>       select a pair of locators for sending IP packets within given
> 
> MB: s/within given/within a given

done.

>       context.  The selection is made by taking miscellaneous conditions
>       into account such as reachability of path, application's
> 
> MB: s/of path/of the path

done.

>       preference, and characteristics of path.  From application's
> 
> MB: s/of path/of the path

done.

> 
>       perspective:
> 
>       *  It should be possible to obtain list of locators of the host
>          within a given context.  Ls(local) and Ls(remote).
> 
>       *  It should be possible to obtain preferred locator of the node
>          within a given context.  Lp(local) and Lp(remote).
> 
>    o  Notification from application to shim layer about the status of
> 
> MB: s/from application to shim/from the application to the shim

done.

> 
>       communication.  Note that the notification is made in event based
> 
> MB: s/of communication/of the communication
> s/in event/in an event

done.

> 
>       manner.  There are mainly two aspects of the feedback that
>       application or upper layer protocol may provide for shim layer,
>       positive and negative feedbacks [NOTE: These feedbacks are
>       addressed in sectoin 4.3 and section 5.2 of REAP specification]:
> 
>       *  Positive feedback could be given by application or upper layer
> 
> MB: s/by application/by the application

done.

> 
>          protocol (e.g.  TCP) to the shim layer informing that its
>          communication is going well.
> 
>       *  Negative feedback could be given by application or upper layer
> 
> MB: s/by application/by the application

done.

>          protocol (e.g.  TCP) to the shim layer informing that its
>          communication status is not satisfactory.  TCP could detect a
>          problem when it does not receives expected ACK from the peer.
>          ICMP error messages delivered to the upper layer protocol could
>          be a clue for application to detect any kind of problem.  REAP
>          module may be triggered by these negative feedbacks and invoke
>          procedure of path exploration.
> 
>    o  Feedback from application to shim layer.  The application should
>       be able to inform the shim layer about the timeout values for
>       detecting failure, for sending keepalives, for starting the
>       exploration procedure.  In particular, the application should be
>       able to suppress the keepalives.
> 
>       connection is needed.  In this case, alternative paths are known
> 
> 
> 
> Internet-Draft             Multihomed Shim API             February 2006
> 
> 
>       to be working.  Hence it is possible for the host to immediately
>       replace the current locator pair with the alternative locator
> MB: i think this sentence needs rewording...

Does this sound better ?

<t>Eagerness of locator exploration.  The application should be able
to inform the shim layer how proactive it wants REAP mechanism to perform
path exploration (e.g. specifying the number of concurrent attempts of
discovering working locator pair) when an outage occurs on the path between
the currently selected locator pair.</t>

[snip]

> 6.  Issues of Handling Multiple Locators with shim unaware applications
> 
>    multiple locators, there are some issues with legacy socket API.
> 
> 6.1.  Initial Contact
> 
>    When application is going to establish communication with its peer
>    who happens to have multiple locators, there are some issues to
>    consider.  In connection oriented communication, connect() system
>    call is used to make the initial contact to the peer, which requires
>    IP address and port number to specify the endpoint.  Hence, name-to-
>    address resolution should be performed prior to connect().
>    Application needs to resolve FQDN of the peer to an IP address by any
>    available name-to-address conversion method.
> 
>    In typical case, the application receives information from resolver.
>    If the application ends up with receiving multiple IP addresses to
>    reach the peer, it should iterate each destination address one-by-
>    one.  It should be noted that the host may also have multiple source
>    addresses.
> 
>    The different resulting address pair may have different reachability
>    status so, in order to find a working address pair, it may be
>    required to explore all the available address pairs (as opposed to
>    explore all available destination addresses).
> 
>    In normal case, application issues connect() by specifying resolved
>    IP address of the peer.  If the connect() fails, IP address is
>    iterated one by one sequentially until working pair is found.
>    Another approach is to initiate concurrent connect() with every
>    locator of the peer. connect() can also be called in a sequence which
>    would probably require more time to find the working pair.
> 
>    There could be another case where involvement of shim layer is
>    expected for handling initial contact.
> 
> MB: which is the previous case where the shim was involved in?
> i mean the next is "another case" is there a previous case?
> maybe s/there/this ?

yes, the sentence is misleading.  I rephrased as "Besides, there
is a case where involvement of the shim layer is expected... "

> 
> 
>    In such case, behavior of
>    shim layer will depend on presence of required context.  If there
>    exists the context for the EID specified in the connect(), the
>    initial contact can be made in accordance with the context
>    information.  Otherwise, shim layer should invoke context
>    establishment with the peer EID specified in the argument for
>    connect().
> 
>    Additional efforts would be required in a case where the peer cannot
>    be reachable by the EID (for example, EID is non-routable or non-IP
>    reachable) but can be reached by alternative locator.  In particular,
>    shim layer should somehow discover the alternate locator for the EID
>    to establish context.  [I-D.nordmark-shim6-esd] addresses the
> 
> 
> 
> TBD                      Expires August 5, 2006                [Page 10]
> 
> Internet-Draft             Multihomed Shim API             February 2006
> 
> 
>    possible approach to perform reverse DNS lookup from EID to FQDN,
>    then perform forward lookup again to find the full-set of locators
>    and EID.
> 
>    In HIP, resolving HITs to IP addresses using DNS is not feasible
>    because HITs do not contain any hierarchical information.  To
>    mitigate this problem, there are a few alternatives.  Firstly,
>    resolver library on end-host can be modified to provide HIT-to-IP
>    mappings for HIP software module.  Secondly, a distributed hash table
>    (DHT) service can be used for storing and looking up the mappings
>    because it supports non-hierarchical identifiers, such as HITs
>    [I-D.ietf-hip-arch].  Thirdly, it is possible to use IP addresses in
>    legacy applications as described in [I-D.henderson-hip-applications].
> 

[snip]

> 8.  Further Issues
> 
>    Followings are issues that need further considerations.
> 
> 8.1.  Additional Requirements from Applications
> 
>    Followings are additional requirements.  At the moment, it is not
>    certain if these features are commonly needed in all the targeted
>    multihomed environments (SHIM6 and HIP).  These requirements are
>    mainly identified during discussions made on SHIM6 WG mailing list.
> 
>    o  The application should be able to select a locator pair.
> 
>    o  The application should be able to set preferences for the
>       locators, local and remote one and also to the preferences of the
>       local locators that will be passed to the peer.
> 
> MB: i think here it should be included the description of the discussion
> about whether an app can select soemthing for a context that will affect
> all the other apps that are using this

Noted.  A context can be by definition, shared by apps, so if we let
app to specify 

> Actually i think this is a relevant discussion in general (for instance for
> negative and positive feedback, timers and so on) because the settings/information
> passed by a single application would affect all other apps using the context.
> I think that we need a section disucssing how to manage the case where there
> are multiple apps that are source of information to the shim and how we can
> deal with contradictory information in particular 
> 

I agree.  Race condition should be avoided.
I think this issue is common to BTNS in case of connection latching.
Specific SA parameters should be chosen for a given application.

And we may also learn from past experience (existing systems).
In some of major Operating Systems, it is possible for application to
configure per-socket IPsec policy by setsockopt().  By doing so, policy
enforcement could be done in per-socket manner.  Well, per-socket does
not necessariliy mean per-application, but...  In those cases (systems
that allows app to specify per-socket IPsec policy), IPsec policy
could be either system-wide or per-socket.  Per-socket policy must not
be applied to flow of application that has no association with the
policy entry.  Question is which policy to apply for when both system-wide
policy and per-socket policy match.  Probably per-socket policy
should override the system-wide policy in any case of race condition.

I will add new section for this issue.  Thank you for pointing this out.

>       layer not to apply Identifier/Locator adaptation but to apply
>       normal IP processing at the IP layer.
> 
> MB: this is already mentioned in the above requirements and i think this is required (i.e. it is not for discussion)

Yes.

>       context setup or it wants context establishment to be started
>       immediately if there is no available context.  In such way,
>       application can 'upgrade' the connection providing in a sense that
>       identifier and locator are managed separately.
> 
> 
> MB: I think this should be supported

Ok.

[snip]

Regards,
Shinta

---

From: Miika Komu <[email-masked]>
Date: Tue, 23 May 2006 20:19:49 +0300 (EEST)

On Tue, 23 May 2006, Shinta Sugimoto wrote:

>> MB: i haven't read the noid draft recently, but afair and AID was just 
>> as a ULID not a ED... (at least no more than a shim ULID)
>

I think I originally misinterpreted AID to be any application identifer. 
Please remove the latter sentence.

> So, it sounds like notion of AID is similar to that of ULID in SHIM6

The AID term is a little bit confusing from the viewpoint of EDs, because 
they are also "application identifiers" even though the pseudo-header 
checksum is not based on the ED.

Anyway, maybe we should have the AID term redundantly in the draft 
terminology.

---

From: Shinta Sugimoto <[email-masked]>
Date: Wed, 24 May 2006 10:49:03 +0300

Hi,

Attached please find the latest version of the API draft.
Updates were made based on the comments from Marcelo and Miika.

Regards,
Shinta

On Tue, 23 May 2006 11:22:30 +0300