[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

CELP (was RE:)

Hi Dave,

I am trying to understand this CELP idea, so i have some comments.

First, about the Locator Pool concept.

The Common Endpoint Locator Pool contains the locators of both endpoints
involved in a communication.
When a host A is communicating with a host B, the CELP of host A contains
both locators from A and locators from B.

Additionally, i  guess that the CELP has to contain reachability information
about each locator (or perhaps about each locator pair, since a destination
may be reachable or not depending on the source address used.)

Furthermore, some proposals also include information about whether the
locator has been verified or not.

So the CELP, in a host A,  for a communication between A and B, has (at
least) the following information:

Locator Set of A={LA1,LA2,...,LAn}
Locator Set of B={LB1,LB2,...,LBm}

Verified Locator Set of B={LVB1,LVB2,...,LVBk}

Reachables pairs={(LAi,LVBj) for a certain group of i and j}

Do you think that this would be what a LP should contain?

Now the idea would be that the CELP is maintained through different means,
such as enhanced transport protocols and wedge layer so that if one of them
introduces new information in the CELP, this information is available for
all the others. In this way, overhead can be reduced since the information
is obtained only once and not for every particular mechanism.

Now, let's analyze a bit more which information can be provided per each
mechanism:

Locator Set information: This would be the (unverified) locator set of B

There are three types of mechanism that can provide such information:
- The enhanced transport layers
- The wedge layer
- The DNS

So the Locator Set of the CELP is feed by these 3 mechanisms, ok.

Now, the next relevant information is about address validation. Here is
where it starts to get fuzzy for me.
Every mechanism can have very different ways to validate a locator.
Especially verifications made by transport layers can be weaker because only
a connection is at stake, while wedge layer tend to do stronger validations,
and even between the different proposals for wedge layer, the strength of
the validation varies. Finally, the addresses provided by the DNS have also
a different level of validation (which also varies if DNSsec is used)

So, i am not so sure that a validated address means the same for the
different mechanism, so i see a difficulty in including addresses through
different means to be used by all of them.

Clearly, the weaker mechanisms can benefit from addresses validated through
stronger mechanisms but i doubt that the reverse would be possible. In any
way, the first option is possible and it would help to reduce the overhead.

Finally, the other relevant information is the reachability information.
Reachability means that if you send a packet to a certain destination from a
certain source address, a reply is received before a defined timeout.
So reachability is related to a destination a source and a timeout.

The problem that has already been discussed in the list is that the timeout
varies depending on the application.

So, a certain source/destination address may be unreachable for some apps
but not for others.

So we need to include something more specific than an unreachability flag
for a source and destination pair.

An option could be that the different mechanisms include the timeout value
that expired when they decided that a certain source and destination address
is unreachable for them.

So a SCTP connection is using a certain source and destination address pair
and it timeouts after x seconds. It then informs the CELP that this
source/dest address pair takes longer than x secs to respond.
The next mechanism can see whether this is acceptable and wants to try its
luck using it or it is not acceptable. But this is starting to become quite
complex, i think. Another option is just to order the potential
source/destination address pairs according to the last timeout, so that the
one with lower timeout is used first. In any case, i still don't see this
very clear.


Finally another question is how do identify a CELP is identified. I mean
some wedge layer create new id name space, so you can just use the ID pair
to identify the CELP, others don't introduce a new id name space, so regular
ip addresses are used.

Now the new id name space and the IP address space may collide, so a
mechanism to uniquely identify a CELP is required.

Regards, marcelo



> -----Mensaje original-----
> De: owner-multi6@ops.ietf.org [mailto:owner-multi6@ops.ietf.org]En
> nombre de Dave Crocker
> Enviado el: jueves, 12 de febrero de 2004 1:06
> Para: Multi6 List
> Asunto:
>
>
> The draft and Avri and I wrote on the SLAP idea is now available:
>
>
> >         Title           : Framework for Common Endpoint Locator Pools
> >         Author(s)       : D. Crocker
> >         Filename        : draft-crocker-celp-00.txt
> >         Pages           : 10
> >         Date            : 2004-2-11
> >
> > Classic Internet transport protocols use a single source IP Address
> >    and a single destination IP Address, as part of the identification
> >    for an individual transport data flow. This is problematic for
> >    multihomed hosts and for mobile hosts, collectively needing
> >    'multiaddressing' support. The basic goal, then, is to find a method
> >    for multiaddressing that makes the smallest possible change to the
> >    architecture and to current systems, while maintaining flexibility
> >    for different emerging solutions.  This draft proposes a framework
> >    for methods for creating Common Endpoint Locator Pools that can be
> >    used by and among the proposed solutions.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-crocker-celp-00.txt
>
>
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
>
>