Division By Zero

ゼロで割る

6LowPANについて少し考えてみた - その3

前回の続き。

結果として、RFC6282のヘッダ圧縮はリンクローカルユニキャストにおいてもRFC4944に勝る。

In the best
case, the LOWPAN_IPHC can compress the IPv6 header down to two octets
(the dispatch octet and the LOWPAN_IPHC encoding) with link-local
communication.

http://www.ietf.org/rfc/rfc6282.txt

RFC6282で標準化されたIPHCを前回と同じように表現すると以下のようになる。

IPv6 LOWPAN_HC1 LOWPAN_IPHC
Dispatch 0 bit 8 bit 3bit
Version 4 bit 0 bit 0 bit
Traffic Class/Flow Label 28 bit 1 bit 2 bit
Payload Length 16 bit 0 bit 0 bit
Next Header 8 bit 2 bit 1 bit
Hop Limit 8 bit 8 bit 2 bit
Source/Destination 256 bit 4 bit 8 bit
HC2 encoding 0 bit 1 bit 0 bit
total 320 bit 24 bit 16 bit

まず、Hop Limitは1, 64, 255, 後続データで指定の4パターンに整理することで、2 bitに圧縮。TC/FLは単純に省略/非省略を1 bitで表す形式から、例えば、QoSを表すDiffServe Code Pointだけをインラインに載せたりできるようになった。

Source/DestinationはHC1より、さらに複雑になっており、コンテキスト識別子拡張フラグ1 bit、マルチキャスト圧縮フラグ1 bit、Source/Destination毎にアドレス圧縮フラグ1 bitとアドレスモードフラグ2 bitで合計8 bitとなる。

コンテキスト識別子拡張というのは、6LowPANパケットをやりとりするノード間で、あらかじめIPv6アドレスそれに対応するコンテキストIDとを決めておき、6LowPANパケットには実アドレスではなく、コンテキストIDを記述することで、圧縮率を高める方法。コンテキスト識別子と対応するIPv6アドレスの配布や、管理方法等はRFC6282では定義されていない。アドレスモードフラグで、単にコンテキストIDに対応する128 bitアドレスをフルで利用する、16 bitをインラインに載せる、64 bitをインラインに載せる、等の選択ができる。

コンテキスト識別子拡張を利用しない場合も、やはりアドレスモードフラグで、インラインに載せるビット数を128 bit/64 bit/16 bit/0 bitから選択できる。

コンテキスト識別子拡張を使う場合も使わない場合も、16 bitをインラインに載せる場合は、後半64 bitは0000:00ff:fe00:XXXXとなる。前半64 bitはもちろんリンクローカルプレフィクスとなる。この0000:00ff:fe00:XXXXは、short addressを使っている802.15.4リンクでも利用される。

IPv6マルチキャストアドレスは最初の8 bitが0xFFになるなどの決まりがあり、これを考慮した圧縮するための仕組みがマルチキャスト圧縮フラグ。もともとIPv6マルチキャストはSouceに指定することはできないため、Destinationに対してのみ有効。やはり、アドレスモードフラグとの組み合わせで、インラインで載せるビット数を切り替えられる。

standardなIPv6と比較すると、実情に応じた決め事を増やすことで圧縮率を稼ごうとしている6LowPANは複雑であまり美しくないように思える。非効率な部分があっても半導体をはじめとする技術の進歩が解決してくれる、という楽天的なムードすら感じさせるTCP/IPやHTTPのシンプルさとは対照的な、6LowPANのコスト最優先の考え方はとっても現代風だ。

残りのNext Header/HC2 encodingは、次のレイヤ、たとえばUDP等の圧縮に関わっているが、長くなったので今日はこれで終了!