Left: | ||
Right: |
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 ====== |
(...skipping 14 matching lines...) Expand all Loading... | |
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· |
Tom Henderson
2013/11/29 15:40:50
The 802.15.4 NetDevice is not supported yet, right
Tommaso Pecorella
2013/11/30 10:52:41
Done.
| |
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. |
Tom Henderson
2013/11/29 15:40:50
default value? might help to state your model's d
Tommaso Pecorella
2013/11/30 10:52:41
Done,
| |
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: |
Tom Henderson
2013/11/29 15:40:50
sources
also, what point are these tracing (logic
Tommaso Pecorella
2013/11/30 10:52:41
Done. And modified the drop trace to include the p
| |
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 ***** |
Tom Henderson
2013/11/29 15:40:50
If we are able to patch things up on the 802.15.4
Tommaso Pecorella
2013/11/30 10:52:41
I'm actually writing a patch to lr-wpan to do that
| |
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 |