draft-ietf-roll-applicability-home-building-05.txt   draft-ietf-roll-applicability-home-building-06.txt 
Roll A. Brandt Roll A. Brandt
Internet-Draft Sigma Designs Internet-Draft Sigma Designs
Intended status: Informational E. Baccelli Intended status: Informational E. Baccelli
Expires: April 9, 2015 INRIA Expires: June 4, 2015 INRIA
R. Cragie R. Cragie
ARM ARM
P. van der Stok P. van der Stok
Consultant Consultant
October 6, 2014 December 01, 2014
Applicability Statement: The use of the RPL protocol suite in Home Applicability Statement: The use of the RPL protocol suite in Home
Automation and Building Control Automation and Building Control
draft-ietf-roll-applicability-home-building-05 draft-ietf-roll-applicability-home-building-06
Abstract Abstract
The purpose of this document is to provide guidance in the selection The purpose of this document is to provide guidance in the selection
and use of protocols from the RPL protocol suite to implement the and use of protocols from the RPL protocol suite to implement the
features required for control in building and home environments. features required for control in building and home environments.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
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 April 9, 2015. This Internet-Draft will expire on June 4, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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
skipping to change at page 2, line 41 skipping to change at page 2, line 41
4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 13 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . 13
4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 13 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 13
4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . 13 4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . 13
4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . 13 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . 13
4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . 14 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . 14
4.1.5. Objective Function . . . . . . . . . . . . . . . . . 14 4.1.5. Objective Function . . . . . . . . . . . . . . . . . 14
4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . 14 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . 14
4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 14 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 14
4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 15 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . 15
4.1.9. P2P communications . . . . . . . . . . . . . . . . . 15 4.1.9. P2P communications . . . . . . . . . . . . . . . . . 15
4.1.10. IPv6 address configuration . . . . . . . . . . . . . 15 4.1.10. IPv6 address configuration . . . . . . . . . . . . . 16
4.2. Layer 2 features . . . . . . . . . . . . . . . . . . . . 15 4.2. Layer 2 features . . . . . . . . . . . . . . . . . . . . 16
4.2.1. Specifics about layer-2 . . . . . . . . . . . . . . . 16 4.2.1. Specifics about layer-2 . . . . . . . . . . . . . . . 16
4.2.2. Services provided at layer-2 . . . . . . . . . . . . 16 4.2.2. Services provided at layer-2 . . . . . . . . . . . . 16
4.2.3. 6LowPAN options assumed . . . . . . . . . . . . . . . 16 4.2.3. 6LowPAN options assumed . . . . . . . . . . . . . . . 16
4.2.4. MLE and other things . . . . . . . . . . . . . . . . 16 4.2.4. MLE and other things . . . . . . . . . . . . . . . . 16
4.3. Recommended Configuration Defaults and Ranges . . . . . . 16 4.3. Recommended Configuration Defaults and Ranges . . . . . . 16
4.3.1. Trickle parameters . . . . . . . . . . . . . . . . . 16 4.3.1. Trickle parameters . . . . . . . . . . . . . . . . . 16
4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . 16 4.3.2. Other Parameters . . . . . . . . . . . . . . . . . . 17
5. MPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 17 5. MPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Recommended configuration Defaults and Ranges . . . . . . 17 5.1. Recommended configuration Defaults and Ranges . . . . . . 17
5.1.1. Real-Time optimizations . . . . . . . . . . . . . . . 17 5.1.1. Real-Time optimizations . . . . . . . . . . . . . . . 17
5.1.2. Trickle parameters . . . . . . . . . . . . . . . . . 17 5.1.2. Trickle parameters . . . . . . . . . . . . . . . . . 18
5.1.3. Other parameters . . . . . . . . . . . . . . . . . . 18 5.1.3. Other parameters . . . . . . . . . . . . . . . . . . 19
6. Manageability Considerations . . . . . . . . . . . . . . . . 18 6. Manageability Considerations . . . . . . . . . . . . . . . . 19
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7.1. Security considerations during initial deployment . . . . 19 7.1. Security considerations during initial deployment . . . . 20
7.2. Security Considerations during incremental deployment . . 20 7.2. Security Considerations during incremental deployment . . 21
7.3. Security Considerations for P2P uses . . . . . . . . . . 20 7.3. Security Considerations for P2P uses . . . . . . . . . . 21
7.4. MPL routing . . . . . . . . . . . . . . . . . . . . . . . 20 7.4. MPL routing . . . . . . . . . . . . . . . . . . . . . . . 21
7.5. RPL Security features . . . . . . . . . . . . . . . . . . 20 7.5. RPL Security features . . . . . . . . . . . . . . . . . . 21
8. Other related protocols . . . . . . . . . . . . . . . . . . . 21 8. Other related protocols . . . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 24
12.1. Normative References . . . . . . . . . . . . . . . . . . 23 12.1. Normative References . . . . . . . . . . . . . . . . . . 24
12.2. Informative References . . . . . . . . . . . . . . . . . 25 12.2. Informative References . . . . . . . . . . . . . . . . . 26
Appendix A. RPL shortcomings in home and building deployments . 26 Appendix A. RPL shortcomings in home and building deployments . 27
A.1. Risk of undesired long P2P routes . . . . . . . . . . . . 26 A.1. Risk of undesired long P2P routes . . . . . . . . . . . . 27
A.1.1. Traffic concentration at the root . . . . . . . . . . 27 A.1.1. Traffic concentration at the root . . . . . . . . . . 28
A.1.2. Excessive battery consumption in source nodes . . . . 27 A.1.2. Excessive battery consumption in source nodes . . . . 28
A.2. Risk of delayed route repair . . . . . . . . . . . . . . 27 A.2. Risk of delayed route repair . . . . . . . . . . . . . . 28
A.2.1. Broken service . . . . . . . . . . . . . . . . . . . 27 A.2.1. Broken service . . . . . . . . . . . . . . . . . . . 28
Appendix B. Communication failures . . . . . . . . . . . . . . . 28 Appendix B. Communication failures . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The primary purpose of this document is to give guidance in the use The primary purpose of this document is to give guidance in the use
of the RPL protocol suite in two application domains: of the RPL protocol suite in two application domains:
o Home automation o Home automation
o Building automation o Building automation
skipping to change at page 13, line 50 skipping to change at page 13, line 50
node can be designed to join multiple RPL instances. node can be designed to join multiple RPL instances.
4.1.2. Storing vs. Non-Storing Mode 4.1.2. Storing vs. Non-Storing Mode
Non-storing mode is necessary to cope with the extremely constrained Non-storing mode is necessary to cope with the extremely constrained
memory of a majority of nodes in the network (such as individual memory of a majority of nodes in the network (such as individual
light switches). light switches).
4.1.3. DAO Policy 4.1.3. DAO Policy
A node can be designed to join multiple RPL instances; in that case Nodes send DAO messages to establish downward paths from the root to
DAO policies may be needed. However, DAO policy is out of scope for themselves. DAO messages are not acknowledged in networks composed
this applicability statement. of battery operated field devices in order to minimize the power
consumption overhead associated with path discovery. The DAO
messages build up a source route because the nodes are recommended to
be in non-storing mode.
If devices in LLNs participate in multiple RPL instances and DODAGs,
it is highly recommended that both the RPLInstance ID and the DODAGID
be included in the DAO.
4.1.4. Path Metrics 4.1.4. Path Metrics
OF0 is the recommended metric. [RFC6551] provides other options. ETX is the recommended metric. [RFC6551] provides other options.
Using other objective functions than OF0 may affect inter-
operability. It is recommended that packets from asymmetric and/or unstable
channels are deleted at layer 2.
4.1.5. Objective Function 4.1.5. Objective Function
OF0 is the recommended Objective Function. Other Objective Functions OF0 is the recommended Objective Function. Other Objective Functions
should be used only when dictated by circumstances. should be used only when dictated by circumstances.
4.1.6. DODAG Repair 4.1.6. DODAG Repair
Since P2P-RPL only creates DODAGs on a temporary basis during route Since P2P-RPL only creates DODAGs on a temporary basis during route
repair or route discovery, there is no need to repair DODAGs. repair or route discovery, there is no need to repair DODAGs.
skipping to change at page 16, line 38 skipping to change at page 16, line 48
Trickle is used to distribute network parameter values to all nodes Trickle is used to distribute network parameter values to all nodes
without stringent time restrictions. The recommended Trickle without stringent time restrictions. The recommended Trickle
parameter values are: parameter values are:
o DIOIntervalMin 4 = 16 ms o DIOIntervalMin 4 = 16 ms
o DIOIntervalDoublings 14 o DIOIntervalDoublings 14
o DIORedundancyConstant 1 o DIORedundancyConstant 1
When a node sends a changed DIO, this is an inconsistency and forces
the receiving node to respond within Imin. So when something happens
which affects the DIO, the change is ideally communicated to a node,
n hops away, within n times Imin. Often, dependent on the node
density, packets are lost, or not sent,leading to larger delays.
In general we can expect DIO changes to propagate within 1 to 3
seconds within the envisaged networks.
When nothing happens, the DIO sending interval increases to 4.37
minutes, thus drastically reducing the network load. When a node
does not receive DIO messages during more than 10 minutes it can
safely conclude the connection with other nodes has been lost.
4.3.2. Other Parameters 4.3.2. Other Parameters
This section discusses the P2P-RPL parameters. This section discusses the P2P-RPL parameters.
P2P-RPL [RFC6997] provides the features requested by [RFC5826] and P2P-RPL [RFC6997] provides the features requested by [RFC5826] and
[RFC5867]. P2P-RPL uses a subset of the frame formats and features [RFC5867]. P2P-RPL uses a subset of the frame formats and features
defined for RPL [RFC6550] but may be combined with RPL frame flows in defined for RPL [RFC6550] but may be combined with RPL frame flows in
advanced deployments. advanced deployments.
The recommended parameter values for P2P-RPL are: The recommended parameter values for P2P-RPL are:
skipping to change at page 18, line 49 skipping to change at page 19, line 29
k > q (see condition above). Under this condition and for small k > q (see condition above). Under this condition and for small
Imin, a value of k=2 or k=3 is usually sufficient to minimize the Imin, a value of k=2 or k=3 is usually sufficient to minimize the
losses of packets in the first repeat interval. losses of packets in the first repeat interval.
max_expiration = 2 - 4. Higher values lead to more network load max_expiration = 2 - 4. Higher values lead to more network load
while generating copies which will probably not meet their deadline. while generating copies which will probably not meet their deadline.
6. Manageability Considerations 6. Manageability Considerations
Manageability is out of scope for home network scenarios. In At this moment it is not clear how homenets will be managed.
building automation scenarios, central control could be applied based Consequently it is not clear which tools will be used and which
on MIBs. parameters must be exposed for management.
In building control, management is mandatory. It is expected that
installations will be managed using the set of currently available
tools(including IETF tools like MIBS, NETCONF modules, DHCP and
others) with large differences between the ways an installation is
managed.
7. Security Considerations 7. Security Considerations
This section refers to the security considerations of [RFC6997], This section refers to the security considerations of [RFC6997],
[RFC6550], [I-D.ietf-roll-trickle-mcast], and the counter measures [RFC6550], [I-D.ietf-roll-trickle-mcast], and the counter measures
discussed in sections 6 and 7 of [I-D.ietf-roll-security-threats]. discussed in sections 6 and 7 of [I-D.ietf-roll-security-threats].
Communications network security is based on providing integrity Communications network security is based on providing integrity
protection and encryption to messages. This can be applied at protection and encryption to messages. This can be applied at
various layers in the network protocol stack based on using various various layers in the network protocol stack based on using various
skipping to change at page 20, line 6 skipping to change at page 20, line 40
nodes which share the same keys for link layer security and exclude nodes which share the same keys for link layer security and exclude
nodes sending unsecured messages. With per-message data origin nodes sending unsecured messages. With per-message data origin
authentication, it is possible to prevent unauthorized nodes joining authentication, it is possible to prevent unauthorized nodes joining
the mesh. the mesh.
At initial deployment the network is secured by consecutively At initial deployment the network is secured by consecutively
securing nodes at the link layer, thus building a network of secured securing nodes at the link layer, thus building a network of secured
nodes. The Protocol for carrying Authentication for Network Access nodes. The Protocol for carrying Authentication for Network Access
(PANA) Relay Element [RFC6345] in conjunction with PANA [RFC5191] (PANA) Relay Element [RFC6345] in conjunction with PANA [RFC5191]
provides a framework for network access and delivery of common link provides a framework for network access and delivery of common link
keys. A new DTLS-based protocol is proposed in keys.
[I-D.kumar-dice-dtls-relay].
New approaches to initial security deployment are being developed in
[I-D.kumar-dice-dtls-relay] and
[I-D.richardson-6tisch--security-6top]. Other initiatives are likely
to emerge in the context of minimal intervention configuration. At
this moment it is not clear what the final most widely deployed
solution will be.
For building control an installer will probably use an installation For building control an installer will probably use an installation
tool that establishes a secure communication path with the joining tool that establishes a secure communication path with the joining
node. In the home, nodes can be visually inspected by the home owner node. In the home, nodes can be visually inspected by the home owner
and simple measures like pushing buttons simultaneously on joint and and simple measures like pushing buttons simultaneously on joint and
joining devices is probably sufficient. joining devices is probably sufficient.
This recommendation is in line with the countermeasures described in This recommendation is in line with the countermeasures described in
section 6.1.1 of [I-D.ietf-roll-security-threats] section 6.1.1 of [I-D.ietf-roll-security-threats]
skipping to change at page 23, line 4 skipping to change at page 23, line 46
threats draft. threats draft.
o Added text to DODAG repair sub-section o Added text to DODAG repair sub-section
Changes from version 3 to version 4. Changes from version 3 to version 4.
o Renumbered sections and moved text to conform to applicability o Renumbered sections and moved text to conform to applicability
template template
o Extended MPL parameter value text o Extended MPL parameter value text
o Added references to building control products o Added references to building control products
Changes from version 4 to version 5. Changes from version 4 to version 5.
o Large editing effort to streamline text o Large editing effort to streamline text
o Rearranged Normative and Informative references o Rearranged Normative and Informative references
o Replaced RFC2119 terminology by non-normative terminology o Replaced RFC2119 terminology by non-normative terminology
o Rearranged text of section 7, 7.1, and 7.2 to agree with the o Rearranged text of section 7, 7.1, and 7.2 to agree with the
intention of section 7.2 intention of section 7.2
Changes from version 5 to version 6.
o Issues #162 - #166 addressed
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, September 2007. Networks", RFC 4944, September 2007.
skipping to change at page 24, line 41 skipping to change at page 25, line 37
Mechanism to Measure the Routing Metrics along a Point-to- Mechanism to Measure the Routing Metrics along a Point-to-
Point Route in a Low-Power and Lossy Network", RFC 6998, Point Route in a Low-Power and Lossy Network", RFC 6998,
August 2013. August 2013.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, January 2014. Lossy Networks", RFC 7102, January 2014.
[I-D.ietf-roll-trickle-mcast] [I-D.ietf-roll-trickle-mcast]
Hui, J. and R. Kelsey, "Multicast Protocol for Low power Hui, J. and R. Kelsey, "Multicast Protocol for Low power
and Lossy Networks (MPL)", draft-ietf-roll-trickle- and Lossy Networks (MPL)", draft-ietf-roll-trickle-
mcast-09 (work in progress), April 2014. mcast-11 (work in progress), November 2014.
[I-D.ietf-roll-security-threats] [I-D.ietf-roll-security-threats]
Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, "A Security Threat Analysis for Routing and M. Richardson, "A Security Threat Analysis for Routing
Protocol for Low-power and lossy networks (RPL)", draft- Protocol for Low-power and lossy networks (RPL)", draft-
ietf-roll-security-threats-11 (work in progress), October ietf-roll-security-threats-11 (work in progress), October
2014. 2014.
[IEEE802.15.4] [IEEE802.15.4]
"IEEE 802.15.4 - Standard for Local and metropolitan area "IEEE 802.15.4 - Standard for Local and metropolitan area
skipping to change at page 25, line 30 skipping to change at page 26, line 25
[RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A. [RFC6345] Duffy, P., Chakrabarti, S., Cragie, R., Ohba, Y., and A.
Yegin, "Protocol for Carrying Authentication for Network Yegin, "Protocol for Carrying Authentication for Network
Access (PANA) Relay Element", RFC 6345, August 2011. Access (PANA) Relay Element", RFC 6345, August 2011.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, May 2014. Constrained-Node Networks", RFC 7228, May 2014.
[I-D.ietf-6lo-lowpanz] [I-D.ietf-6lo-lowpanz]
Brandt, A. and J. Buron, "Transmission of IPv6 packets Brandt, A. and J. Buron, "Transmission of IPv6 packets
over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-07 over ITU-T G.9959 Networks", draft-ietf-6lo-lowpanz-08
(work in progress), September 2014. (work in progress), October 2014.
[I-D.ietf-dice-profile] [I-D.ietf-dice-profile]
Tschofenig, H., "A Datagram Transport Layer Security Tschofenig, H., "A Datagram Transport Layer Security
(DTLS) 1.2 Profile for the Internet of Things", draft- (DTLS) 1.2 Profile for the Internet of Things", draft-
ietf-dice-profile-04 (work in progress), August 2014. ietf-dice-profile-05 (work in progress), October 2014.
[I-D.keoh-dice-multicast-security] [I-D.keoh-dice-multicast-security]
Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A. Keoh, S., Kumar, S., Garcia-Morchon, O., Dijk, E., and A.
Rahman, "DTLS-based Multicast Security in Constrained Rahman, "DTLS-based Multicast Security in Constrained
Environments", draft-keoh-dice-multicast-security-08 (work Environments", draft-keoh-dice-multicast-security-08 (work
in progress), July 2014. in progress), July 2014.
[I-D.kumar-dice-dtls-relay] [I-D.kumar-dice-dtls-relay]
Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay Kumar, S., Keoh, S., and O. Garcia-Morchon, "DTLS Relay
for Constrained Environments", draft-kumar-dice-dtls- for Constrained Environments", draft-kumar-dice-dtls-
relay-01 (work in progress), April 2014. relay-02 (work in progress), October 2014.
[I-D.ietf-core-groupcomm] [I-D.ietf-core-groupcomm]
Rahman, A. and E. Dijk, "Group Communication for CoAP", Rahman, A. and E. Dijk, "Group Communication for CoAP",
draft-ietf-core-groupcomm-25 (work in progress), September draft-ietf-core-groupcomm-25 (work in progress), September
2014. 2014.
[I-D.richardson-6tisch--security-6top]
Richardson, M., "6tisch secure join using 6top", draft-
richardson-6tisch--security-6top-04 (work in progress),
November 2014.
[SOFT11] Baccelli, E., Phillip, M., and M. Goyal, "The P2P-RPL [SOFT11] Baccelli, E., Phillip, M., and M. Goyal, "The P2P-RPL
Routing Protocol for IPv6 Sensor Networks: Testbed Routing Protocol for IPv6 Sensor Networks: Testbed
Experiments", Proceedings of the Conference on Software Experiments", Proceedings of the Conference on Software
Telecommunications and Computer Networks, Split, Croatia,, Telecommunications and Computer Networks, Split, Croatia,,
September 2011. September 2011.
[INTEROP12] [INTEROP12]
Baccelli, E., Phillip, M., Brandt, A., Valev , H., and J. Baccelli, E., Phillip, M., Brandt, A., Valev , H., and J.
Buron , "Report on P2P-RPL Interoperability Testing", Buron , "Report on P2P-RPL Interoperability Testing",
RR-7864 INRIA Research Report RR-7864, January 2012. RR-7864 INRIA Research Report RR-7864, January 2012.
 End of changes. 21 change blocks. 
47 lines changed or deleted 90 lines changed or added

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