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

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
>