[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [DNA] Updates to dna-protocol3
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.
>