< draft-ietf-6lo-blemesh-00.txt   draft-ietf-6lo-blemesh-01.txt >
6Lo Working Group C. Gomez 6Lo Working Group C. Gomez
Internet-Draft S. Darroudi Internet-Draft S. Darroudi
Intended status: Standards Track UPC/i2cat Intended status: Standards Track UPC/i2cat
Expires: May 17, 2017 T. Savolainen Expires: September 12, 2017 T. Savolainen
Nokia Nokia
November 13, 2016 March 11, 2017
IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP
draft-ietf-6lo-blemesh-00 draft-ietf-6lo-blemesh-01
Abstract Abstract
RFC 7668 describes the adaptation of 6LoWPAN techniques to enable RFC 7668 describes the adaptation of 6LoWPAN techniques to enable
IPv6 over Bluetooth low energy networks that follow the star IPv6 over Bluetooth low energy networks that follow the star
topology. However, recent Bluetooth specifications allow the topology. However, recent Bluetooth specifications allow the
formation of extended topologies as well. This document specifies formation of extended topologies as well. This document specifies
the mechanisms needed to enable IPv6 over mesh networks composed of the mechanisms needed to enable IPv6 over mesh networks composed of
Bluetooth low energy links established by using the Bluetooth Bluetooth low energy links established by using the Bluetooth
Internet Protocol Support Profile. Internet Protocol Support Profile.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 17, 2017. This Internet-Draft will expire on September 12, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 4, line 9 skipping to change at page 4, line 9
vice versa, if a link layer connection has been established between vice versa, if a link layer connection has been established between
both by using the IPSP functionality for discovery and link layer both by using the IPSP functionality for discovery and link layer
connection establishment for IPv6 packet transport. connection establishment for IPv6 packet transport.
3. Specification of IPv6 mesh over Bluetooth LE networks 3. Specification of IPv6 mesh over Bluetooth LE networks
3.1. Protocol stack 3.1. Protocol stack
Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth Figure 1 illustrates the protocol stack for IPv6 mesh over Bluetooth
LE networks. There are two main differences with the IPv6 over LE networks. There are two main differences with the IPv6 over
Bluetooth LE stack in RFC 7668: a) the adaptation layer below IPv6 Bluetooth LE stack in RFC 7668: a) the adaptation layer below IPv6
(labelled as "6Lo for mesh of Bluetooth LE") is now adapted for mesh (labelled as "6Lo for IPv6 mesh of Bluetooth LE") is now adapted for
networks of Bluetooth LE links, and b) the protocol stack for IPv6 mesh networks of Bluetooth LE links, and b) the protocol stack for
mesh networks of Bluetooth LE links includes IPv6 routing IPv6 mesh networks of Bluetooth LE links includes IPv6 routing
functionality. functionality.
+------------------------------------+ +------------------------------------+
| Application | | Application |
+---------+ +------------------------------------+ +---------+ +------------------------------------+
| IPSS | | UDP/TCP/other | | IPSS | | UDP/TCP/other |
+---------+ +------------------------------------+ +---------+ +------------------------------------+
| GATT | | IPv6 |routing| | | GATT | | IPv6 |routing| |
+---------+ +------------------------------------+ +---------+ +------------------------------------+
| ATT | | 6Lo for IPv6 mesh over Bluetooh LE | | ATT | | 6Lo for IPv6 mesh over Bluetooh LE |
skipping to change at page 6, line 6 skipping to change at page 6, line 6
'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless 'Neighbor Discovery Optimization for IPv6 over Low-Power Wireless
Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor Personal Area Networks (6LoWPANs)' [RFC6775] describes the neighbor
discovery approach as adapted for use in several 6LoWPAN topologies, discovery approach as adapted for use in several 6LoWPAN topologies,
including the mesh topology. The route-over functionality of RFC including the mesh topology. The route-over functionality of RFC
6775 MUST be supported. 6775 MUST be supported.
The following aspects of the Neighbor Discovery optimizations The following aspects of the Neighbor Discovery optimizations
[RFC6775] are applicable to Bluetooth LE 6LNs: [RFC6775] are applicable to Bluetooth LE 6LNs:
1. A Bluetooth LE 6LN MUST NOT register its link-local address. A 1. A Bluetooth LE 6LN MUST NOT register its link-local address. A
Bluetooth LE 6LN MUST register its non-link-local addresses with its Bluetooth LE host MUST register its non-link-local addresses with its
routers by sending a Neighbor Solicitation (NS) message with the routers by sending a Neighbor Solicitation (NS) message with the
Address Registration Option (ARO) and process the Neighbor Address Registration Option (ARO) and process the Neighbor
Advertisement (NA) accordingly. The NS with the ARO option MUST be Advertisement (NA) accordingly. The NS with the ARO option MUST be
sent irrespective of the method used to generate the IID. The ARO sent irrespective of the method used to generate the IID. The ARO
option requires use of an EUI-64 identifier [RFC6775]. In the case option requires use of an EUI-64 identifier [RFC6775]. In the case
of Bluetooth LE, the field SHALL be filled with the 48-bit device of Bluetooth LE, the field SHALL be filled with the 48-bit device
address used by the Bluetooth LE node converted into 64-bit Modified address used by the Bluetooth LE node converted into 64-bit Modified
EUI-64 format [RFC4291]. EUI-64 format [RFC4291].
If the 6LN registers for a same compression context multiple If the 6LN registers for a same compression context multiple
addresses that are not based on Bluetooth device address, the header addresses that are not based on Bluetooth device address, the header
compression efficiency will decrease. compression efficiency will decrease.
2. For sending Router Solicitations and processing Router 2. For sending Router Solicitations and processing Router
Advertisements the Bluetooth LE 6LNs MUST, respectively, follow Advertisements the Bluetooth LE hosts MUST, respectively, follow
Sections 5.3 and 5.4 of the [RFC6775]. Sections 5.3 and 5.4 of the [RFC6775].
3. The router behavior for 6LRs and 6LBRs is described in Section 6 3. The router behavior for 6LRs and 6LBRs is described in Section 6
of RFC 6775. However, as per this specification, routers SHALL NOT of RFC 6775. However, as per this specification, routers SHALL NOT
use multicast NSs to discover other routers' link layer addresses. use multicast NSs to discover other routers' link layer addresses.
4. Border router behavior is described in Section 7 of RFC 6775. 4. Border router behavior is described in Section 7 of RFC 6775.
RFC 6775 defines substitutable mechanisms for distributing prefixes RFC 6775 defines substitutable mechanisms for distributing prefixes
and context information (section 8.1 of RFC 6775), as well as for and context information (section 8.1 of RFC 6775), as well as for
skipping to change at page 7, line 11 skipping to change at page 7, line 11
[RFC6775] matching each address prefix advertised via a Prefix [RFC6775] matching each address prefix advertised via a Prefix
Information Option (PIO) [RFC4861] for use in stateless address Information Option (PIO) [RFC4861] for use in stateless address
autoconfiguration. autoconfiguration.
The specific optimizations of RFC 7668 for header compression, which The specific optimizations of RFC 7668 for header compression, which
exploit the star topology and ARO, cannot be generalized in a mesh exploit the star topology and ARO, cannot be generalized in a mesh
network composed of Bluetooth LE links. Still, a subset of those network composed of Bluetooth LE links. Still, a subset of those
optimizations can be applied in some cases in such a network. In optimizations can be applied in some cases in such a network. In
particular, the latter comprise link-local interactions, non-link- particular, the latter comprise link-local interactions, non-link-
local packet transmissions originated and performed by a 6LN, and local packet transmissions originated and performed by a 6LN, and
non-link-local packet transmissions originated by a 6LN neighbor and non-link-local packets transmitted (but not necessarily originated)
sent to a 6LN. For the rest of packet transmissions, context-based by the neighbor of a 6LN to that 6LN. For the rest of packet
compression MAY be used. transmissions, context-based compression MAY be used.
When a device transmits a packet to a neighbor, the sender MUST fully When a device transmits a packet to a neighbor, the sender MUST fully
elide the source IID if the source IPv6 address is the link-local elide the source IID if the source IPv6 address is the link-local
address based on the sender's Bluetooth device address (SAC=0, address based on the sender's Bluetooth device address (SAC=0,
SAM=11). The sender also MUST fully elide the destination IPv6 SAM=11). The sender also MUST fully elide the destination IPv6
address if it is the link-local-address based on the neighbor's address if it is the link-local-address based on the neighbor's
Bluetooth device address (DAC=0, DAM=11). Bluetooth device address (DAC=0, DAM=11).
When a 6LN transmits a packet, with a non-link-local source address When a 6LN transmits a packet, with a non-link-local source address
that the 6LN has registered with ARO in the next-hop router for the that the 6LN has registered with ARO in the next-hop router for the
 End of changes. 9 change blocks. 
13 lines changed or deleted 13 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/