draft-ietf-roll-p2p-measurement-05.txt   draft-ietf-roll-p2p-measurement-06.txt 
Internet Engineering Task Force M. Goyal, Ed. Internet Engineering Task Force M. Goyal, Ed.
Internet-Draft University of Wisconsin Internet-Draft University of Wisconsin
Intended status: Experimental Milwaukee Intended status: Experimental Milwaukee
Expires: November 11, 2012 E. Baccelli Expires: March 21, 2013 E. Baccelli
INRIA INRIA
A. Brandt A. Brandt
Sigma Designs Sigma Designs
J. Martocci J. Martocci
Johnson Controls Johnson Controls
May 10, 2012 September 17, 2012
A Mechanism to Measure the Quality of a Point-to-point Route in a Low A Mechanism to Measure the Quality of a Point-to-point Route in a Low
Power and Lossy Network Power and Lossy Network
draft-ietf-roll-p2p-measurement-05 draft-ietf-roll-p2p-measurement-06
Abstract Abstract
This document specifies a mechanism that enables an RPL router to This document specifies a mechanism that enables an RPL router to
measure the quality of an existing route towards another RPL router measure the quality of an existing route towards another RPL router
in a low power and lossy network, thereby allowing the router to in a low power and lossy network, thereby allowing the router to
decide if it wants to initiate the discovery of a better route. decide if it wants to initiate the discovery of a better route.
Status of this Memo Status of this Memo
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 November 11, 2012. This Internet-Draft will expire on March 21, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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 5, line 8 skipping to change at page 5, line 8
Upon receiving the Measurement Request, the Target unicasts a Upon receiving the Measurement Request, the Target unicasts a
Measurement Reply message, carrying the accumulated values of the Measurement Reply message, carrying the accumulated values of the
routing metrics, back to the Origin. Optionally, the Origin may routing metrics, back to the Origin. Optionally, the Origin may
allow an Intermediate Router to generate the Measurement Reply if it allow an Intermediate Router to generate the Measurement Reply if it
already knows the relevant routing metric values along rest of the already knows the relevant routing metric values along rest of the
route. route.
3. The Measurement Object (MO) 3. The Measurement Object (MO)
This document defines two new RPL Control Message types, the This document defines two new RPL Control Message types, the
Measurement Object (MO), with code 0x06 (to be confirmed by IANA), Measurement Object (MO), with code TBD1, and the Secure MO, with code
and the Secure MO, with code 0x86 (to be confirmed by IANA). An MO TBD2. An MO serves as both Measurement Request and Measurement
serves as both Measurement Request and Measurement Reply. Reply.
3.1. Format of the base MO 3.1. Format of the base MO
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID | Compr |T|H|A|R|B|I| SequenceNo| Num | Index | | RPLInstanceID | Compr |T|H|A|R|B|I| SequenceNo| Num | Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
| Origin Address | | Origin Address |
skipping to change at page 17, line 44 skipping to change at page 17, line 44
that it does not contain a loop involving the router. The router that it does not contain a loop involving the router. The router
must drop the received packet if the source route does contain must drop the received packet if the source route does contain
such a loop. This and the previous two rules protect the network such a loop. This and the previous two rules protect the network
against some of the security concerns even if a compromised node against some of the security concerns even if a compromised node
inserts a malformed Address vector inside the MO message. inserts a malformed Address vector inside the MO message.
9. IANA Considerations 9. IANA Considerations
This document defines two new RPL messages: This document defines two new RPL messages:
o "Measurement Object" (see Section 3.1), assigned a value of 0x06 o "Measurement Object" (see Section 3.1), assigned a value TBD1 from
from the "RPL Control Codes" space [to be removed upon the "RPL Control Codes" space [to be removed upon publication:
publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes] http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550]. [RFC6550]. IANA is requested to allocate TBD1 from the range
0x00-0x7F to indicate a message without security enabled. The
string TBD1 in this document should be replaced by the allocated
value. These last two sentences should be removed before
publication.
o "Secure Measurement Object" (see Section 3.2), assigned a value of o "Secure Measurement Object" (see Section 3.2), assigned a value
0x86 from the "RPL Control Codes" space [to be removed upon TBD2 from the "RPL Control Codes" space [to be removed upon
publication: publication:
http://www.iana.org/assignments/rpl/rpl.xml#control-codes] http://www.iana.org/assignments/rpl/rpl.xml#control-codes]
[RFC6550]. [RFC6550]. IANA is requested to allocate TBD2 from the range
0x80-0xFF to indicate a message with security enabled. The string
TBD2 in this document should be replaced by the allocated value.
These last two sentences should be removed before publication.
+------+---------------------------+---------------+ +------+---------------------------+---------------+
| Code | Description | Reference | | Code | Description | Reference |
+------+---------------------------+---------------+ +------+---------------------------+---------------+
| 0x06 | Measurement Object | This document | | TBD1 | Measurement Object | This document |
| 0x86 | Secure Measurement Object | This document | | TBD2 | Secure Measurement Object | This document |
+------+---------------------------+---------------+ +------+---------------------------+---------------+
RPL Control Codes RPL Control Codes
10. Acknowledgements 10. Acknowledgements
Authors gratefully acknowledge the contributions of Matthias Philipp, Authors gratefully acknowledge the contributions of Matthias Philipp,
Pascal Thubert, Richard Kelsey and Zach Shelby in the development of Pascal Thubert, Richard Kelsey and Zach Shelby in the development of
this document. this document.
skipping to change at page 18, line 38 skipping to change at page 18, line 42
11.1. Normative References 11.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.
11.2. Informative References 11.2. Informative References
[I-D.ietf-roll-p2p-rpl] [I-D.ietf-roll-p2p-rpl]
Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J. Goyal, M., Baccelli, E., Philipp, M., Brandt, A., and J.
Martocci, "Reactive Discovery of Point-to-Point Routes in Martocci, "Reactive Discovery of Point-to-Point Routes in
Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-12 Low Power and Lossy Networks", draft-ietf-roll-p2p-rpl-13
(work in progress), May 2012. (work in progress), June 2012.
[RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation [RFC5095] Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
of Type 0 Routing Headers in IPv6", RFC 5095, of Type 0 Routing Headers in IPv6", RFC 5095,
December 2007. December 2007.
[RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation
Routing Requirements in Low-Power and Lossy Networks", Routing Requirements in Low-Power and Lossy Networks",
RFC 5826, April 2010. RFC 5826, April 2010.
[RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen,
 End of changes. 11 change blocks. 
18 lines changed or deleted 24 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/