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. 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. - 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? 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
