LEFT | RIGHT |
1 PageBreak | 1 PageBreak |
2 | 2 |
3 Transmission of IPv6 Packets over IEEE 802.15.4 Networks (6LoWPAN) | 3 Transmission of IPv6 Packets over IEEE 802.15.4 Networks (6LoWPAN) |
4 ------------------------------------------------------------------ | 4 ------------------------------------------------------------------ |
5 | 5 |
6 This chapter describes the implementation of ns-3 model for the | 6 This chapter describes the implementation of |ns3| model for the |
7 compression of IPv6 packets over IEEE 802.15.4-Based Networks· | 7 compression of IPv6 packets over IEEE 802.15.4-Based Networks· |
8 as specified by RFC 4944 and RFC 6262. | 8 as specified by RFC 4944 and RFC 6262. |
9 | 9 |
10 Model Description | 10 Model Description |
11 ***************** | 11 ***************** |
12 | 12 |
13 The source code for the sixlowpan module lives in the directory ``src/sixlowpan`
`. | 13 The source code for the sixlowpan module lives in the directory ``src/sixlowpan`
`. |
14 | 14 |
15 Design | 15 Design |
16 ====== | 16 ====== |
17 | 17 |
18 The model design does not follow strictly the standard from an architectural· | 18 The model design does not follow strictly the standard from an architectural· |
19 standpoint, as it does extend it beyond the original scope by supporting also | 19 standpoint, as it does extend it beyond the original scope by supporting also |
20 other kinds of networks. | 20 other kinds of networks. |
21 | 21 |
22 Other than that, the module does strictly follow RFCs 4944 and 6262, with the· | 22 Other than that, the module strictly follows RFCs 4944 and 6262, with the· |
23 following exceptions: | 23 following exceptions: |
24 * MESH and LOWPAN_BC0 dispatch types are not supported | 24 * MESH and LOWPAN_BC0 dispatch types are not supported |
25 * HC2 encoding is not supported | 25 * HC2 encoding is not supported |
26 * IPHC's SAC and DAC are not supported | 26 * IPHC's SAC and DAC are not supported |
27 | 27 |
28 The MESH and LOWPAN_BC0 are not supported as they do apply only to mesh-under | 28 The MESH and LOWPAN_BC0 are not supported as they do apply only to mesh-under |
29 architecture, which is not one of the goals of the module development. | 29 architecture, which is not one of the goals of the module development. |
30 | 30 |
31 The HC2 encoding is not supported, as it has been superseded by IPHC and NHC | 31 The HC2 encoding is not supported, as it has been superseded by IPHC and NHC |
32 compression type (RFC 6262). | 32 compression type (RFC 6262). |
33 | 33 |
34 IPHC SAC and DAC are not yet supported, as they do require RFC 6775 for full· | 34 IPHC SAC and DAC are not yet supported, as they do require RFC 6775 for full· |
35 compliance. It is planned to support them in the future.· | 35 compliance. It is planned to support them in the future.· |
36 | 36 |
37 NetDevice | 37 NetDevice |
38 ######### | 38 ######### |
39 | 39 |
40 The whole module is developed as a transparent NetDevice, which can act as a | 40 The whole module is developed as a transparent NetDevice, which can act as a |
41 proxy between IPv6 and any NetDevice. | 41 proxy between IPv6 and any NetDevice (the module has been successfully tested· |
| 42 with PointToPointNedevice, CsmaNetDevice and LrWpanNetDevice). |
42 | 43 |
43 For this reason, the module implments a virtual NetDevice, and all the calls are
passed | 44 For this reason, the module implements a virtual NetDevice, and all the calls ar
e passed |
44 without modifications to the underlying NetDevice. The only important difference
is in | 45 without modifications to the underlying NetDevice. The only important difference
is in |
45 GetMtu behaviour. It will always return *at least* 1280 bytes, as is the minumum
IPv6 MTU. | 46 GetMtu behaviour. It will always return *at least* 1280 bytes, as is the minumum
IPv6 MTU. |
46 | 47 |
47 The module does provide some attributes and some tracesources. | 48 The module does provide some attributes and some tracesources. |
48 The attributes are: | 49 The attributes are: |
49 * Rfc6282 (boolean), used to activate HC1 (RFC 4944) or IPHC (RFC 6282) compress
ion. | 50 * Rfc6282 (boolean, default true), used to activate HC1 (RFC 4944) or IPHC (RFC
6282) compression. |
50 * OmitUdpChecksum (boolean), used to activate UDP checksum compression in IPHC. | 51 * OmitUdpChecksum (boolean, default true), used to activate UDP checksum compres
sion in IPHC. |
51 * FragmentReassemblyListSize (integer), indicating the number of packets that ca
n be reassembled at the same time. If the limit is reached, the oldest packet is
discarded. | 52 * FragmentReassemblyListSize (integer, default 0), indicating the number of pack
ets that can be reassembled at the same time. If the limit is reached, the oldes
t packet is discarded. Zero means infinite. |
52 * FragmentExpirationTimeout (Time), being the timeout to wait for further fragme
nts before discarding a partial packet. | 53 * FragmentExpirationTimeout (Time, default 60 seconds), being the timeout to wai
t for further fragments before discarding a partial packet. |
53 * ForceEtherType (boolean), and | 54 * ForceEtherType (boolean, default false), and |
54 * EtherType (unsigned 16 bits integer), to force a particular L2 EtherType. | 55 * EtherType (unsigned 16 bits integer, default 0xFFFF), to force a particular L2
EtherType. |
55 | 56 |
56 The last two attributes are needed to use the module with a NetDevice other than
802.15.4, as | 57 The last two attributes are needed to use the module with a NetDevice other than
802.15.4, as |
57 neither IANA or IEEE did reserve an EtherType for 6LoWPAN. As a consequence ther
e might be a | 58 neither IANA or IEEE did reserve an EtherType for 6LoWPAN. As a consequence ther
e might be a |
58 conflict with the L2 multiplexer/demultiplexer which is based on EtherType. The
default· | 59 conflict with the L2 multiplexer/demultiplexer which is based on EtherType. The
default· |
59 value is 0xFFFF, which is reserved by IEEE. | 60 value is 0xFFFF, which is reserved by IEEE. |
60 The default module behaviour is to not change the EtherType, however this would
not work with | 61 The default module behaviour is to not change the EtherType, however this would
not work with |
61 any NetDevice actually understanding and using the EtherType. | 62 any NetDevice actually understanding and using the EtherType. |
62 | 63 |
63 Note that the `ForceEtherType` parameter have also a direct effect on the MAC ad
dress kind the | 64 Note that the `ForceEtherType` parameter have also a direct effect on the MAC ad
dress kind the |
64 module is expecting to handle: | 65 module is expecting to handle: |
65 * ForceEtherType true: Mac48Address (Ethernet, WiFi, etc.). | 66 * ForceEtherType true: Mac48Address (Ethernet, WiFi, etc.). |
66 * ForceEtherType false: Mac16Address or Mac64Address (IEEE 802.15.4). | 67 * ForceEtherType false: Mac16Address or Mac64Address (IEEE 802.15.4). |
67 | 68 |
| 69 Note that using 6LoWPAN over any NetDevice other than 802.15.4 will produce vali
d .pcap files, |
| 70 but they will not be correctly dissected by Wireshark. |
| 71 The reason lies on the fact that 6LoWPAN was really meant to be used only over 8
02.15.4, so |
| 72 Wireshark dissectors will not even try to decode 6LoWPAN headers on top of proto
cols other than |
| 73 802.15.4. |
68 | 74 |
69 The Trace suorces are: | 75 The Trace sources are: |
70 * Tx | 76 * Tx - exposing packet (including 6LoWPAN header), SixLoWPanNetDevice Ptr, inter
face index. |
71 * Rx | 77 * Rx - exposing packet (including 6LoWPAN header), SixLoWPanNetDevice Ptr, inter
face index. |
72 * Drop | 78 * Drop - exposing DropReason, packet (including 6LoWPAN header), SixLoWPanNetDev
ice Ptr, interface index. |
| 79 |
| 80 The Tx and Rx traces are called as soon as a packet is received or sent. The Dro
p trace is |
| 81 invoked when a packet (or a fragment) is discarded. |
| 82 |
73 | 83 |
74 Scope and Limitations | 84 Scope and Limitations |
75 ===================== | 85 ===================== |
76 | 86 |
77 Future versions of this module will support RFC 6775, however no timeframe is gu
aranteed. | 87 Future versions of this module will support RFC 6775, however no timeframe is gu
aranteed. |
| 88 |
| 89 Using 6LoWPAN with IPv4 (or other L3 protocols) |
| 90 ############################################### |
| 91 |
| 92 As the name implies, 6LoWPAN can handle only IPv6 packets. Any other protocol wi
ll be discarded. |
| 93 Moreover, 6LoWPAN assumes that the network is uniform, as is all the devices con
nected by the |
| 94 same same channel are using 6LoWPAN. Mixed environments are not supported by the
standard. |
| 95 The reason is simple: 802.15.4 frame doesn't have a "protocol" field. As a conse
quence, |
| 96 there is no demultiplexing at MAC layer and the protocol carried by L2 frames mu
st be known |
| 97 in advance. |
| 98 |
| 99 In the |ns3| implementation it is possible, but not advisable, to violate this r
equirement |
| 100 if the underlying NetDevice is capable of discriminating different protocols. As
an example, |
| 101 CsmaNetDevice can carry IPv4 and 6LoWPAN at the same time. However, this configu
ration has· |
| 102 not been tested. |
78 | 103 |
79 References | 104 References |
80 ========== | 105 ========== |
81 | 106 |
82 * RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". | 107 * RFC 4944, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks". |
83 * RFC 6282, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Netw
orks". | 108 * RFC 6282, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Netw
orks". |
84 * http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xml | 109 * http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xml |
85 * http://standards.ieee.org/develop/regauth/ethertype/eth.txt | 110 * http://standards.ieee.org/develop/regauth/ethertype/eth.txt |
86 | 111 |
87 Usage | 112 Usage |
88 ***** | 113 ***** |
89 | 114 |
90 Enabling sixlowpan | 115 Enabling sixlowpan |
91 ================== | 116 ================== |
92 | 117 |
93 Add ``sixlowpan`` to the list of modules built with ns-3. | 118 Add ``sixlowpan`` to the list of modules built with |ns3|. |
94 | 119 |
95 Helper | 120 Helper |
96 ====== | 121 ====== |
97 | 122 |
98 The helper is patterned after other device helpers.· | 123 The helper is patterned after other device helpers.· |
99 | 124 |
100 Examples | 125 Examples |
101 ======== | 126 ======== |
102 | 127 |
103 The following example can be found in ``src/sixlowpan/examples/``: | 128 The following example can be found in ``src/sixlowpan/examples/``: |
104 | 129 |
105 * ``example-sixlowpan.cc``: A simple example showing end-to-end data transfer. | 130 * ``example-sixlowpan.cc``: A simple example showing end-to-end data transfer. |
106 | 131 |
107 In particular, the example enables a very simplified end-to-end data | 132 In particular, the example enables a very simplified end-to-end data |
108 transfer scenario, with a CSMA network forced to carry 6LoWPAN compressed packet
s. | 133 transfer scenario, with a CSMA network forced to carry 6LoWPAN compressed packet
s. |
109 | 134 |
110 | 135 |
111 Tests | 136 Tests |
112 ===== | 137 ===== |
113 | 138 |
114 The test provided checks the connection between two UDP clients and the correctn
ess of the received packets. | 139 The test provided checks the connection between two UDP clients and the correctn
ess of the received packets. |
115 | 140 |
116 Validation | 141 Validation |
117 ********** | 142 ********** |
118 | 143 |
119 The model has been validated against WireShark, checking whatever the packets ar
e correctly | 144 The model has been validated against WireShark, checking whatever the packets ar
e correctly |
120 interpreted and validated. | 145 interpreted and validated. |
121 | 146 |
122 | 147 |
LEFT | RIGHT |