Salut Laurent :-)
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 ? [Pascal] You're behind by one version; see http://tools.ietf.org/id/draft-ietf-6lowpan-hc-01.txt 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. [Pascal] we need something like Carsten's CEP to sync all the nodes in the contxet scope/ Now a context entry (say an address) can be used source or destination. For instance, if many sensors are publishing their data to server 2001::1 then we could use a context entry for 2001::1. Context 3 would be the destinarion context for publishing and the source for subscribing. Say that the sensor network is 2002::/64 and we have sensor with IP address is based on EUI-48 following RFC4944 addressing. I assume here that context 0 is the default context, (and BTW that is contains the full address of the edge router) and a prefix length of 64. We'll end up with a 3 bytes dispatch + HC. For publishin we'll get: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+--- +---+---+---+---+---+---+ | 0 | 1 | 0 | 0 | 1 | TF |NH | HLIM | DDF | SAM | DAM | src context | dest context | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+--- +---+---+---+---+---+---+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+--- +---+---+---+---+---+---+ | 0 | 1 | 0 | 0 | 1 | TF |NH | HLIM | 0 1 | 0 1 | 1 | 1 | 0 | 3 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+--- +---+---+---+---+---+---+ DDF: Destination Dependant Field: 01: Destination and Source are Global or Unique Local Addresses and one additional context octet extends the LOWPAN_IPHC field to disambiguate an elided prefix or address described by the SAM or DAM fields. SAM: Source Address Mode: When the Destination is a Global or Unique Local Addresses: 01: 64 bits: the prefix of Source Address is elided. DAM: Destination Address Mode: When the Destination is a Global or Unique Local Addresses: 11: 0 bit: The Destination Address is fully elided. - 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. Well, the sensor as it moves away from its subnet will have to form a new address. Part of thart process will be to learn contexts. Hopefully this can be done within existing flows. The context is not supposed to change too often or the node to move very rapidly between subnets. There are limits where another technology with more power becomes necessary. 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
