> It seems that we have a reasonable consensus in this thread > to do exactly that in RPL anyway... > > Pascal
OK, So could someone with the full overview outline explain to me how many mechanisms a RPL node running over 6lowPan will have to implement to be compatible with all other nodes claiming to be RPL compliant? My guess: * Classic RS/RA * DHCPv6 * 6lowPAN ND * RPL address assignment * etc Should we make a decision someday? (!) Thanks, Anders > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of Pascal Thubert (pthubert) > Sent: Thursday, April 29, 2010 09:01 > To: [email protected]; Richard Kelsey > Cc: [email protected]; [email protected] > Subject: Re: [Roll] how does a node get an IP address > > Hi Zach: > > I have yet to review the new ND-09 but my guts tell me that > it is the wrong place to do the job. Router to router is > usually routing protocol land and ND is definitely not a > routing protocol. > > The main question is how long can a router advertise a > prefix, and the answer is, as long as it is in the same > subnet of an authoritative router that owns the prefix. > Asserting the continuous reachability of the authoritative > router is a routing protocol problem. Maintaining a subnet > together is the job for a new form of Gateway Protocol, a > Subnet Gateway Protocol RPL is just that. > > Let see: > > - Propagating the RA content is not an ND intrinsic problem, > it only comes with route over. And route over comes with a > routing protocol. > - the route over protocol should be able to tie the route > over subnetwork together so it is a SGP. > > So why can't we just say in 6LoWPAN ND that you for those who > use it in route over we expect an SGP to tie the route over > subnetwork together and that the SGP should transport the RA > content, maintaining the validity with the reachability of > the authoritative router? I can write that text if you wish. > > It seems that we have a reasonable consensus in this thread > to do exactly that in RPL anyway... > > Pascal > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On Behalf > Of > > [email protected] > > Sent: Tuesday, April 27, 2010 10:36 PM > > To: Richard Kelsey > > Cc: [email protected] > > Subject: Re: [Roll] how does a node get an IP address > > > > Hi Everyone, > > > > Let me jump into this thread - just to make things more interesting > ;-) First, I > > recommend everyone goes and reads 6lowpan-nd-09 which was submitted > > today. When it comes to ND, you need to separate two interfaces. > > > > 1. The host-router interface > > > > Hosts know absolutely nothing about RPL (nor should they). Thus in > this case > > ND* does the job, and RS/RA is used for obtaining a prefix and > initializing its > > addresses. I think some people in the thread are referring to this. > > > > 2. The router-router interface > > > > As in RFC4861, in 6lowpan-nd-09 routers have more flexibility than > hosts in > > how they obtain prefix information (among other things). nd-09 does > include > > an optional technique for an authorative border router to > disseminate > PIOs > > and CIOs (Context Information Options) between the border router and > all > > routers in the LoWPAN using RAs. It is actually a decent > mechanism and > > improved over early versions. The draft clearly states that it is > optional as a > > routing algorithm may already do this. So Pascal is correct in that > respect. I > > haven't followed the thread well enough to have an opinion if RPL > should do > > that. > > > > Routers will also find other features of 6lowpan-nd-09 useful, for > example > > during initial bootstrapping, to maintain their default router and > neighbor > > caches, avoid the need for address resolution, and to > perform NUD. The > > draft (tries to) clearly state when features are required > or optional > for a > > router. > > > > Zach > > > > > > >> From: Michael Richardson <[email protected]> > > >> Date: Tue, 27 Apr 2010 10:38:47 -0400 > > >> > > >> >>>>> "Richard" == Richard Kelsey <[email protected]> > writes: > > >> >> Date: Tue, 27 Apr 2010 14:18:32 +0200 From: > "Pascal Thubert > > >> >> (pthubert)" <[email protected]> > > >> >> > > >> >> The question here is that the authoritative > routers need to > > >> >> disseminate the PIO (and the RIO) to all routers in the > subnet. > > >> > > >> Richard> How do other routing protocols (OSPF, IS-IS, AODV, > OLSR) > > >> > > >> I can only speak for OSPF and ISIS. > > >> Neither deal with multi-hop subnets or with any kind of address > > >> assignment. > > > > > > Why should RPL be any different? Yes, it will be run on > multi-hop > > > subnets, but I still do not see how this affects the routing. > > > > > >> Both were written when multicast was very new. > > > > > > I am not sure how RPL's handling of multicast matters here. > > > While RPL is required to route multi-hop multicasts, ND uses > > > link-local multicasts, which do not require routing. > > > > > >> Richard> I understand that multi-hop subnets are a > problem for ND, > > >> Richard> but I don't see how the routing protocol is affected. > > >> > > >> RPL either requires 6lowpan, or it doesn't. > > > > > > RPL should work fine with ordinary ND. Why would it require > 6lowpan? > > > > > >> If it doesn't, then it has to provide for ND to work, or for > another > > >> protocol to replace it. > > > > > > ND works fine, using link-local, one-hop multicasts. RPL need not > be > > > involved. > > > > > > If someone wants to run RPL on a node that uses neither > ordinary ND > or > > > 6lowpan's version, then they will need some third variety > of ND. I > do > > > not see why this is an issue for RPL to address. It > seems quite out > > > of scope. > > > > > > -Richard Kelsey > > > _______________________________________________ > > > Roll mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/roll > > > > > > > > > _______________________________________________ > > Roll mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
