TWiki > DNA > DNASolution1 > DNASoln1Issue010	TWiki webs: Main | TWiki | Know | Sandbox
	DNA . { History of Changes | DNA Documents | Search | Go }

Host response to inconsistant info

What does the host do if it receives multiple RAs that have conflicting
information? 

Discussion

Jim

What do you mean by conflicting information?

            jak

Erik

Brett Pentland wrote:

> What does the host do if it receives multiple RAs that have conflicting
> information?


Here is my cut at a way to handle flash renumbering and reassignment without being confused for more than 1.5 hours.

The basic conceptual data structure is the Candidate Link object described in the CPL draft, but some additional care must be taken when multiple CPL objects are merged due to one or more common prefixes (because that common prefix might be the one that was reassigned to a different link).

The CLO idea is based on collecting the information from all the received RAs where the host knows it didn't move in the interim. (I think how it determines this is largely orthogonal, but let's assume there is a reliable 'link up' event from L2 right now.)

Here is one of the cases we need to handle (with an outline of how to handle it).

1. 'link up' event. Start collecting information in a new CLO
2. Multiple RAs received, with the information going into that CLO (and also used to configure the host). The prefixes are P1 and P2. Assume preferred lifetimes of 7 days and valid lifetimes of 30 days.
3. Host is disconnected from the link (and there might not be a timely 'link down' event)
4. P1 is flash removed from the link; the router advertises it with valid lifetime=0 for some time (ideally 30 days, but DNA doesn't depend on that)
5. P1 is added to another link, which previously had prefix P3.
6. Host moves to this new link.
7. Host DNA receives 'link up' event from L2.
   Since it doesn't know whether the old CLO is still valid it
    - starts a 1.5 hour timer on the old CLO (oCLO)
    - will collect new information into a new CLO (nCLO)
8. Host receives a RA with P1, P3 (preferred=7 days, valid=30 days)
   The logic we have discussed so far says it can conclude it is still
   on the same link, since there is one common prefix P1.
   In CPL terminology, it would form a CLO by merging the oCLO and nCLO,
   ending up with P1, P2, P3 as the prefixes.

   That still seems like a reasonable thing to do, but the added logic
   is to continue to keep track of the 1.5 timer for the information
   that was in the oCLO.
   Thus it would say CLO = union(oCLO, nCLO), but still run a timer on
   oCLO.

9. Host is confused for 1.5 hours
10. 1.5 hour timer fires.
    Discards the oCLO set of information, and recomputes
    CLO = nCLO (which is the information which has been received
    after #7)
    This means that P2 is no longer part of the host's prefixes, but it
    also discards e.g. some MTU information that was in the oCLO.


  Erik

Brett

During a prefix change, a host might solicit, and request a prefix
that has been withdrawn on one router, but that change hasn't
yet propagated to another router on the link.  The host the gets
a no, followed by a yes, or vice versa.  The host has to act on the
first one, but what should it do with the second, conflicting
response?

Brett.

James Kempf wrote:

> What do you mean by conflicting information?
>
>             jak
>
> ----- Original Message ----- From: "Brett Pentland" <brett.pentland@eng.monash.edu.au>
> To: <dna-dt@eng.monash.edu.au>
> Sent: Monday, April 18, 2005 12:47 AM
> Subject: [DNA-DT] Solution1, Issue 10: Host response to inconsistant info
>
>
>
>> What does the host do if it receives multiple RAs that have conflicting
>> information?

Tero

>3. Host is disconnected from the link (and there might not be a timely
>> 'link down' event)
>> 4. P1 is flash removed from the link; the router advertises it with
>> valid lifetime=0 for some time (ideally 30 days, but DNA doesn't

depend

>> on that)
>> 5. P1 is added to another link, which previously had prefix P3.
>> 6. Host moves to this new link.
>> 7. Host DNA receives 'link up' event from L2.


While reading the discussion it just popped into my mind that if a node
moves from a wireless LAN access point to another the node does not
necessarily get   a 'link down' event just a new 'link up' event, i.e. a
possible indication of movement is a sequence of 'link up' events. I
can't confirm if this is valid for all Wireless LAN cards but it at
least happens with Orinoco WLAN cards. This is mostly likely irrelevant
information that has no effect on the design but I just wanted to write
it down.

Tero

Jim

Well, that seems to me another indication we are going to have to bite the
bullet and do some kind of router convergence algorithm. A failure in that
case would indicate a misconfigured router, which we could handle by saying
that it's time to call someone.

            jak

----- Original Message ----- 
From: "Brett Pentland" <brett.pentland@eng.monash.edu.au>
To: "James Kempf" <kempf@docomolabs-usa.com>
Cc: <dna-dt@eng.monash.edu.au>
Sent: Tuesday, April 19, 2005 1:13 AM
Subject: Re: [DNA-DT] Solution1, Issue 10: Host response to inconsistant
info



>> During a prefix change, a host might solicit, and request a prefix
>> that has been withdrawn on one router, but that change hasn't
>> yet propagated to another router on the link.  The host the gets
>> a no, followed by a yes, or vice versa.  The host has to act on the
>> first one, but what should it do with the second, conflicting
>> response?
>>
>> Brett.
>>
>> James Kempf wrote:
>
>>> > What do you mean by conflicting information?
>>> >
>>> >             jak
>>> >
>>> > ----- Original Message ----- 
>>> > From: "Brett Pentland" <brett.pentland@eng.monash.edu.au>
>>> > To: <dna-dt@eng.monash.edu.au>
>>> > Sent: Monday, April 18, 2005 12:47 AM
>>> > Subject: [DNA-DT] Solution1, Issue 10: Host response to inconsistant

info

>>> >
>>> >
>>> >
>>
>>>> >>What does the host do if it receives multiple RAs that have conflicting
>>>> >>information?

-- Main.BrettPentland - 18 Apr 2005

Back to DNA Issue Tracker Base Page