idnits 2.17.1 draft-mariager-6lowpan-v6over-dect-ule-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 2, 2012) is 4371 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-6lowpan-nd' is defined on line 358, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6LoWPAN Peter B. Mariager, Ed. 3 Internet-Draft Jens T. Petersen 4 Intended status: Informational RTX A/S 5 Expires: November 3, 2012 May 2, 2012 7 Transmission of IPv6 Packets over DECT Ultra Low Energy 8 draft-mariager-6lowpan-v6over-dect-ule-02 10 Abstract 12 DECT Ultra Low Energy is a low power air interface technology that is 13 defined by the DECT Forum and specified by ETSI. 15 The DECT air interface technology has been used world-wide in 16 communication devices for more than 15 years, primarily carrying 17 voice for cordless telephony but has also been deployed for data 18 centric services. 20 The DECT Ultra Low Energy is a recent addition to the DECT interface 21 primarily intended for low-bandwidth, low-power applications such as 22 sensor devices, smart meters, home automation etc. As the DECT Ultra 23 Low Energy interface inherits many of the capabilities from DECT, it 24 benefits from long range, interference free operation, world wide 25 reserved frequency band, low silicon prices and maturity. There is 26 an added value in the ability to communicate with IPv6 over DECT ULE. 28 This document describes how IPv6 is transported over DECT ULE using 29 6LoWPAN techniques. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on November 3, 2012. 48 Copyright Notice 49 Copyright (c) 2012 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . . 3 66 1.2. Terms Used . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. The DECT ULE Protocol Stack . . . . . . . . . . . . . . . . . . 4 68 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Addressing Model . . . . . . . . . . . . . . . . . . . . . . . 6 70 5. MTU Considerations . . . . . . . . . . . . . . . . . . . . . . 7 71 6. IPv6 Address Configuration . . . . . . . . . . . . . . . . . . 7 72 7. IPv6 Link Local Address . . . . . . . . . . . . . . . . . . . . 7 73 8. Unicast and Multicast address mapping . . . . . . . . . . . . . 8 74 9. Header Compression . . . . . . . . . . . . . . . . . . . . . . 8 75 10. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 76 11. Considerations . . . . . . . . . . . . . . . . . . . . . . . . 9 77 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 78 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 79 14. Security Considerations . . . . . . . . . . . . . . . . . . . . 9 80 15. Normative References . . . . . . . . . . . . . . . . . . . . . 9 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 83 1. Introduction 85 DECT Ultra Low Energy (DECT ULE or just ULE) is an air interface 86 technology building on the key fundamentals of traditional DECT / 87 CAT-iq but with specific changes to significantly reduce the power 88 consumption on the expense of data throughput. DECT ULE devices with 89 requirements to power consumption will operate on special power 90 optimized silicon, but can connect to a DECT Gateway supporting 91 traditional DECT / CAT-iq for cordless telephony and data as well as 92 the ULE extensions. DECT terminology operates with two major role 93 definitions: The Portable Part (PP) is the power constrained device, 94 while the Fixed Part (FP) is the Gateway or base station. This FP 95 may be connected to the internet. An example of a use case for DECT 96 ULE is a home security sensor transmitting small amounts of data (few 97 bytes) at periodic intervals through the FP, but is able to wake up 98 upon an external event (burglar) and communicate with the FP. 99 Another example incorporating both DECT ULE as well as traditional 100 CAT-iq telephony is an elderly pendant (broche) which can transmit 101 periodic status messages to a care provider using very little 102 battery, but in the event of urgency, the elderly person can 103 establish a voice connection through the pendant to an alarm service. 104 It is expected that DECT ULE will be integrated into many residential 105 gateways, as many of these already implements DECT CAT-iq for 106 cordless telephony. DECT ULE can be added as a software option for 107 the FP. It is desirable to consider IPv6 for DECT ULE devices due to 108 the large address space and well-known infrastructure. This document 109 describes how IPv6 is used on DECT ULE links to optimize power while 110 maintaining the many benefits of IPv6 transmission. [RFC4944] 111 specifies the transmission of IPv6 over IEEE 802.15.4. DECT ULE has 112 in many ways similar characteristics of IEEE 802.15.4, but also 113 differences. Many of the mechanisms defined in [RFC4944] can be 114 applied to the transmission of IPv6 on DECT ULE links. 116 This document specifies how to map IPv6 over DECT ULE inspired by 117 RFC4944 119 1.1. Requirements Notation 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in [RFC2119]. 125 1.2. Terms Used 127 PP: DECT Portable Part, typically the sensor node 129 FP: DECT Fixed Part, the gateway 130 LLME: Lower Layer Management Entity 132 NWK: Network 134 2. The DECT ULE Protocol Stack 136 The DECT ULE protocol stack consists of the PHY layer operating at 137 frequencies in the 1800 - 1920 MHz frequency band depending on the 138 region and uses a symbol rate of 1.152 Mbps. 140 In its generic network topology, DECT is defined as a cellular 141 network technology. However, the most common configuration is a star 142 network with a single FP defining the network with a number of PP 143 attached. The MAC layer must support both traditional DECT as this 144 is used for services like discovery, pairing, security features etc. 145 All these features have been reused from DECT. 147 The DECT ULE device can then switch to the ULE mode of operation, 148 utilizing the new ULE MAC layer features. The DECT ULE Data Link 149 Control (DLC) provides multiplexing as well as segmentation and re- 150 assembly for larger packets from layers above. The DECT ULE layer 151 should also implement per-message authentication and encryption. 153 In general, communication sessions can be initiated from both FP and 154 PP side. Depending of power down modes employed in the PP, latency 155 may occur when initiating sessions from FP side. MAC layer 156 communication can either take place using connection less packet 157 transfer with low overhead for short sessions or take place using 158 connection oriented bearers including media reservation. The MAC 159 layer autonomously selects the radio spectrum positions that are 160 available within the band and can rearrange these to avoid 161 interference. 163 The DECT ULE device will incorporate an Application Programmers 164 Interface (API) as well as common elements known as Generic Access 165 Profile (GAP) for enrolling into the network. The DECT ULE stack 166 provides support for a range of different application protocols. The 167 used application protocol is negotiated between the PP and FP when a 168 communication service is established. One of these application 169 protocols is 6LoWPAN over DECT ULE as described in this draft. 171 +----------------------------------------+ 172 | Applications | 173 +----------------------------------------+ 174 | Generic Access Profile | ULE Profile | 175 +----------------------------------------+ 176 | DECT/Service API | ULE Data API | 177 +--------------------+-------------------+ 178 | LLME | NWK | | 179 +--------------------+-------------------+ 180 | DECT DLC | DECT ULE DLC | 181 +--------------------+-------------------+ 182 | MAC Layer | 183 +--------------------+-------------------+ 184 | Physical Layer | 185 +--------------------+-------------------+ 187 Figure 1: DECT ULE Protocol Stack 189 The DLC layer has to provide a reliable channel, either directly or 190 through MAC layer service to the higher layers. It is expected that 191 the ULE 6LoWPAN adaptation layer can run directly on this DLC layer. 192 Figure 2 illustrates IPv6 over DECT ULE stack. 194 Constrained Application Protocol (CoAP) is an application protocol 195 specifically designed for resource constrained environments. CoAP 196 could be run on top of IPv6 supporting requests from the server and 197 requests of cached replies from a CoAP/HTTP proxy in the DECT Fixed 198 Part or in an external network infrastructure. 200 Alternatively, the use of HTTP light, as defined for CAT-iq v3 can be 201 considered. 203 +-------------------+ 204 | Applications | 205 +-------------------+ 206 | CoAP/HTTP | 207 +-------------------+ 208 |IPv6 adaption layer| 209 +-------------------+ 210 | DECT ULE DLC | 211 +-------------------+ 212 | DECT ULE MAC | 213 +-------------------+ 214 | DECT ULE PHY | 215 +-------------------+ 217 Figure 2: IPv6 over DECT ULE Stack 219 3. Requirements 221 DECT ULE technology sets strict requirements for low power 222 consumption and thus limits the allowed protocol overhead. 6LoWPAN 223 standard [RFC4944] provides useful generic functionality like header 224 compression, link-local IPv6 addresses, Neighbor Discovery and 225 stateless IP-address autoconfiguration for reducing the overhead in 226 802.15.4 networks. This functionality can be partly applied to DECT 227 ULE. 229 4. Addressing Model 231 Each DECT PP is assigned an (International Portable Equipment 232 Identity) during manufacturing. This identity has the size of 40 233 bits and is unique for the PP and will be used to constitute the MAC 234 address. 236 When bound to the FP, a PP is assigned a 20 bit TPUI (Temporary 237 Portable User Identity) which is unique within the FP. This TPUI is 238 used for addressing (layer 2) in messages between FP and PP. 240 Each DECT FP is assigned a (Radio Fixed Part Identity) during 241 manufacturing. This identity has the size of 40 bits and is unique 242 for a FP and will be used to constitute the MAC address. 243 Alternatively each DECT PP and DECT FP can be assigned a unique 244 (IEEE) MAC-48 address additionally to the DECT identities. 246 5. MTU Considerations 248 Generally the DECT ULE PP generate data that fits into one MAC Layer 249 packet (40 bytes or optionally 80 bytes) that is transferred to the 250 FP periodically, depending on application. IP data packets may be 251 much larger and hence MTU size should be the size of the IP data 252 packet. 254 Larger IP packets can be transferred with the Segmentation and 255 reassembly (SAR) feature of the DLC Layer. If an implementation 256 cannot support the larger MTU size (due to cost) then SAR needs to be 257 supported at upper layers. 259 The SAR feature of [RFC4944] section 5 could also be considered. 261 It is expected that the LOWPAN_IPHC packet will fulfill all the 262 requirements for header compression without spending unnecessary 263 overhead for mesh addressing. 265 It is important to realize that the support of larger packets will be 266 on the expense of battery life, as a large packet will be fragmented 267 into several or many MAC layer packets, each consuming power to 268 transmit / receive. 270 6. IPv6 Address Configuration 272 StateLess AutoConfiguration (SLAC) and other means to configure an 273 address on a ULE device. 275 Neighbor Discovery Optimization for Low-power and Lossy Networks 276 [I-D.ietf-6lowpan-hc]. 278 Resulting addressing can be achieved by combining the 40bit RFPI of 279 the FP and the 20bit TPUI of the PP. A mapping scheme to compute the 280 IID must be developed. If MAC-48 addresses are assigned the DECT PP 281 and FP, the IID are constructed as described in RFC4291 283 7. IPv6 Link Local Address 285 The IPv6 LLA [RFC4291] for a DECT ULE device is formed by appending 286 the prefix FE80::/64 to the IID address found through SLAAC. 288 All packets transferred between the ULE FP and PP are addressed on 289 MAC layer by the 20bit TPUI. 291 8. Unicast and Multicast address mapping 293 It should be investigated how to support the LOWPAN_BC0 packets for 294 broadcast How do we utilize the DECT Broadcast features for multicast 295 ? 297 DECT FP has MAC features to allow broadcast or multicast small amount 298 of data (max 27 bytes). However ULE PP entering into long sleep 299 period cannot receive these packets reliably. Other methods for 300 emulating broadcast/multicast could be considered, such as 301 replicating and queuing these packets until a ULE PP wakes up. 303 9. Header Compression 305 Compression Format for IPv6 Datagrams in Low Power and Lossy Networks 306 (6LoWPAN) [I-D.ietf-6lowpan-hc]. 308 In [RFC4944] different types of frame formats and related headers 309 have been defined to support fragmentation and mesh addressing. 311 In ULE context LoWPAN_IPHC compressed IPv6 header would be used by 312 default. Support for fragmentation is not required and mesh headers 313 can be added if required. 315 10. Security Considerations 317 The secure transmission of speech over DECT will be based on the 318 DSAA2 and DSC2 work being developed by the DF Security group / ETSI 319 TC DECT and the ETSI SAGE Security expert group. However, these 320 security mechanisms may not be fully compatible to the message 321 oriented nature of DECT ULE, hence alternative mechanisms are being 322 developed. 324 DECT ULE communication are secured by encryption and per-message 325 authentication through CCM mode (Counter with CBC-MAC), which 326 currently is being defined in the ETSI TC-DECT ULE group. It is 327 expected that the DECT ULE DLC layer will implement this per-message 328 authentication and encryption to provide additional security 329 mechanicms defined in ETSI TC-DECT. 331 The underlying algorithm for providing authentication and encryption 332 is based on AES128. Individual key for each ULE PP are generated 333 during the binding procedure. Encryption keys are renewed regularly. 334 DECT ULE does not use any shared encryption key. 336 11. Considerations 338 PP roaming between FP is not considered in this draft. The use of 339 repeater functionality is not considered in this draft 341 12. Acknowledgements 343 13. IANA Considerations 345 14. Security Considerations 347 15. Normative References 349 [ETSI EN300 175 (1-7)] 350 "". 352 [ETSI TS102 827] 353 "". 355 [I-D.ietf-6lowpan-hc] 356 "". 358 [I-D.ietf-6lowpan-nd] 359 "". 361 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 362 Requirement Levels", BCP 14, RFC 2119, March 1997. 364 [RFC4291] "". 366 [RFC4944] "". 368 Authors' Addresses 370 Peter B. Mariager (editor) 371 RTX A/S 373 Email: pm@rtx.dk 374 Jens T. Petersen 375 RTX A/S 377 Email: jtp@rtx.dk