[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] A Merging Proposal
Hi Greg,
on 2006-07-18 21:42 Greg Daley said the following:
> Hi Behcet,
>
> We don't necessarily need to keep the flags available, as
> future extensions could define a flags field in an option.
>
> We will coordinate with the IPv6 WG, the ADs and IANA,
> to make sure that problems don't occur, and the best
> outcome is achieved.
You might want to consider using the last flag as an extension
indicator, indicating that more flags are available in an
option. That would give a fast-out path for the cases where
no flags defined in the possible future flag option are used
(i.e. the flag option and extension flag is absent).
I think this might be better than using the last flag slot
for a regular flag.
Henrik
> Greg
>
> ----- Original Message -----
> From: Behcet Sarikaya <behcetsarikaya@yahoo.com>
> Date: Tuesday, July 18, 2006 1:01 pm
> Subject: Re: [DNA] A Merging Proposal
> To: JinHyeock Choi <jinchoe@gmail.com>, dna@eng.monash.edu.au
>
>> Hi JinHyeock,
>> Please keep the very last two reserved bits left in the RA
>> messages and introduce options instead. I mentioned this to Suresh
>> in Montreal.
>>
>> Regards,
>>
>> --behcet
>> ----- Original Message ----
>> From: JinHyeock Choi <jinchoe@gmail.com>
>> To: dna@eng.monash.edu.au; JinHyeock Choi <jinchoe@samsung.com>
>> Sent: Tuesday, July 18, 2006 7:21:15 AM
>> Subject: [DNA] A Merging Proposal
>>
>> Dear All
>>
>> As Greg told in the meeting, we started working on a merge. We aim to
>> combine multiple drafts into an integrated solution without
>> inconsistency or redundancy. I had a discussion with the authors and
>> am glad to say that we seem to be in an agreement (at least, there was
>> no objection. :-)). I propose to combine the existing schemes as
>> below. Kindly see that the merging proposal is ok. Your feedback would
>> be appreciated.
>>
>> Thanks for your kind consideration.
>>
>> Best Regards
>>
>> JinHyeock
>>
>> --------------------------------------------------------------------
>> -----------------------------
>> Right now, DNAv6 doesn't manage the Complete Prefix List (CPL).
>> While it manages the Prefix List with DNAHostPrefixList, it doesn't
>> concern whether the Prefix List is complete or not.
>>
>> We can combine CPL & DNAv6 to make a host always manage
>> not only the Prefix List but also its COMPLETENESS. So roughly
>> DNA host checks for link change as below.
>>
>> First, a host manages the CPL for an each link.
>>
>> Second, when the host moves to a new link,
>>
>> Case 1. When the host WITH the CPL
>> - The host compares the CPL with the Prefix List in an incoming RA
>> and assumes a link change if and only if
>> there is no common prefix between two.
>> (Take notice that it doesn't matter whether the host moves to
>> a DNA link or a non-DNA link.)
>>
>> Case 2. When the host WITHOUT a CPL moves to a DNA link,
>> - The host should send an RS with a Landmark prefix.
>> - Upon receiving the RS,
>> - If a DNA router can send a CompleteRA,
>> it sends the CompleteRA
>> to provide the (possibly new) CPL.
>> Upon receiving the RA, the host can check for link change
>> by comparing its Prefix List with the CPL in the RA.
>> (Even when a DNA router can send a CPL,
>> it may simply reply with the Landmark prefix
>> in case of no link change to save bandwidth.)
>> - If the router can't sends a CompleteRA
>> (because of too many prefixes),
>> it replies with the Landmark Option with YES/ NO indication.
>> The host check for link change with the Landmark Option.
>>
>> Case 3. When the host WITHOUT a CPL moves to a non-DNA link,
>> - If the host happens to move to a non-DNA link without a CPL,
>> it checks for link change as of CPL
>> by performing (multiple) RS/ RA exchanges to generate the (new) CPL
>>
>> Also LinkID prefix makes that any two RAs in a link have
>> at least one common prefix to assure graceful prefix addition or
>> removal.There would be no false decision, even when there is a
>> temporaryasynchronization among DNARouterPrefixList.
>>
>> In this way, I think we can integrate CPL and DNAv6 in an efficient
>> way.
>> I elaborated the above further as below.
>>
>> 1. DNA Host Operation
>>
>> 1.1 CPL management.
>> 1) A host generates the Prefix List of a currently attached link.
>>
>> 2) The host declares the existing Prefix List is complete when
>> - it receives a CompleteRA
>> (as of DNAv6 in a DNA link where a router can send a CompleteRA.)
>> or
>> - it performs RS/ RA exchange num_RS_RA times
>> (as of CPL either in a non-DNA link or in a DNA link where a router
>> can't send the CompleteRA)
>> - The Prefix List needs a complete flag to indicate its completeness.
>> Currently, in CPL, Candidate Link Object uses the number of
>> RS/ RA exchanges to indicate its completeness.
>>
>> 1.2 Link Identification.
>> 1) Assume a host receives a hint of a possible link change.
>>
>> 2) Then the host sends an RS with a Landmark Option.
>> * If the host has the CPL, I think it can omit the Landmark
>> without degrading performance.
>>
>> 3) Upon receiving an RA with at least one prefix,
>> the host checks for link change as below.
>>
>> IF the host has the CPL (Complete Prefix List)
>> the host assumes a link change
>> if and only if
>> its Prefix List and the Prefix List from the incoming RA
>> have no common prefix.
>>
>> ELSE {
>> IF it receives the CompleteRA,
>> the host assumes a link change
>> if and only if
>> its Prefix List and the Prefix List from the
>> incoming RA
>> have no common prefix.
>>
>> ELSE {
>> IF it receives the RA with the Landmark Option
>> which it sent
>> the host assumes a link change
>> if and only if
>> the Landmark Option indicates a link
>> change with NO
>>
>> ELSE
>> the host checks for link change as of
>> CPL. (i.e. it performs RS/ RA exchange
>> num_RS_RA times
>> to generates a (new) Prefix List and
>> compare it with the existing one.)
>> }
>> }
>>
>> * I guess we can make Sec 5.2.5 of DNAv6 more clear with the above.
>>
>> 2. DNA Router Operation
>>
>> 2.1 CPL Management
>> 1) A router generates the CPL (Complete Prefix List) by performing
>> multiple RS/ RA exchanges as of DNAv6.
>>
>> 2) The router includes the LinkID Prefix as of DNAv6
>> to assure that two RAs always have a common prefix.
>> * With this, we can add or remove a prefix without resulting in
>> false link identification.
>>
>> 2.2 Link Identification.
>> 1) Upon receiving an RS, the router sends back the CompleteRA,
>> if possible.
>>
>> 2) If not possible, the router indicate a link identity
>> with Landmark Option with YES/ NO bit.
>> * I think we may do away with YES bit because we simply put
>> the Landmark prefix in PIO to indicate YES.
>>
>> 3) Or we may make a modification to save bandwidth as below.
>>
>> The router first checks the Landmark Option in an RS and
>>
>> IF the Landmark is in the same link,
>> the router simply sends back the Landmark Option with YES.
>>
>> ELSE {
>> IF possible, the router sends the CompleteRA.
>> * because the host needs the CPL anyway.
>> ELSE the router sends back the Landmark Option with NO.
>> }
>>
>>
>>
>>
>>
>