idnits 2.17.1 draft-popa-6lo-6loplc-ipv6-over-ieee19012-networks-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 5 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6282], [RFC4944]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 84: '... to this document MUST implement these...' RFC 2119 keyword, line 143: '...is specification MUST support the 6LOW...' RFC 2119 keyword, line 164: '... RECOMMENDED....' == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4944, updated by this document, for RFC5378 checks: 2005-07-13) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 31, 2014) is 3677 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 4944' is mentioned on line 14, but not defined == Missing Reference: 'RFC 6282' is mentioned on line 15, but not defined Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6lo Working Group D. Popa, Ed. 3 Internet-Draft Itron, Inc. 4 Updates: RFC 4944 and RFC 6282 (if approved) J.H. Hui 5 Intended status: Standards Track Cisco 6 Expires: September 30, 2014 March 31, 2014 8 6LoPLC: Transmission of IPv6 Packets over IEEE 1901.2 Narrowband 9 Powerline Communication Networks 10 draft-popa-6lo-6loplc-ipv6-over-ieee19012-networks-00.txt 12 Abstract 14 This document updates [RFC 4944], "Transmission of IPv6 Packets over 15 IEEE 802.15.4 Networks", and [RFC 6282], "Compression Format for IPv6 16 Datagrams over IEEE 802.15.4-Based Networks", and specifies the 17 6LoPLC technology: the transmission of IPv6 packets over IEEE 1901.2 18 narrowband powerline communication networks. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 30, 2014. 37 Copyright Notice 39 Copyright (c) 2014 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 1. Introduction 53 6LOWPAN technology defines the transport of IPv6 packets over IEEE 54 802.15.4-2006 low power and lossy networks (LLNs). Because the 55 802.15.4-2006 wireless links do not support the IPv6 requirement for 56 a link MTU of at least 1280 octets, 6LOWPAN adaptation layer defines 57 header compression and fragmentation of IPv6 packets. 59 A link in a LLN is characterized as lossy, low-power, low bit-rate, 60 and short range. The LLN nodes have resources constrained in terms 61 of processing power, memory capabilities, and communication 62 bandwidth, due to a combination of factors including regulations on 63 spectrum use, form factor and cost considerations. 65 Recently, IEEE Standard Association published the IEEE 1901.2 PHY and 66 MAC standard for narrowband powerline communications (NB-PLC). When 67 used in LLNs, apart from using powerline communications instead of 68 wireless communications, the devices implementing IEEE 1901.2 69 standard share the same constraints as their wireless counterparts. 71 1.1. Applicability 73 This document updates [RFC4944] and [RFC6282] and specifies 6LoPLC: 74 the transmission of IPv6 packets over IEEE 1901.2 NB-PLC networks. 76 The term 6LoPLC is used to make a clear difference between the 77 6LOWPAN technology, known in the industry as a mechanism to transmit 78 IPv6 packets over 802.15.4-2006 wireless networks, and the use of 79 6LOWPAN technology for the transmission of IPv6 packets over IEEE 80 1901.2 networks. 82 This document specifies a set of behaviors between devices in 1901.2 83 networks, which apply to both mesh and star topologies. An 84 implementation that adheres to this document MUST implement these 85 behaviors. 87 1.2. IEEE 1901.2 Technology 89 This section describes those features from IEEE 1901.2 standard that 90 are relevant to the transmission of IPv6 packets over 1901.2 91 networks. For further details on IEEE 1901.2 technology, the reader 92 is invited to refer to [IEEE1901.2]. 94 IEEE 1901.2 standard defines a Narrowband PLC PHY and MAC technology 95 for indoor and outdoor communications (e.g., smart grid networks, 96 home area networks). 98 IEEE 1901.2 MAC frame format endorses the IEEE 802.15.4-2006 MAC 99 frame format [IEEE802.15.4], with a few exceptions described below. 101 o The IEEE 1901.2 MAC frame format is obtained by prepending a 102 Segment Control Field to the IEEE 802.15.4-2006 MAC frame. One 103 function of the Segment Control Field is to carry inline 104 information for the MAC sub-layer fragmentation and reassembly 105 process. Note that the complete format and use of Segment Control 106 Field are not relevant to the transmission of IPv6 packets over 107 IEEE 1901.2 networks. 109 o IEEE 1901.2 MAC frame format endorses only the IEEE 802.15.4-2006 110 short and extended MAC addresses with a length of 16 and 64 bits, 111 respectively. 113 o IEEE 1901.2 MAC frame format endorses the concept of Information 114 Elements, as defined in IEEE 802.15.4e-2012 [IEEE802.15.4e]. Note 115 that the format and use of Information Elements are not relevant 116 to the transmission of IPv6 packets over IEEE 1901.2 networks. 118 The maximum size of a 1901.2 MAC frame payload is 1280 bytes, while 119 the maximum size of a 1901.2 PHY frame payload is 512 bytes. The PHY 120 frame payload size can vary from frame to frame, as a function of the 121 modulation used to transmit the frame and the strength of the Forward 122 Error Correction scheme. 124 To cope with the mismatch between the size of the PHY frame payload 125 and the size of the MAC frame, the IEEE 1901.2 standard specifies a 126 mandatory MAC sub-layer fragmentation and reassembly process. This 127 process fragments an upper layer datagram into multiple fragments and 128 provides a reliable one-hop transfer of the resulting fragments. 130 2. Transmission of IPv6 Packets over IEEE 1901.2 Networks 132 The transmission of IPv6 packets over low-power and lossy networks 133 relies on two mechanisms defined at 6LOWPAN adaptation layer. The 134 first mechanism defines a set of procedures for IPv6 and UDP header 135 compression (as specified in [RFC4944] and updated in [RFC6282]). 136 The second mechanism defines a scheme for one-hop fragmentation and 137 reassembly of IPv6 packets (as specified in [RFC4944]). 139 2.1. 6LOWPAN Header compression 141 Because IEEE 1901.2 fundamentally supports the IEEE 802.15.4-2006 MAC 142 frame format and addressing scheme, IEEE 1901.2 devices implementing 143 this specification MUST support the 6LOWPAN header compression 144 schemes specified in [RFC6282]. 146 Note that header compression mechanisms defined in [RFC6282] 147 completely replace the header compression mechanisms defined in 148 [RFC4944]. 150 2.2. 6LOWPAN Fragmentation 151 The use of fragmentation and reassembly consumes resources in terms 152 of buffering and processing power. Also, fragmentation and 153 reassembly consumes link capacity because, for each fragment that is 154 transmitted, additional headers are required to properly manage the 155 transmission, retransmission and reassembly of the fragments. As 156 such, in the context of LLNs, where HW resources are constrained and 157 network capacity is scarce, the fragmentation and reassembly should 158 be avoided whenever possible. 160 Because IEEE 1901.2 fundamentally supports a MAC payload of 1280 161 bytes and provides its own MAC sub-layer fragmentation mechanism, the 162 use of 6LOWPAN fragmentation scheme defined in [RFC4944], when 163 transmitting IPv6 packets over IEEE 1901.2 networks, is NOT 164 RECOMMENDED. 166 3. IANA Considerations 168 No IANA considerations. 170 4. Security Considerations 172 This document has no security considerations beyond those in 173 [RFC4291]. 175 5. Acknowledgements 177 The authors would like to acknowledge the review, feedback, and 178 comments of Matthew Gillmore, Samita Chakrabarti, and Ulrich Herberg. 180 6. References 182 6.1. Normative References 184 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 185 Architecture", RFC 4291, February 2006. 187 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J. and D. Culler, 188 "Transmission of IPv6 Packets over IEEE 802.15.4 189 Networks", RFC 4944, September 2007. 191 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 192 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 193 September 2011. 195 6.2. Informative References 197 [IEEE1901.2] 198 IEEE SA , "IEEE Standard for Low-Frequency (less than 500 199 kHz) Narrowband Power Line Communications for Smart Grid 200 Applications", December 2013. 202 [IEEE802.15.4] 203 IEEE SA, "IEEE Standard for Information technology-- Local 204 and metropolitan area networks-- Specific requirements-- 205 Part 15.4: Wireless Medium Access Control (MAC) and 206 Physical Layer (PHY) Specifications for Low Rate Wireless 207 Personal Area Networks (WPANs)", September 2006. 209 [IEEE802.15.4e] 210 IEEE SA , "IEEE Standard for Local and metropolitan area 211 networks--Part 15.4: Low-Rate Wireless Personal Area 212 Networks (LR-WPANs) Amendment 1: MAC sublayer", April 213 2012. 215 Authors' Addresses 217 Daniel Popa, editor 218 Itron, Inc. 219 52, rue Camille Desmoulins 220 Issy les Moulineaux, 92130 221 FR 223 Email: daniel.popa@itron.com 225 Jonathan W. Hui 226 Cisco 227 170 West Tasman Drive 228 San Jose, California 95134 229 USA 231 Phone: +408 424 1547 232 Email: jonhui@cisco.com