idnits 2.17.1 draft-heile-lpwan-wisun-overview-00.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 date (July 3, 2017) is 2486 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 lpwan B. Heile 3 Internet-Draft Wi-SUN Alliance 4 Intended status: Informational B. Liu 5 Expires: January 4, 2018 M. Zhang 6 Huawei Technologies 7 C. Perkins 8 Futurewei 9 July 3, 2017 11 Wi-SUN FAN Overview 12 draft-heile-lpwan-wisun-overview-00 14 Abstract 16 This draft presents an informational overview of the Wi-SUN 17 technology, which gives the principal characteristics of the 18 protocols that have been adopted. The objective is to provide 19 overview information for the IETF LPWAN working group. We also 20 identify relevant characteristics of Wi-SUN that make it suitable for 21 deployment in LPWWANs. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 4, 2018. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Characteristics . . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Topologies . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 5.1. Star Topology . . . . . . . . . . . . . . . . . . . . . . 6 63 5.2. Cluster Tree . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 7. Addressing . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 7.1. Unicast Addressing . . . . . . . . . . . . . . . . . . . 9 67 7.2. Multicast Addressing . . . . . . . . . . . . . . . . . . 9 68 8. Routing . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 8.1. Layer-3 routing: Route-Over . . . . . . . . . . . . . . . 10 70 8.2. L2 routing: Mesh-Under . . . . . . . . . . . . . . . . . 11 71 9. Encapsulation . . . . . . . . . . . . . . . . . . . . . . . . 11 72 9.1. Frame Formats . . . . . . . . . . . . . . . . . . . . . . 11 73 9.2. Information Elements . . . . . . . . . . . . . . . . . . 11 74 10. Wi-SUN Alliance . . . . . . . . . . . . . . . . . . . . . . . 11 75 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 76 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 78 13.1. Normative References . . . . . . . . . . . . . . . . . . 13 79 13.2. Informative References . . . . . . . . . . . . . . . . . 14 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 82 1. Introduction 84 Wi-SUN is a wireless communication technology designed for Utilities, 85 Smart Cities and IoT. Wi-SUN is based on various IEEE, IETF, and 86 ANSI/TIA standards supporting low power and lossy networks. Use 87 cases for Wi-SUN that are relevant for LPWAN may be found in a 88 companion document [draft-wisun-use-cases]. 90 This document provides an overview of the Wi-SUN FAN technology, 91 based on the FAN Technical Profile Specification [FANTPS]. The FAN 92 technical profile is a product of the Wi-SUN Alliance (see 93 Section 10). 95 The remainder of this document describes the Wi-SUN FAN profile in 96 more detail to support the inclusion of Wi-SUN as a technology choice 97 that can beneficially be used in the deployment of low-power, wide- 98 area networks (LPWANs). 100 2. Terminology 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 104 "OPTIONAL" in this document are to be interpreted as described in 105 [RFC2119]. 107 Additionally, this document uses the following terms: 109 Border Router: a node that provides WAN connectivity to the FAN, 110 maintains source routing tables, provides node authentication and key 111 management services, and disseminates PAN wide information. 113 DAO: DODAG Destination Advertisement Object [RFC6550] 115 DIO: DODAG Information Object 117 DIS: DODAG Information Solicitation 119 DODAG: Destination oriented Directed Acyclic Graph 121 IE: Information Element 123 FAN: Field Area Network, containing one or more PANs 125 FFD: A Full-Function Device, which can act as a Border Router, a 126 Router Node, or a Leaf Node. 128 Leaf Node: a node that offers minimum capabilities such as 129 discovering and joining a PAN, sending/receiving IPv6 packets, etc. 131 PAN: Personal Area Network 133 RFD: A Reduced-Function Device. A RFD does not allow other devices 134 to associate, and can only act as Leaf Node. 136 Router Node: a node that provides upward and downward packet 137 forwarding, as well as security and address management protocols 138 relaying. 140 Wi-SUN: Wireless Smart Ubiquitous Network 142 3. Characteristics 144 WiSUN [FANTPS] is an established suite of IoT technologies that is 145 based on IEEE 802.15.4, TCP/IP, and related standard protocols as 146 detailed in the following sections. Important characteristics of 147 WiSUN include the following: 149 Coverage 150 Range measured in kilometers 152 Development Ecosystem 153 WiSUN Alliance with task groups for targeted use cases and assured 154 interoperability (see Section 10) 156 High Bandwidth 157 Up to 300 kbps 159 Low Latency 160 0.02 seconds 162 Mesh Routing 163 Resilient and scalable 165 Power Efficiency 166 less than 2 uA when resting; 8 mA when listening 168 Scalability 169 Networks to 5,000 devices; 10 million endpoints worldwide 171 Security 172 Public key certificates, AES, HMAC, dynamic key refresh, hardened 173 crypto 175 Taken as a whole, these characteristics support consideration of 176 WiSUN protocol solution as an implementation choice for LPWAN. 178 4. Protocol Stack 180 The stack overview of Wi-SUN FAN is illustrated in Figure 1. The PHY 181 layer is based on IEEE 802.15.4g, which provides bi-directional 182 communication with high data rate (up to 300kbps) and low latency. 183 The low power consumption permits a battery-powered FAN device to 184 listen frequently while maintaining a lifetime measured in years. 185 The MAC sub-layer is based on IEEE 802.15.4e along with Wi-SUN 186 defined Information Extensions (IEs). The network layer is IPv6 with 187 6LoWPAN [RFC6282] adaptation. The Wi-SUN FAN supports star and mesh 188 topologies, as well as hybrid star/mesh deployments. Two methods are 189 available for packet routing: RPL [RFC6550] non-storing mode is 190 mandatory at the network layer, and MHDS [ANSITIA-4957.200] is 191 optional at the Logical Link Control (LLC) sub-layer. The transport 192 layer provides both UDP and TCP services. 194 +--------------------------------------+ 195 | Application | 196 +------------+-------------------------+ +---------+ 197 | Transport | UDP/TCP | |Security | 198 +------------+-------------------------+ +---------+ 199 | Network | IPv6/ICMPv6/RPL/6LoWPAN | | 802.1X | 200 +------------+-------------------------+ | EAP-TLS | 201 | | LLC Sub-Layer | | 802.1fi | 202 | | +-------+ | | | 203 | | |L2 MESH| | |+-------+| 204 | Data Link +--------+-------+--------+ || ETSI- || 205 | | MAC Sub-Layer | ||TS-102-|| 206 | | IEEE 802.15.4e | || 887-2 || 207 | | IE extensions | |+-------+| 208 +------------+-------------------------+ +---------+ 209 | PHY | IEEE 802.15.4g | 210 +------------+-------------------------+ 212 Figure 1: Stack Overview 214 A Wi-SUN FAN node can operate in any of the regional frequency bands 215 defined in [PHYSPEC], i.e. 470-510MHz, 779-787MHz and 920.5-924.5MHz 216 in China, 863-870MHz and 870-876MHz in Europe, or 920-928MHz in USA, 217 Canada and Japan. The radio interface is also compliant with local 218 regulations of India, Mexico, Brazil, Australia, New Zealand, Korea, 219 Philippines, Malaysia, Hong Kong, Singapore, Thailand, and Vietnam. 221 The MAC layer supports channel hopping for both unicast and broadcast 222 frame transmission. The total number of channels available is 223 determined by the regional band and the channel spacing. A node can 224 also choose to exclude a set of channels from its hopping sequence. 225 A channel function defines a method used to determine, from the list 226 of available PHY channels, the specific channel upon which a node is 227 operating at a given time [FANTPS]. The resulting hopping schedule 228 is advertised to the neighbors. A variety of channel functions can 229 be implemented, including TR51 [ANSITIA-4957.200], direct hash 230 [FANTPS], fixed channel and vendor defined channel functions. 231 Related information is encapsulated in the unicast/broadcast schedule 232 IE. 234 Wi-SUN FAN's PHY layer supports data rates ranging from 50-300kbps. 235 Wi-SUN devices support low latency (0.02s) and frequent (as often as 236 every 10 seconds) communications. 238 5. Topologies 240 The Wi-SUN FAN can operate in a star topology or a peer-to-peer mesh 241 topology. Either way, the FAN should include at least one FFD which 242 acts as the PAN coordinator. The coordinator is the primary 243 controller of the PAN and is often mains powered. In a star 244 topology, communication is established between the devices and the 245 PAN coordinator. In a peer-to-peer topology, any two devices can 246 communicate with another if they are in the range of other mesh 247 nodes, and multi-hop forwarding is enabled. 249 5.1. Star Topology 251 +-+ 252 |R| C: PAN Coordinator 253 +-+ +-+ +-+ F: FFD 254 |R|**** * ****|F| R: RFD 255 +-+ * * * +-+ 256 * * * 257 +-+ 258 |C| 259 +-+ 260 * * * 261 +-+ * * * +-+ 262 |F|**** * ****|F| 263 +-+ +-+ +-+ 264 |R| 265 +-+ 267 Figure 2: Star topology 269 The topology of a star network is illustrated in Figure 2. When the 270 first FFD is activated, it chooses a PAN identifier that is not used 271 by any other PAN in its range. Then it becomes the coordinator and 272 allows both FFD and RFD to join the star PAN. 274 5.2. Cluster Tree 276 An example peer-to-peer topology is the cluster tree, which can be 277 regarded as a tree of PANs (clusters) as illustrated in Figure 3. In 278 a cluster tree, several of the nodes are FFDs, and one of them 279 operates as the overall coordinator. This coordinator forms the 280 first cluster by choosing an unused PAN identifier and broadcasting 281 beacon frames to discover its neighbors. A candidate device 282 receiving a beacon frame can request to join the network at the PAN 283 coordinator. If the PAN coordinator agrees on this requirement, it 284 adds this new devices as a child in its neighbor list. Once the 285 requirements are met, the first coordinator can appoint FFDs to be 286 coordinators of new clusters which are adjacent to the first cluster. 287 These appointed coordinators may continue to appoint coordinators of 288 their adjacent clusters, until all devices have joined in the cluster 289 tree. 291 +----+ 292 +------------+ ****|PAN4| C: PAN Coordinator 293 |PAN1 |* +----+ F: FFD 294 | +-+* R: RFD 295 | ***|F|| 296 | * +-+* 297 | * |* +----+ 298 | +-+ +-+| ****|PAN3| 299 | |C|*****|R|| +----+ 300 | +-+ +-+| +-----------------+ 301 | * | | +-+ | 302 | * +-+| | |R| | 303 | ***|F|| | *+-+ | 304 | +-+* | * | 305 +------------+* |+-+* | 306 ****||F| | 307 |+-+* +-+| +----+ 308 | * ****|F|*****|PAN5| 309 | *+-+* +-+| +----+ 310 | |F| | 311 | +-+* +-+| 312 | ****|F|| 313 |PAN2 +-+| 314 +-----------------+ 316 Figure 3: Cluster Tree 318 6. Discovery 320 In this section we describe the method by which new Wi-SUN devices 321 may securely discover and join an existing Wi-SUN network. For this 322 purpose Wi-SUN relies on EAP and 802.1x security standards. Trickle 323 timers are used to reduce interference and battery consumption while 324 still maintaining responsive connectivity. 326 A node is at Join State 1 with no information of the PAN when it 327 first is powered up. It MUST transmit PAN Advertisement Solicit 328 (PAS) Frames as triggered by the Advertisement Solicit trickle timer. 329 A received PAN Advertisement (PA) frame is accepted if information 330 carried in the frame matches the factory preset information (e.g. the 331 Network Name and Routing Method). Both PAS and PA are transmitted as 332 cleartext. During the Advertisement Solicit trickle interval, a node 333 may receive several PA frames, and it MUST select the node which 334 advertises the lowest PAN Cost [FANTPS] as its EAPOL (Extensible 335 Authentication Protocol over LAN) target node. 337 After selecting an EAPOL target node, the node is in Join State 2. 338 It MUST perform the 802.1x/802.11i security flow via the selected 339 EAPOL target node, to authenticate itself to the network and obtain 340 its GTKs (group transient keys) from the PAN Border Router. If the 341 authentication succeeds, the node MUST set its PAN ID to be that of 342 the EAPOL target node, and then proceeds to Join State 3. Otherwise 343 the node returns to Join State 1. 345 At Join State 3, a node transmits PAN Configuration Solicit (PCS) 346 frames as triggered by the Configuration Solicit trickle timer. When 347 a PAN configuration (PC) frame is received and decrypted 348 successfully, the node MUST select the source of the PC frame as its 349 initial source of broadcast transmissions. Then the node enters to 350 Join State 4. Otherwise, if a node fails to receive and decrypt a PC 351 frame after several retries, it returns to Join State 1. 353 In Join State 4, the node has been configured with its channel- 354 hopping schedule and active group keys. The node is then a secured 355 member of the PAN. 357 _____________________________________________ 358 | | 359 | | 360 v EAPOL Target | 361 +--------------+ Selected +--------------+ | 362 | Join State 1 |------------------>| Join State 2 | | 363 | | | | | 364 | No PAN |<------------------| Acquire Keys | | 365 +--------------+ EAPOL Fails +--------------+ | 366 | | 367 | | 368 GTKs Acquired | 369 | | 370 | | 371 v | 372 +--------------+ +--------------+ | 373 | Join State 4 | | Join State 3 | | 374 | |<------------------| | | 375 | Secured | RX and Decrypt | PAN Selected | | 376 +--------------+ PAN +--------------+ | 377 Configuration | | 378 |___________| 379 Unsuccessful 380 PAN Configuration 382 Figure 4: FAN Join States 384 7. Addressing 386 The short addressing of 16 bit is not used in Wi-SUN, which means 387 that all the related addressing and header compression mechanisms 388 defined in IEEE 802.15.4 and the 6LoWPAN are not applied. 390 7.1. Unicast Addressing 392 The link local IPv6 address of a FAN node is auto configured 393 according to [RFC4291]. The address combines the well-known link 394 local prefix FE80::0 and the modified EUI-64 Interface Identifier. 395 The node's Global and Unique Local Addresses (GUA and ULA) are 396 managed via DHCPv6 [RFC3315]. 398 7.2. Multicast Addressing 400 For both L2 and L3 routing networks, a FAN node MUST join the all- 401 nodes group (ff02::1) and all-routers group (ff02::2) in link scope 402 [RFC4291]. The realm for IEEE 802.15.4 is defined as all the 403 interfaces which share a common PAN ID [RFC7346]. In realm scope, a 404 FAN node MUST join the all-nodes group (ff03::1) and all-routers 405 group (ff03::2). A FAN node SHOULD subscribe to the unicast-prefix- 406 based IPv6 multicast group [RFC3306] to support MPL [RFC7731]. 408 For L3 routing networks, a FAN node MUST also join the all-nodes 409 group (ff02::1a)[RFC6550] in link scope and the all-mpl-forwarders 410 group (ff03::fc) in realm scope. 412 8. Routing 414 8.1. Layer-3 routing: Route-Over 416 For Layer-3 routing, Wi-SUN FAN adopts the non-storing mode of RPL 417 [RFC6550]. RPL requires the construction and maintenance of DODAGs. 418 A DODAG rooted at the Border Router is called a "grounded DODAG". 419 After a link failure, some nodes may lose connection to the Border 420 Router; then they can form a "floating DODAG". A node's rank is 421 defined by its relative position to the root; the rank strictly 422 increases after every link from the root to the leaves. 424 To build a DODAG, the Border Router multicasts a DIO message to its 425 immediate neighbors. Each neighbor decides whether or not to join 426 the DODAG or not cccording to the objective function and other 427 criteria. If so, the Border Router is noted as their parent. Each 428 node in the DODAG sets trickle timers [RFC6206] for DIO message 429 transmission. Upon receiving a DIO, if the node is the Border Router 430 or the source node has a higher rank, the message is ignored; if not, 431 in case that the node decides to join in this DODAG, the source of 432 the DIO can be included in the node's DODAG parent set; the node that 433 has the best objective function value is marked as the most preferred 434 parent, which provides the default upward route from the child node. 435 Thus the upward packets can be routed hop-by-hop to the root. A 436 neighbor can send a DIS message to solicit the transmission of a DIO 437 message. 439 According to the non-storing mode of RPL, downward packets are routed 440 using source routing from the root. Each node, except the Border 441 Router, sends DAO messages to the Border Router indicating its route 442 to its DODAG parents. When the Border Router receives DAO messages 443 from all node, it scan construct source routes to any node in the 444 DODAG. 446 For communication between two peers, in the non-storing mode, the 447 packet goes up to the Border Router at first then sent to the 448 destination node via source routing [RFC6997]. 450 When a link failure happens (e.g. by temporary obstruction), if a 451 node has no alternative parent it becomes the root of a floating 452 DODAG and sends DIO to its neighbors to advertise this change. Each 453 child node switches to an alternative parents if possible, but 454 otherwise stays in the floating DODAG. When receiving the DIO 455 messages from the nodes in the grounded DODAG, a node in the floating 456 DODAG tries to find a new preferred DODAG parent. Once the 457 connection is recovered at this node, the other nodes in the floating 458 DODAG can join the grounded DODAG through this new link. The 459 topology of the floating DODAG might be changed during this local 460 redirection process. 462 8.2. L2 routing: Mesh-Under 464 Mesh-under L2 routing is based on MHDS, as defined in 465 [ANSITIA-4957.210]. 467 9. Encapsulation 469 The Wi-SUN MAC MTU is 2047 bytes as defined in IEEE802.15.4g, 470 satisfying the IPv6 packet length requirement. The header 471 compression and fragmentation in 6LoWPAN [RFC6282] can be applied. 472 Besides 6LoWPAN fragmentation, Wi-SUN FAN supports an optional L2 473 fragmentation. 475 9.1. Frame Formats 477 Wi-SUN FAN defines 7 frame formats, including PAN Advertisement 478 frame, PAN Advertisement Solicit frame, PAN Configuration frame, PAN 479 Configuration Solicit frame, Upper Layer Application Data frame, 480 Acknowledgment frame and EAPOL frame. Detailed information can be 481 found in [FANTPS]. 483 9.2. Information Elements 485 Wi-SUN FAN defines its own Information Elements (IEs) to support 486 certain operations. Depending on where the MAC management 487 information is encapsulated, IEs defined in Wi-SUN can be divided 488 into two categories: Wi-SUN header IEs, and Wi-SUN payload IEs. A 489 payload IE can be longer than a header IE, and can be encrypted as a 490 part of the payload. Wi-SUN FAN also adopts the MP-IE defined in 491 IEEE802.15.9 to carry the MAC payload. 493 Detailed definitions and the inclusion relation of the IEs for Wi-SUN 494 frame types can be found in [FANTPS]. 496 10. Wi-SUN Alliance 498 The Wi-SUN Alliance consists of more than 130 member companies 499 including product vendors, silicon vendors, software companies, 500 utilities, government institutions and universities. Each member 501 company contributes to the Wi-SUN ecosystem as the Wi-SUN Alliance 502 has defined testing and certification programs for multi-vendor 503 interoperability. Wi-SUN networks have been deployed for more than 504 10 years in mixed-vendor environments, demonstrating ongoing 505 commitments from a wide variety of organizations. 507 The mission of the Wi-SUN Alliance is to advance seamless 508 connectivity by promoting IEEE 802.15.4g standard-based 509 interoperability for regional markets worldwide. Key activities of 510 the Wi-SUN Alliance include the following: 512 Promotion of wireless Smart Ubiquitous Networks and related 513 applications as defined by international and regional standards 514 development organizations. 516 Advancement of wireless Smart Ubiquitous Networks worldwide 518 Interoperability and compliance certification programs. 520 User education 522 Industry outreach and other support programs 524 Lobbying regional regulatory bodies for spectrum allocation to be 525 used in the support of smart grid services 527 Provide a forum for global collaboration to achieve Smart City and 528 Smart Ubiquitous Communications Network Interoperability 530 In January 2015, the Wi-SUN Alliance released its "Technical Profile 531 Specification for IEEE 802.15.4g Standard-Based Field Area Networks" 532 (FANs) [FANTPS]. That specification integrates: 534 A 802.15.4g physical layer compatible with the existing Wi-SUN 535 Alliance PHY Certification Program 537 Frequency hopping, network discovery/join and protocol dispatch 539 The IPv6 protocol suite, including 6LoWPAN, address management, 540 routing using RPL, unicast and multicast forwarding 542 A standards-based multi-layer security specification encompassing 543 authentication, authorization, encryption. 545 11. Security Considerations 547 FAN access control is based on IEEE802.1x and EAP-TLS [RFC5216]. If 548 the supplicant is not able to reach the Authenticator directly, the 549 EAPOL Datagram can be forwarded by multiple routing nodes. FAN nodes 550 also support Node Pairwise (N2NP) Authentication [ETSI-TS-102-887-2] 551 between one-hop neighbors in the mesh. 553 FAN nodes MUST implement Frame Security policy based on AES-CCM* as 554 defined in IEEE802.15.4. The derivation of the Group AES Key and 555 Pairwise AES Key is described in [FANTPS]. A node MUST maintain a 556 frame counter for each GTK. The frame counter is set to 0 initially, 557 and increases with each transmission using this GTK. It is 558 recommended to replace a GTK which has been used for 30 days. 560 12. IANA Considerations 562 IANA need not assign anything for this document. RFC editor: please 563 remove this section before publication. 565 13. References 567 13.1. Normative References 569 [ANSITIA-4957.210] 570 ANSI, "Multi-Hop Delivery Specification of a Data Link 571 Sub-Layer", February 2013. 573 [draft-wisun-use-cases] 574 Liu, B., Zhang, M., and C. Perkins, "WiSUN use cases", 575 July 2017. 577 [FANTPS] Wi-SUN Alliance, "Technical Profile Specification Field 578 Area Network", May 2016. 580 [PHYSPEC] Wi-SUN Alliance, "Wi-SUN PHY Specification V1.0", March 581 2016. 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, 585 DOI 10.17487/RFC2119, March 1997, 586 . 588 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 589 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 590 DOI 10.17487/RFC6282, September 2011, 591 . 593 [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., 594 Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, 595 JP., and R. Alexander, "RPL: IPv6 Routing Protocol for 596 Low-Power and Lossy Networks", RFC 6550, 597 DOI 10.17487/RFC6550, March 2012, 598 . 600 13.2. Informative References 602 [ANSITIA-4957.200] 603 ANSI, "Layer 2 Standard Specification for the Smart 604 Utility Network", January 2013. 606 [ETSI-TS-102-887-2] 607 ETSI, "Smart Metering Wireless Access Protocol; Part 2: 608 Data Link Layer (MAC Sub-layer)", September 2013. 610 [RFC3306] Haberman, B. and D. Thaler, "Unicast-Prefix-based IPv6 611 Multicast Addresses", RFC 3306, DOI 10.17487/RFC3306, 612 August 2002, . 614 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 615 C., and M. Carney, "Dynamic Host Configuration Protocol 616 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 617 2003, . 619 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 620 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 621 2006, . 623 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 624 Authentication Protocol", RFC 5216, DOI 10.17487/RFC5216, 625 March 2008, . 627 [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, 628 "The Trickle Algorithm", RFC 6206, DOI 10.17487/RFC6206, 629 March 2011, . 631 [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and 632 J. Martocci, "Reactive Discovery of Point-to-Point Routes 633 in Low-Power and Lossy Networks", RFC 6997, 634 DOI 10.17487/RFC6997, August 2013, 635 . 637 [RFC7346] Droms, R., "IPv6 Multicast Address Scopes", RFC 7346, 638 DOI 10.17487/RFC7346, August 2014, 639 . 641 [RFC7731] Hui, J. and R. Kelsey, "Multicast Protocol for Low-Power 642 and Lossy Networks (MPL)", RFC 7731, DOI 10.17487/RFC7731, 643 February 2016, . 645 Authors' Addresses 647 Bob Heile 648 Wi-SUN Alliance 649 11 Robert Toner Blvd, Suite 5-301 650 North Attleboro MA 02763 651 USA 653 Email: bheile@ieee.org 655 Bing Liu (Remy) 656 Huawei Technologies 657 No. 156 Beiqing Rd. Haidian District 658 Beijing 100095 659 China 661 Email: remy.liubing@huawei.com 663 Mingui Zhang 664 Huawei Technologies 665 No. 156 Beiqing Rd. Haidian District 666 Beijing 100095 667 China 669 Email: zhangmingui@huawei.com 671 Charles E. Perkins 672 Futurewei 673 2330 Central Expressway 674 Santa Clara 95050 675 United States 677 Email: charliep@computer.org