Brett -
I like the change.
thanks,
Sathya
----- Original Message -----
From: Brett Pentland <brett.pentland eng.monash.edu.au>
Date: Friday, March 17, 2006 11:36 pm
Subject: Re: [DNA] Updates to dna-protocol3
> Hi Sathya,
>
> Sathya Narayanan wrote:
> > Brett -
> >
> > Sorry for the delay in responding. I was occupied.
See my
> responses inline.
>
> No worries. I can certainly relate to that. 
>
> > <snip>
> >
> >> The former is what's in
draft-pentland-dna-protocol3-00.txt I
> don't>> remember actually having any debate on
that point.
> The way it's
> >> written was an attempt to make the
specification simple to follow
> >> while integrating the three identification
methods: base the
> solution>> around completeRA but allow the RA
size to be reduced
> in certain
> >> circumstances.
> >
> > OK. I felt this was confusing because it MAY sound
like there are
> > contradictory recommendations. IMHO, the order in
which we
> introduce the
> > flow should correspond to implementation logic,
something like, if
> > landmark present, should do landmark-response,
else if XXX, do
> YYY else
> > do completeRA. Does that make sense? If not, I am
ok with your
> proposed> change below.
>
> Yes, that makes sense. Would the following
rearrangement of 5.1.5 fit
> the bill?
>
> From:
>
> 5.1.5 Processing Router Solicitations
>
> All Router Advertisements sent by a DNA router MUST
have the
> "F" flag
> set so that hosts processing them know that they can
count on the
> content being interpretable according to this
specification.
>
> The usual response to an RS SHOULD be a unicast RA.
However,
> to keep
> control of the rate of unicast RAs sent, a token
bucket is
> used. The
> token bucket is filled at one token every
UnicastRAInterval. A
> maximum of MaxUnicastRABurst tokens are stored.
>
> In order to respond to a Router Solicitation, the
router SHOULD
> generate a Complete RA as specified in Section
5.1.6. The Router
> Advertisement MUST include the LinkID, as described
in Section
> 5.1.7.
> If a unicast send token is available AND the source
address of the
> Router Solicitation is NOT the unspecified address
(:,
then
> a token
> is removed and the Router Advertisement is scheduled
for
> transmission as specified in Section 5.1.8.
>
> If no unicast send token is available OR the source
address of the
> Router Solicitation is the unspecified address, then
if there
> is no
> multicast RA scheduled for transmission in the next
> MulticastRADelay the RA MUST be sent to the
link-scoped all-
> nodes multicast address at
> the current time plus MulticastRADelay.
>
> If no unicast send token is available OR the source
address of the
> Router Solicitation is the unspecified address but
there is a
> multicast RA scheduled for transmission in the next
> MulticastRADelay, then the Router Solicitation MUST
be dropped.
>
> 5.1.5.1 Space Optimized Advertisements
>
> If the Router Solicitation contains a Landmark
Option whose
> prefix is
> included in DNARouterPrefixList or AdvPrefixList AND
the
> corresponding Router Advertisement will be unicast,
the router MAY
> send an abbreviated Router Advertisement.
>
> The abbreviated advertisement includes only the
Landmark
> Option, with
> the "Y" flag set, plus the base RA
header and any SEND options as
> appropriate. The Complete flag MUST NOT be set.
This is the one
> exception where the LinkID MAY be omitted as the Y
flag
> implies that
> link change has not occurred.
>
> Some prefixes may also be omitted from unsolicited
Router
> Advertisements, as described in Section 5.1.9.
>
> To:
>
> 5.1.5 Processing Router Solicitations
>
> The usual response to a Router Solicitation SHOULD
be a
> unicast RA.
> However, to keep control of the rate of unicast RAs
sent, a token
> bucket is used. The token bucket is filled at one
token every
> UnicastRAInterval. A maximum of MaxUnicastRABurst
tokens are
> stored.
> When a Router Solicitation is received, the router
checks if
> it is
> possible to send a unicast response. A unicast
response requires
> that the following conditions to be met:
>
> o A unicast send token is available.
>
> o The source address of the Router Solicitation is
NOT the
> unspecified address (:.
>
> If a unicast response is possible and the Router
Solicitation
> contains a Landmark Option whose prefix is included
in
> DNARouterPrefixList or AdvPrefixList, the router
SHOULD send an
> abbreviated Router Advertisement.
>
> This abbreviated advertisement includes only the
Landmark Option,
> with the "Y" flag set, plus the base RA
header and any SEND
> options as appropriate. The FastRA flag MUST be
set. The
> Complete flag MUST
> NOT be set. This is the one exception where the
LinkID MAY be
> omitted as the Y flag implies that link change has
not
> occurred and
> that the previously received LinkID is still
current.
>
> If there is no Landmark Option in the received
Router
> Solicitation or
> it contains a Landmark Option whose prefix is not
included in
> DNARouterPrefixList or AdvPrefixList or a unicast
response is not
> possible, then the router SHOULD generate a Complete
RA as
> specified in Section 5.1.6. The Router
Advertisement MUST
> include the LinkID,
> as described in Section 5.1.7.
>
> If a unicast response is possible, then a token is
removed and the
> Router Advertisement is scheduled for transmission
as
> specified in
> Section 5.1.8.
>
> If a unicast response is not possible and there is
no
> multicast RA
> already scheduled for transmission in the next
MulticastRADelay
> the RA MUST be sent to the link-scoped all-nodes
multicast
> address at
> the current time plus MulticastRADelay.
>
> If a unicast response is not possible but there is a
multicast RA
> already scheduled for transmission in the next
> MulticastRADelay, then
> the Router Solicitation MUST be dropped.
>
> Does that make it more readable? What do others think?
>
> Cheers,
> Brett.
>
|