Re: [CARD Technical Issue] U flag and Unsolicited CARD

Well,I guess it is not much different when you think about it...:)

Cheers,
Jukka

On Fri, 4 Jul 2003, James Kempf wrote:

> Jukka,
> 
> How is this any different than the default value for router discovery in RFC
> 2461? There are so many different kinds of wired links too: ATM, Ethernet,
> token ring, PPP, etc.
> 
>             jak
> 
> ----- Original Message ----- 
> From: "Jukka MJ Manner" <[email protected]>
> To: "Seamoby Working Group" <[email protected]>
> Sent: Thursday, July 03, 2003 11:58 PM
> Subject: Re: [Seamoby] [CARD Technical Issue] U flag and Unsolicited CARD
> 
> 
> >
> > Hi,
> >
> > I can't help but argue about the default value. There are so many
> > scenarios and network types that could make use of CARD that it would be
> > impossible to give a default value. In the worst case, with a WLAN
> > network, a user might only spend a few seconds within the cover area of
> > one AP, while in the IETF, most people are sitting down while the
> > connectivity is on, which implies a lingering time of minutes or even
> > hours...
> >
> > I would go for a section that discusses shortly the transmission interval,
> > and could give some example values in different scenarios, but no
> > single standardized default.
> >
> > My 2 cents,
> > Jukka
> >
> > On Thu, 3 Jul 2003, James Kempf wrote:
> >
> > > > > A default rate must be specified. The IESG will insist on this. See
> RFC
> > > > 2608
> > > > > for an example.
> > > > >
> > > > [eunsoo] If the IESG insist on setting the default value, we can set
> the
> > > > default maximum transmission rate of the unsolicited replies. Since
> > > > unsolicited replies would not involve time-sensitive operation, it
> should
> > > be
> > > > fine. A simple guess is "maximum once per second" like the router
> > > > advertisement. What do you think?
> > > >
> > >
> > > Here are what some other protocols do.
> > >
> > > 1) RFC 2461 suggests MAX_INITIAL_RTR_ADVERT_INTERVAL as an initial value
> and
> > > MIN_DELAY_BETWEEN_RAS multicast to the All Nodes Multicast Address.
> > > MIN_DELAY_BETWEEN_RAS is 3 seconds, MAX_INITIAL_RTR_ADVERT_INTERVAL is
> 16
> > > seconds.
> > >
> > > 2) RFC 2608 (SLP, whose purpose is similar to CARD in some ways)
> suggests 12
> > > hours for unsolicited DA advertisements. This is clearly too long for
> CARD,
> > > since nodes can hand over at any time.
> > >
> > > 3) OSPF has a default route flooding period of about 20 min. This also
> seems
> > > a bit long.
> > >
> > > 4) As a general observation, protocols that do excessive advertisement
> tend
> > > to increase the base network load, reducing bandwidth for traffic,
> something
> > > to be especially avoided on wireless networks. Novell's SAP for example
> was
> > > infamous for this, and I am told that Apple Rendezvous can also if not
> > > properly configured.
> > >
> > > The question one must ask is if the MNs can solicit, what is the purpose
> of
> > > the unsolicited message?  As an alternative, to reduce traffic from per
> MN
> > > solicitations? If so, then having the message multicast more frequently
> than
> > > the approximate lingering time of the MNs on the link won't end up
> saving
> > > anything.
> > >
> > > With this in mind, I'd suggest a default mean of 5 min, configurable to
> half
> > > the approximate mean lingering time of mobile nodes on the link. The
> router
> > > then randomly generates a time between 1 sec. and the mean for the
> actual
> > > time (to avoid synchronization). An interesting experiment would be to
> look
> > > at some data on 802.11 networks, like for example, the IETF network, and
> > > find out long nodes do linger. YMMV of course, but it would give some
> more
> > > realistic bounds.
> > >
> > > Here are some other considerations:
> > >
> > > 1) If any of the CARD information changes, the router should multicast
> > > immediately. The router should start by randomizing the initial message
> > > between, say, 1 and 3 seconds in order to avoid clashes with other
> routers
> > > on the link. And it should continue sending for, say 20 seconds,
> randomizing
> > > the intermessage time, in case any of the messages are dropped. The
> draft
> > > should recommend keeping dynamic attribute changes to a minimum, as this
> > > would cause excessive advertisement. Perhaps a minimum change interval
> of 5
> > > min.
> > >
> > > 2) Pg. 46 of RFC 2461 has this to say about sending of unsolicted RAs:
> > >
> > >    Unsolicited Router Advertisements are not strictly periodic: the
> > >    interval between subsequent transmissions is randomized to reduce the
> > >    probability of synchronization with the advertisements from other
> > >    routers on the same link [SYNC].
> > >
> > > The WG may want to consider requiring this of unsolicited CARD messages
> as
> > > well.
> > >
> > > 3) Another way to avoid the clashing adverts problem is to have only one
> > > router on the link do the advertisement. The WG may also want to
> consider
> > > recommending that the protocol accommodate configuration such that one
> > > router can be configured as the sole CARD multicast source. Or was the
> > > protocol intended to accommodate different CARD information on routers
> > > sharing the same link? It might be possible (but clearly undesirable
> from a
> > > complexity standpoint) to have one set of access points in one
> geographical
> > > area configured with one router and another with another but both
> routers on
> > > the same subnet, and the possible CARs be different, since the possible
> > > topological moves from the different geographical areas could be
> different.
> > > The MIP group is grappling with this issue for movement detection, no
> > > solution yet.
> > >
> > > > > > The same port number as the solicited CARD reply is used for the
> > > > > unsolicted
> > > > > > CARD reply.
> > > > > >
> > > > >
> > > > > OK.
> > > > >
> > > > > > What do you think would be the proper TTL for the unsolicited CARD
> > > > reply?
> > > > > I
> > > > > > thought TTL 1 should be fine between MN-AR.
> > > > > >
> > > > >
> > > > > If you make it 255, then the reply must have come from a node on the
> > > same
> > > > > link. This is a cheap way to prevent an offlink attacker from
> sending
> > > > bogus
> > > > > CARD replies. RFC 2461 uses this technique. The node should reject
> the
> > > > > message if the TTL is not 255.
> > > > >
> > > > [eunsoo] Thanks for the info. 255 must be the right value for MN-AR.
> How
> > > > about AR-AR?
> > > >
> > >
> > > The check won't work in that case because there could be multiple hops
> > > between the two. The two ARs should be using ESP to authenticate anyway.
> > >
> > >             jak
> > >
> > >
> > >
> > > _______________________________________________
> > > Seamoby mailing list
> > > [email protected]
> > > https://www1.ietf.org/mailman/listinfo/seamoby
> > >
> >
> >
> > _______________________________________________
> > Seamoby mailing list
> > [email protected]
> > https://www1.ietf.org/mailman/listinfo/seamoby
> >
> 
>