idnits 2.17.1 draft-mariager-6lowpan-v6over-dect-ule-01.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 (October 31, 2011) is 4533 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-6lowpan-nd' is defined on line 354, 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: May 3, 2012 October 31, 2011 7 Transmission of IPv6 Packets over DECT Ultra Low Energy 8 draft-mariager-6lowpan-v6over-dect-ule-01 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 May 3, 2012. 48 Copyright Notice 49 Copyright (c) 2011 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. 167 +----------------------------------------+ 168 | Applications | 169 +----------------------------------------+ 170 | Generic Access Profile | ULE Profile | 171 +----------------------------------------+ 172 | DECT/Service API | ULE Data API | 173 +--------------------+-------------------+ 174 | LLME | NWK | | 175 +--------------------+-------------------+ 176 | DECT DLC | DECT ULE DLC | 177 +--------------------+-------------------+ 178 | MAC Layer | 179 +--------------------+-------------------+ 180 | Physical Layer | 181 +--------------------+-------------------+ 183 Figure 1: DECT ULE Protocol Stack 185 The DLC layer layer has to provide a reliable channel, either 186 directly or through MAC layer service to the higher layers. It is 187 expected that the ULE 6LoWPAN adaptation layer can run directly on 188 this DLC layer. Figure 2 illustrates IPv6 over DECT ULE stack. 190 Constrained Application Protocol (CoAP) is an application protocol 191 specifically designed for resource constrained environments. CoAP 192 could be run on top of IPv6 supporting requests from the server and 193 requests of cached replies from a CoAP/HTTP proxy in the DECT Fixed 194 Part. 196 Alternatively, the use of HTTP light, as defined for CAT-iq v3 can be 197 considered. 199 +-------------------+ 200 | Applications | 201 +-------------------+ 202 | CoAP/HTTP | 203 +-------------------+ 204 |IPv6 adaption layer| 205 +-------------------+ 206 | DECT ULE DLC | 207 +-------------------+ 208 | DECT ULE MAC | 209 +-------------------+ 210 | DECT ULE PHY | 211 +-------------------+ 213 Figure 2: IPv6 over DECT ULE Stack 215 3. Requirements 217 DECT ULE technology sets strict requirements for low power 218 consumption and thus limits the allowed protocol overhead. 6LoWPAN 219 standard [RFC4944] provides useful generic functionality like header 220 compression, link-local IPv6 addresses, Neighbor Discovery and 221 stateless IP-address autoconfiguration for reducing the overhead in 222 802.15.4 networks. This functionality can be partly applied to DECT 223 ULE. 225 4. Addressing Model 227 Each DECT PP is assigned an (International Portable Equipment 228 Identity) during manufacturing. This identity has the size of 40 229 bits and is unique for the PP and will be used to constitute the MAC 230 address. 232 When bound to the FP, a PP is assigned a 20 bit TPUI (Temporary 233 Portable User Identity) which is unique within the FP. This TPUI is 234 used for addressing in messages between FP and PP. 236 Each DECT FP is assigned a (Radio Fixed Part Identity) during 237 manufacturing. This identity has the size of 40 bits and is unique 238 for a FP and will be used to constitute the PAN identity. 240 5. MTU Considerations 242 Generally the DECT ULE PP generate data that fits into one MAC Layer 243 packet (40 bytes or optionally 80 bytes) that is transferred to the 244 FP periodically, depending on application. IP data packets may be 245 much larger and hence MTU size should be the size of the IP data 246 packet. 248 Larger IP packets can be transferred with the Segmentation and 249 reassembly (SAR) feature of the DLC Layer. If an implementation 250 cannot support the larger MTU size (due to cost) then SAR needs to be 251 supported at upper layers. 253 The SAR feature of [RFC4944] section 5 could also be considered. 255 It is expected that the LOWPAN_IPHC packet will fulfill all the 256 requirements for header compression without spending unnecessary 257 overhead for mesh addressing. 259 It is important to realize that the support of larger packets will be 260 on the expense of battery life, as a large packet will be fragmented 261 into several or many MAC layer packets, each consuming power to 262 transmit / receive. 264 6. IPv6 Address Configuration 266 StateLess AutoConfiguration (SLAC) and other means to configure an 267 address on a ULE device. 269 Neighbor Discovery Optimization for Low-power and Lossy Networks 270 [I-D.ietf-6lowpan-hc]. 272 Resulting addressing can be achieved by combining the 40bit RFPI of 273 the FP and the 20bit TPUI of the PP. A mapping scheme to compute the 274 IID must be developed. 276 7. IPv6 Link Local Address 278 How do we form the IPv6 Link Local Address, or can this be obtained 279 from the IID using SLAC ? 281 The IPv6 LLA [RFC4291] for a DECT ULE device is formed by appending 282 the XXXX to form the 128 bit LLA. this is done by appending the 283 prefix FE80::/64 to the IPv6 address found through SLAAC. 285 All packets transferred between the ULE FP and PP are addressed on 286 MAC layer by the 20bit TPUI. 288 8. Unicast and Multicast address mapping 290 It should be investigated how to support the LOWPAN_BC0 packets for 291 broadcast How do we utilize the DECT Broadcast features for multicast 292 ? 294 DECT FP has MAC features to allow broadcast or multicast small amount 295 of data (max 27 bytes). However ULE PP entering into long sleep 296 period cannot receive these packets reliably. Other methods for 297 emulating broadcast/multicast could be considered, such as queuing 298 these packets until a ULE PP wakes up. 300 9. Header Compression 302 Compression Format for IPv6 Datagrams in Low Power and Lossy Networks 303 (6LoWPAN) [I-D.ietf-6lowpan-hc]. 305 In [RFC4944] different types of frame formats and related headers 306 have been defined to support fragmentation and mesh addressing. 308 In ULE context LoWPAN_IPHC compressed IPv6 header would be used by 309 default. Support for fragmentation and mesh headers can be added if 310 required (if not provided by the ULE DLC layer). 312 10. Security Considerations 314 The transmission of speech over DECT will be based on the DSAA2 and 315 DSC2 work being developed by the DF Security group / ETSI TC DECT and 316 the ETSI SAGE Security expert group. However, these security 317 mechanisms may not be fully compatible to the connection-less nature 318 of DECT ULE, hence new mechanisms must be investigated. 320 Additional security such as per-message authentication through CBC- 321 MAC are currently being defined in the ETSI TC-DECT ULE group. It is 322 expected that the DECT ULE DLC layer will implement per-message 323 authentication and encryption to optionally provide security on top 324 of the mandatory and additional security mechanicms defined in ETSI 325 TC-DECT. 327 The underlying algorithm for providing authentication and encryption 328 is based on AES128. Individual key for each ULE PP are generated 329 during the binding procedure. Encryption keys are renewed regularly. 330 DECT ULE does not use any shared encryption key. 332 11. Considerations 334 PP roaming between FP is not considered in this draft. The use of 335 repeater functionality is not considered in this draft 337 12. Acknowledgements 339 13. IANA Considerations 341 14. Security Considerations 343 15. Normative References 345 [ETSI EN300 175 (1-7)] 346 "". 348 [ETSI TS102 827] 349 "". 351 [I-D.ietf-6lowpan-hc] 352 "". 354 [I-D.ietf-6lowpan-nd] 355 "". 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 [RFC4291] "". 362 [RFC4944] "". 364 Authors' Addresses 366 Peter B. Mariager (editor) 367 RTX A/S 369 Email: pm@rtx.dk 370 Jens T. Petersen 371 RTX A/S 373 Email: jtp@rtx.dk