Hi, On Thu, Oct 16, 2008 at 09:27, Pascal Thubert (pthubert) <[EMAIL PROTECTED] > wrote:
> Hi Carsten and all: > > I think we need to define context and usage in the architecture > document, not in HC. > > Now, there's this recurrent question about how many contexts and what > they are for: > - It is very hard to know how many we need if we do not know what they > are for in the first place. > - Another question that is not answered if the scope of a context. > > What we have today: > - The Current version of the HC WG doc uses contexts for anything > stateful > - The Current version of the HC WG doc enables up to 16 contexts. > A stupid question, DDF 10 context 0 is the same as the context DDF 01, in another way can you have up to 17 contexts ? > > Following the current HC assumptions, a context can be used to compress > anything down to /128. As Carsten mentions down here that includes > remote prefixes; and it also enables to fully compress a number of much > used addressed such as the application gateways and servers that the > nodes publish to. > > There could be a number of those babies, thus the number 16. > > My proposal is the following: > > - It is the edge router responsibility to maintain the contexts in all > nodes. The contexts are distributed by the edge routers through a new ND > option that the ND draft introduces, valid in RAs and Router > Registration Confirmation. It is something I don't understand. RA is for source prefix not destination prefix how sensors will know destination context. > > - the scope of a context is the set of devices attached to an interface > of that edge router. That is, it is guaranteed that entry 7 will means > the same for all nodes attached to a same interface on a same edge > router. > > - An edge router might use the same table on multiple interfaces. > > - For transparent mobility, it is allowed to have a common context table > across the subnet > > - a context entry contains a prefix and a prefix length. Length can be > 128. > > - entry 0 is the edge router global address > > - which context and how many there are (up to 16) is under the > responsibility of the edge router (config, radius, ...) > > - if a node can not support as many contexts as the edge router > requires, we can hope that it does not need them. > > - nodes should advertise how many contexts they can support max as they > attach to a router (ND) > > - the router should store that in it ND cache and expand any address > that the node can not understand > - an new ICMP can be introduced to reject an unknown entry. > > What do you think? I think this compression is good for sensors that stays in the same WSN, if a sensor is moving from one network to another (for instance parcel tracking) it may be very difficult to use that compression. Laurent > > > Pascal > > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Carsten Bormann > >Sent: lundi 13 octobre 2008 20:18 > >To: Jonathan Hui > >Cc: Carsten Bormann; 6lowpan > >Subject: Re: [6lowpan] Fwd: New Version > Notificationfordraft-ietf-6lowpan-hc-01 > > > >On Oct 13 2008, at 17:36, Jonathan Hui wrote: > > > >> most people were happy with just two contexts > > > >Let me just point out that in the example I sent to the list on Jul > >31, I used contexts for both the prefix of the 6lowpan and for > >prefixes of the main correspondent network. If you add the need for > >state transitions (renumbering, other reconfigurations), two seems low. > > > >I wouldn't mind an update of this example for HC-01. > > > >Gruesse, Carsten > > > >_______________________________________________ > >6lowpan mailing list > >[email protected] > >https://www.ietf.org/mailman/listinfo/6lowpan > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan > >
_______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
