当前位置：文档库 › draft-bormann-6lowpan-roadmap-00

draft-bormann-6lowpan-roadmap-00

6LoWPAN Working Group C. Bormann Internet-Draft Universitaet Bremen TZI Intended status: Informational March 7, 2011 Expires: September 8, 2011

6LoWPAN Roadmap and Implementation Guide

Abstract

6LoWPAN is defined in RFC 4944 in conjunction with a number of

specifications that are currently nearing completion. The entirety

of these specifications may be hard to understand, pose specific

implementation problems, or be simply inconsistent.

The present guide aims to provide a roadmap to these documents as

well as provide specific advice how to use these specifications in

combination. In certain cases, it may provide clarifications or even corrections to the specifications referenced.

This guide is intended as a continued work-in-progress, i.e. a long- lived Internet-Draft, to be updated whenever new information becomes available and new consensus on how to handle issues is formed.

Similar to the ROHC implementation guide, RFC 4815, it might be

published as an RFC at some future time later in the acceptance curve of the specifications.

This document does not describe a new protocol or attempts to set a

new standard of any kind -- it mostly describes good practice in

using the existing specifications, but it may also document emerging consensus where a correction needs to be made.

The current version -00 of this document is just an initial draft

that is intended to spark the collection of relevant information. Status of this Memo

This Internet-Draft is submitted in full conformance with the

provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering

Task Force (IETF). Note that other groups may also distribute

working documents as Internet-Drafts. The list of current Internet- Drafts is at https://www.wendangku.net/doc/a717441706.html,/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any Bormann Expires September 8, 2011 [Page 1]

Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2011 time. It is inappropriate to use Internet-Drafts as reference

material or to cite them other than as "work in progress."

This Internet-Draft will expire on September 8, 2011.

This document is subject to BCP 78 and the IETF Trust’s Legal

Provisions Relating to IETF Documents

