Lowpanners,
in the meeting, we have been discussing draft-hui-6lowpan-hc-01.txt
(which I'll call "HC-01" here) with respect to the way to obtain the
context required. I'd like to move back to the specific kinds of
compression we can get.
Let's recap HC1, which has four different modes for each direction,
which lets us independently switch on prefix and IID compression:
00: PI, II
01: PI, IC
10: PC, II
11: PC, IC
PI/II means we actually encode the prefix and IID parts, respectively,
in the packet. PC means the prefix is compressed by assuming it is
FE80::, IC means the IID is taken/constructed from the appropriate L2
information, or, if present, the "mesh addressing" field.
HC-01 has a couple more modes, gated on AC (SAC/DAC) and AM (SAM/DAM).
AM can be:
00: All 128 bits of Source Address are carried in-line.
01: 64-bit Compressed IPv6 address.
10: 16-bit Compressed IPv6 address.
11: All 128 bits of Source Address are elided.
AC can be 00 (FE80::) or a context that is presumably giving a global
prefix.
CBHC-00 has:
Context Prefix
Number Length
0 0 (uncompressed)
1-3 TBD
4-7 /64
8-11 /112
12-15 /128
CBHC-00 clearly forgot link-local, so let me amend that to include a
second constant context:
1 FE80::/64
CBHC also needs to have the IC flag from 4944 for the contexts 1 and
4-7; so I'll need to rejuggle the bits a bit (say, use context 2 for
FE80::/64 with IC, and the rest split up between IC=0 and IC=1).
Now let's see some examples. I'll ignore 16-bit addresses for now (I
think HC-01 has set this up nicely, but examples would help verify
that).
The global prefix for our 6lowpan is 2345::
For simplicity, I'll abbreviate the IIDs as 2:1:1:1, 2:2:2:2, 2:3:3:3,
or "own" if this is the L2 IID; 2:1:1:1 is the border router.
The 6lowpan is communicating with a single correspondent network
somewhere in the Internet, with addresses 2468::5, 2468::6, 268::7.
We could have the following addresses in a packet:
FE80::own
FE80::2:1:1:1
FE80::2:2:2:2
FE80::2:3:3:3
2345::own
2345::2:1:1:1
2345::2:2:2:2
2345::2:3:3:3
2468::5
2468::6
The assumption in CBHC would be that the context is set up as follows:
4: 2345::/64
8: 2468::/112
12: 2468::5/128
13: 2468::6/128
14: 2468::7/128
15: 2345::2:1:1:1
8 and 12/13/14 are somewhat redundant here, but in practice there
probably will be more nodes in the correspondent network, so I wanted
to show both alternatives for CBHC (there may also be multiple
correspondent networks, of course). Note that the encoding of the
context can be done in such a way that there is no redundancy between
4 and 15.
In HC-01, the context might be set up as:
1: 2345::2:1:1:1
2: 2468::5
3: 2468::6
Now let's encode:
4944 CBHC HC-01
FE80::own 11, 0 ctx=1, II=1, [] am=11, ac=0
FE80::2:1:1:1 10, [2:1:1:1] ctx=1, II=0, [2:1:1:1] am=01, ac=0,
[2:1:1:1]
FE80::2:2:2:2 10, [2:2:2:2] ctx=1, II=0, [2:2:2:2] am=01, ac=0,
[2:2:2:2]
FE80::2:3:3:3 10, [2:3:3:3] ctx=1, II=0, [2:3:3:3] am=01, ac=0,
[2:3:3:3]
2345::own 01, [2345::] ctx=4, II=1 am=11, ac=0,
[own]
2345::2:1:1:1 00, (uncompr) ctx=15 am=11, ac=1
2345::2:2:2:2 00, (uncompr) ctx=4, II=0, [2:2:2:2] am=01, ac=1,
[2:2:2:2]
2345::2:3:3:3 00, (uncompr) ctx=4, II=0, [2:3:3:3] am=01, ac=1,
[2:3:3:3]
2468::5 00, (uncompr) ctx=12 (or 8, [5]) am=11, ac=2
2468::6 00, (uncompr) ctx=13 (or 8, [6]) am=11, ac=3
2468::7 00, (uncompr) ctx=14 (or 8, [7]) am=10, ac=2,
[7]
I have no idea whether I correctly interpreted HC-01, and I obviously
have to fix CBHC, so I'm looking forward to discussion.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan