Transcript PowerPoint Presentation - 6LoWPAN Interoperability

Compression Format for IPv6
Datagrams in 6LoWPAN Networks
Jonathan Hui
6LoWPAN WG Meeting
71st IETF Meeting
Philadelphia, PA
03/11/2008
71st IETF Meeting - 6LoWPAN WG
1
RFC 4944 – IPv6 Header Compression
0
1
SA
2
3
DA
4
TF
5
6
NH
7
HC2
uncompressed fields…
• Most effective when communicating with link-local
addresses
– Prefix: must be carried in-line when not link-local
• Route-over, ROLL
• Communicating with devices outside PAN
– Suffix: must be 64 bits when carried in-line
• No provision to shorten it even when IID is derived from short
802.15.4 address.
– Multicast: must carry all 128 bits in-line
• Even for commonly used multicast addresses (e.g. link-local all
nodes, IPv6 ND, etc.)
– Hop-limit always carried in-line
03/11/2008
71st IETF Meeting - 6LoWPAN WG
2
RFC 4944 – Next Header Compression
• Defined for UDP header
– No way to elide Checksum
• End-to-end integrity checks may be provided by other end-toend mechanisms (e.g. security).
– No support for future compression of arbitrary next
headers
• UDP, TCP, or ICMPv6 only
03/11/2008
71st IETF Meeting - 6LoWPAN WG
3
Proposed 6LoWPAN HC
• Generalize LOWPAN_HC1/HC2
– Broader range of communication paradigms
• Mesh-under, route-over, communication with external devices,
multicast
– Framework for compression of arbitrary next headers
• UDP compression initially defined within this framework
– IPv6 Hop Limit and UDP Checksum compression
– Carry forward design concepts
• Minimize state
• Rely on shared context
03/11/2008
71st IETF Meeting - 6LoWPAN WG
4
LOWPAN_IPHC
IPv6 Header Compression
0
1
VTF NH
•
•
•
•
•
•
•
2
3
HLIM
4
5
SA
6
7
DA
uncompressed fields…
VTF: Version, Traffic Class, Flow Label
NH: Next Hop
HLIM: Hop Limit
SA: Source Address
DA: Destination Address
rsv: reserved
Payload Length always elided
03/11/2008
71st IETF Meeting - 6LoWPAN WG
5
LOWPAN_IPHC
Address Compression
00: 128 bits
Full 128-bit Address In-Line
01: 64 bits
CP Implicit
10: 16 bits
CP Implicit
11: 0 bits
CP Implicit
64-bit Suffix In-Line
0’s
SA
From Lower Layers
• Common Prefix (CP)
– Implicit when prefix is elided
– Link-local (LL) or Common Routable Prefix (CRP)
• Identified by different 6LoWPAN Dispatch values
• SA derived from IEEE 802.15.4 Short Address
• Elided suffix derived from lower-layers
03/11/2008
71st IETF Meeting - 6LoWPAN WG
6
LOWPAN_IPHC
Obtaining the Common Routable Prefix
• Assumption
– 6LoWPAN network operate under a single administrative domain
• Single-homed
– CRP is trivial (the only prefix assigned to the PAN).
– Renumbering inconsistencies caught with pseudo-header
checksum
• Multi-homed
– Need to specify a protocol and think through the operational
details
– Can we go without for now?
03/11/2008
71st IETF Meeting - 6LoWPAN WG
7
LOWPAN_IPHC
IID Derived from 802.15.4 Short Addresses
• RFC 4944
– Includes PAN ID and 0xFFFE
– Is there a need to assign the same prefix to >1 PAN?
• Instead, prefix Short Address with zeros
– u/l-bit is zero, indicating local scope
– Could also be some fixed bit-pattern, other than 0’s.
0’s
03/11/2008
SA
71st IETF Meeting - 6LoWPAN WG
8
LOWPAN_IPHC
Hop Limit Compression
• 1 bit to indicate compression
• 1 bit to indicate 63 (egress) or 1 (ingress)
• Most useful for mesh-under
– All nodes connected via a single IP hop
• Not as useful for route-over
– Forwarding nodes have to expand anyway
03/11/2008
71st IETF Meeting - 6LoWPAN WG
9
LOWPAN_IPHC
Multicast Address Compression
• For commonly-used, well-known multicast addresses
– Divide 16-bit compressed address into ranges
• Unicast: 0xxxxxxxxxxxxxxx
• Multicast: 100xxxxxxxxxxxxx
128 bits
FF Flags
Scope
0
1
Group ID
2
1 0 0
3
4
5
Scope
6
7
8
9
0
1
2
3
4
5
Group ID
• Prefix (8-bits): Compressed to 3-bit range
• Flags (4-bits): Assumed to be zero
– permanent, not derived from prefix, doesn’t embed RP
• Scope (4-bits): Carried in-line
• Group ID (112-bits): Mapped to 9-bits
– Currently defined: All Nodes (1) and All Routers (2)
03/11/2008
71st IETF Meeting - 6LoWPAN WG
10
LOWPAN_NHC
Next Header Compression
0
1
2
3
ID
SP
DP
C
4
5
6
7
rsv
uncompressed fieds…
• IPHC NH indicates next header compression
– IPv6 Next Header elided, derived from first bits in NHC
– Encoding gives shorter bit-patterns to frequently used next headers
•
•
•
•
•
ID: 0 for UDP, 1 for other
SP: Source Port
DP: Destination Port
C: Checksum
Length always elided
• Checksum MUST NOT be elided when no other end-to-end integrity
cover the pseudo-header, UDP header, and UDP payload
03/11/2008
71st IETF Meeting - 6LoWPAN WG
11
Unicast Examples
• Link-Local, Mesh-Under (9 bytes)
5
15.4
1
6LoWPAN Mesh Header
1
Disp. IPHC
1
1
NHC
Ports
1
1
NHC
Ports
• Link-Local, Route-Over (4 bytes)
1
15.4
1
Disp. IPHC
1
1
NHC
Ports
• Routable, Mesh-Under (9 bytes)
5
15.4
1
6LoWPAN Mesh Header
1
Disp. IPHC
• Routable Addresses, Route-Over (9 bytes)
1
15.4
03/11/2008
1
1
Disp. IPHC HLIM
2
2
1
1
Src Addr
Dst Addr
NHC
Ports
71st IETF Meeting - 6LoWPAN WG
12
Multicast Examples
• Link-Local, Mesh-Under (11 bytes)
5
15.4
1
6LoWPAN Mesh Header
1
1
1
Disp. Bcast Disp. IPHC
1
1
NHC
Ports
1
1
NHC
Ports
• Link-Local, Route-Over (6 bytes)
15.4 Disp. IPHC
Dst Addr
NHC
Ports
• Routable, Mesh-Under (11 bytes)
5
15.4
1
6LoWPAN Mesh Header
1
1
1
Disp. Bcast Disp. IPHC
• Routable Addresses, Route-Over (9 bytes)
1
1
1
15.4 Disp. IPHC HLIM
03/11/2008
2
2
1
1
Src Addr
Dst Addr
NHC
Ports
71st IETF Meeting - 6LoWPAN WG
13
6LoWPAN HC Summary
• Generalize LOWPAN_HC1/HC2
– Broader range of communication paradigms
• Mesh-under, route-over, communication with external devices,
multicast
– Framework for compression of arbitrary next headers
• UDP compression initially defined within this framework
– IPv6 Hop Limit and UDP Checksum compression
– Carry forward design concepts
• Minimize state
• Rely on shared context
03/11/2008
71st IETF Meeting - 6LoWPAN WG
14
Discussion
• Should 6lowpan-hc become a WG doc?
03/11/2008
71st IETF Meeting - 6LoWPAN WG
15
Combining IPHC and NHC
(From Discussion with Pascal Thubert)
• Another dispatch for combining LOWPAN_IPHC/NHC?
– Fully elided Source and Destination addresses and Hop Limit
– Next header compression
0
1
VTF HLIM
2
3
4
5
0
SP
DP
C
6
5
7
rsv
uncompressed fields…
• Pro: Save an additional octet
• Con: Additional code overhead
03/11/2008
71st IETF Meeting - 6LoWPAN WG
16