(https://www.wendangku.net/doc/a717441706.html,/license-info) in effect on the date of

publication of this document. Please review these documents

carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of

the Trust Legal Provisions and are provided without warranty as

described in the Simplified BSD License.

Bormann Expires September 8, 2011 [Page 2]

Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2011 Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4

2. 6LoWPAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3. 6LoWPAN MTU . . . . . . . . . . . . . . . . . . . . . . . . . 6

4. PAN identifiers in IPv6 addresses . . . . . . . . . . . . . . 7

5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8

6. Security Considerations . . . . . . . . . . . . . . . . . . . 9

7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10

8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author’s Address . . . . . . . . . . . . . . . . . . . . . . . . . 12 Bormann Expires September 8, 2011 [Page 3]

Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2011 1. Introduction

(To be written - for now please read the Abstract.)

1.1. Terminology

This document is a guide. However, it might evolve to make specific recommendations on how to use standards-track specification.

Therefore: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",

"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and

"OPTIONAL" in this document are to be interpreted as described in RFC 2119. They indicate requirement levels for compliant 6LoWPAN

implementations [RFC2119]. Note that these keywords are not only

used where a correction or clarification is intended; the latter are explicitly identified as such.

The term "byte" is used in its now customary sense as a synonym for

"octet".

Bormann Expires September 8, 2011 [Page 4]

Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2011 2. 6LoWPAN

What is a 6LoWPAN?

The term, originally just the name of the IETF WG that created the

specifications, nowadays refers to a specific way of building IP-

connected wireless networks for embedded use cases. The 6LoWPAN core specifications are:

o [RFC4944], as updated by

o [I-D.ietf-6lowpan-hc] and

o [I-D.ietf-6lowpan-nd].

While [RFC4944] defines 6LoWPAN specifically for IEEE 802.15.4

networks, 6LoWPAN concepts have been applied to other PHY/MAC layers. 6LoWPANs MAY use additional protocols, such as [I-D.ietf-roll-rpl]

for routing, or [I-D.ietf-core-coap] for application data transfer.

However, the "6LoWPANness" of a network is caused by adherence to the core specifications.

Bormann Expires September 8, 2011 [Page 5]

Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2011 3. 6LoWPAN MTU

IPv6 defines a minimal value for the "Minimum Transmission Unit",

MTU, of 1280 bytes. This means that every IPv6 network must be able to transfer a packet of at least 1280 bytes of IPv6 headers and data without requiring fragmentation.

A common Internet MTU is 1500 bytes (motivated by the Ethernet MTU). The gap between 1280 and 1500 allows tunneling protocols to insert

headers on the way from the source of a packet to a destination

without breaking the overall MTU of the path. As various tunneling

protocols do indeed insert bytes, it is unwise to simply assume an

end-to-end MTU of 1500 bytes even with the current dominance of

Ethernet. Path MTU discovery [RFC1981] [RFC4821] has been defined to enable transport protocols to find an MTU value better than 1280

bytes, but still reliably within the MTU of the path being used.

Path MTU discovery places, however, additional strain on constrained nodes, which therefore may want to stick with an MTU of 1280 bytes

for all IPv6 applications.

6LoWPAN was designed as a stub network, not requiring any tunneling. As IEEE 802.15.4 packets are rather small (127 bytes maximum at the

physical layer, minus MAC/security and adaptation layer overhead),

1280 bytes was already considered a somewhat large packet size.

Therefore, the 6LoWPAN network MTU was simply set at the minimum size allowable by IPv6, 1280 bytes, although the 6LoWPAN fragmentation

mechanism is able to support packets with total lengths (including

the initial IPv6 header) of up to 2047 bytes.

As a more recent development, some modes of operation of the RPL

protocol [I-D.ietf-roll-rpl] do indeed operate by tunneling data

packets between RPL routers. Maintaining the MTU visible to

applications at 1280 therefore requires making a larger MTU available to the tunnels.

6LoWPAN routers that employ RPL therefore MUST support a more

appropriate MTU between routers that make use of tunneling between

them. [The specific MTU value is TBD, to be chosen between 1280 and 2047 based on RPL considerations that need to be added to this

document.]

Bormann Expires September 8, 2011 [Page 6]

Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2011 4. PAN identifiers in IPv6 addresses

[RFC4944] incorporates PAN identifiers in IPv6 addresses created from 16-bit MAC addresses, in a somewhat awkward way (one of the 16 bits

needs to be cleared to enable the U/L bit.).

As the use of PAN identifiers in 6LoWPAN networks has since become

less and less meaningful, [I-D.ietf-6lowpan-hc] provides specific

support only for interface IDs of the form 0000:00ff:fe00:XXXX, i.e. PAN identifiers of zero. (Other forms can be supported by creating

sufficiently long pieces of compression context information for each non-zero PAN identifier; however there is a limited number of context elements and each consumes space in all nodes of a 6LoWPAN.)

It is therefore RECOMMENDED to employ a PAN identifier of zero with

6LoWPAN.

Bormann Expires September 8, 2011 [Page 7]

Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2011 5. IANA Considerations

This document has no actions for IANA.

Bormann Expires September 8, 2011 [Page 8]

Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2011 6. Security Considerations

(None so far; this section will certainly grow as additional security considerations beyond those listed in the base specifications become known.)

Bormann Expires September 8, 2011 [Page 9]

Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2011 7. Acknowledgements

(The concept for this document is borrowed from [RFC4815], which was invented by Lars-Erik Jonsson. Thanks!)

Bormann Expires September 8, 2011 [Page 10]

Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2011 8. References

8.1. Normative References

[I-D.ietf-6lowpan-hc]

Hui, J. and P. Thubert, "Compression Format for IPv6

Datagrams in Low Power and Lossy Networks (6LoWPAN)",

draft-ietf-6lowpan-hc-15 (work in progress),

February 2011.

[I-D.ietf-6lowpan-nd]

Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor

Discovery Optimization for Low-power and Lossy Networks", draft-ietf-6lowpan-nd-15 (work in progress),

December 2010.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate

Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,

"Transmission of IPv6 Packets over IEEE 802.15.4

Networks", RFC 4944, September 2007.

8.2. Informative References

[I-D.ietf-core-coap]

Shelby, Z., Hartke, K., Bormann, C., and B. Frank,

"Constrained Application Protocol (CoAP)",

draft-ietf-core-coap-04 (work in progress), January 2011. [I-D.ietf-roll-rpl]

Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J.

Vasseur, "RPL: IPv6 Routing Protocol for Low power and

Lossy Networks", draft-ietf-roll-rpl-18 (work in

progress), February 2011.

[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.

[RFC4815] Jonsson, L-E., Sandlund, K., Pelletier, G., and P. Kremer, "RObust Header Compression (ROHC): Corrections and

Clarifications to RFC 3095", RFC 4815, February 2007.

[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU

Discovery", RFC 4821, March 2007.

Bormann Expires September 8, 2011 [Page 11]

Internet-Draft 6LoWPAN Roadmap and Implementation Guide March 2011 Author’s Address

Carsten Bormann

Universitaet Bremen TZI

Postfach 330440

Bremen D-28359

Germany

Phone: +49-421-218-63921

Fax: +49-421-218-7000

Email: cabo@https://www.wendangku.net/doc/a717441706.html,

Bormann Expires September 8, 2011 [Page 12]