draft-ietf-roll-capabilities-08.txt   draft-ietf-roll-capabilities-09.txt 
ROLL R. Jadhav, Ed. ROLL R.A. Jadhav, Ed.
Internet-Draft Internet-Draft Huawei
Intended status: Standards Track P. Thubert Intended status: Standards Track P. Thubert
Expires: September 18, 2021 Cisco Expires: 13 May 2022 Cisco
M. Richardson M. Richardson
Sandelman Software Works Sandelman Software Works
R. Sahoo R.N. Sahoo
Juniper Juniper
March 17, 2021 9 November 2021
RPL Capabilities RPL Capabilities
draft-ietf-roll-capabilities-08 draft-ietf-roll-capabilities-09
Abstract Abstract
This draft enables the discovery, advertisement and query of This draft enables the discovery, advertisement and query of
capabilities for RPL nodes. capabilities for RPL nodes.
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
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 September 18, 2021. This Internet-Draft will expire on 13 May 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Language and Terminology . . . . . . . . . . 3 1.1. Requirements Language and Terminology . . . . . . . . . . 3
1.2. What are Capabilities? . . . . . . . . . . . . . . . . . 4 1.2. What are Capabilities? . . . . . . . . . . . . . . . . . 4
2. Requirements for this document . . . . . . . . . . . . . . . 4 2. Requirements for this document . . . . . . . . . . . . . . . 4
2.1. How are Capabilities different from existing RPL 2.1. How are Capabilities different from existing RPL
primitives? . . . . . . . . . . . . . . . . . . . . . . . 4 primitives? . . . . . . . . . . . . . . . . . . . . . . . 4
3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Capabilities . . . . . . . . . . . . . . . . . . . . . . . . 5
skipping to change at page 2, line 36 skipping to change at page 2, line 43
5.1. Handling Capability flags . . . . . . . . . . . . . . . . 8 5.1. Handling Capability flags . . . . . . . . . . . . . . . . 8
5.1.1. Rules to handle capabilities flag . . . . . . . . . . 9 5.1.1. Rules to handle capabilities flag . . . . . . . . . . 9
6. Node Capabilities . . . . . . . . . . . . . . . . . . . . . . 9 6. Node Capabilities . . . . . . . . . . . . . . . . . . . . . . 9
6.1. Capability Indicators . . . . . . . . . . . . . . . . . . 9 6.1. Capability Indicators . . . . . . . . . . . . . . . . . . 9
6.1.1. Format of Capability Indicators . . . . . . . . . . . 9 6.1.1. Format of Capability Indicators . . . . . . . . . . . 9
6.2. Routing Resource Capability . . . . . . . . . . . . . . . 10 6.2. Routing Resource Capability . . . . . . . . . . . . . . . 10
6.2.1. Format of Routing Resource Capability . . . . . . . . 10 6.2.1. Format of Routing Resource Capability . . . . . . . . 10
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
8.1. New option: Capabilities . . . . . . . . . . . . . . . . 11 8.1. New option: Capabilities . . . . . . . . . . . . . . . . 11
8.2. Capability Sub-Type . . . . . . . . . . . . . . . . . . . 11 8.2. Capability Sub-Type . . . . . . . . . . . . . . . . . . . 12
8.3. New Registry for CAPQ Flags . . . . . . . . . . . . . . . 12 8.3. New Registry for CAPQ Flags . . . . . . . . . . . . . . . 12
8.4. New Registry for Capabilities Flags . . . . . . . . . . . 12 8.4. New Registry for Capabilities Flags . . . . . . . . . . . 12
8.5. New Registry for Capabilities Indicators . . . . . . . . 12 8.5. New Registry for Capabilities Indicators . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
10.1. Normative References . . . . . . . . . . . . . . . . . . 13 10.1. Normative References . . . . . . . . . . . . . . . . . . 13
10.2. Informative References . . . . . . . . . . . . . . . . . 13 10.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Capability Handshake Example . . . . . . . . . . . . 14 Appendix A. Capability Handshake Example . . . . . . . . . . . . 14
A.1. Query supported Cap Types . . . . . . . . . . . . . . . . 14 A.1. Query supported Cap Types . . . . . . . . . . . . . . . . 14
A.2. Query specific Cap Set . . . . . . . . . . . . . . . . . 14 A.2. Query specific Cap Set . . . . . . . . . . . . . . . . . 15
A.3. CAPS with partial Cap Set . . . . . . . . . . . . . . . . 15 A.3. CAPS with partial Cap Set . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
RPL [RFC6550] specifies a proactive distance-vector based routing RPL [RFC6550] specifies a proactive distance-vector based routing
scheme. The protocol creates a DAG-like structure which operates scheme. The protocol creates a DAG-like structure which operates
with a given "Mode of Operation" (MOP) determining the minimal and with a given "Mode of Operation" (MOP) determining the minimal and
mandatory set of primitives to be supported by all the participating mandatory set of primitives to be supported by all the participating
nodes. nodes.
This document adds a notion of capabilities, through which a node in This document adds a notion of capabilities using which nodes in the
the network could inform its peers about its additional capabilities. network could inform its peers about its additional capabilities.
Using capabilities, a node could determine whether the target node This document highlights the differences of capabilities from that of
supports the required feature before utilizing the feature. This Mode of operation and explains the necessity of it.
document highlights the differences between capabilities and Mode of
Operation and explains the necessity for the former.
1.1. Requirements Language and Terminology 1.1. Requirements Language and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
MOP: Mode of Operation. Identifies the MOP of the RPL Instance as MOP: Mode of Operation. Identifies the MOP of the RPL Instance as
administratively provisioned at and distributed by the DODAG root. administratively provisioned at and distributed by the DODAG root.
MOPex: Extended MOP: As defined in [I-D.ietf-roll-mopex]. MOPex: Extended MOP: As defined in [I-D.ietf-roll-mopex].
Capabilities: Additional features or capabilities that are supported Capabilities: Additional features or capabilities that are supported
by the node. by the node.
Cap: Abbreviated term used for Capability. Cap: Abbreviated term used for Capability.
Caps: Abbreviated term used for Capabilities. Caps: Abbreviated term used for Capabilities.
DAO: DODAG Advertisement Object. A RPL (pronounced ripple) message DAO: DODAG Advertisement Object. An RPL message used to advertise
used to advertise the target information in order to establish the target information in order to establish routing adjacencies.
routing adjacencies.
DIO: DODAG Information Object. A RPL message initiated by the root DIO: DODAG Information Object. An RPL message initiated by the root
and is used to advertise the network configuration information. and is used to advertise the network configuration information.
Current parent: Parent 6LR node before switching to the new path. Current parent: Parent 6LR node before switching to the new path.
NPDAO: No-Path DAO. A DAO message that contains a Transit NPDAO: No-Path DAO. A DAO message which has target with lifetime 0.
Information Option with lifetime equal to 0.
Upstream path/direction: Path or direction from the node to the Root Upstream path/direction: Path or direction from the node to the Root
in a DAG. in a DAG.
Downstream path/direction: Path or direction to the node from the Downstream path/direction: Path or direction to the node from the
Root in a DAG. Root in a DAG.
This document uses terminology described in [RFC6550]. For the sake This document uses terminology described in [RFC6550]. For the sake
of readability all the known relevant terms are repeated in this of readability all the known relevant terms are repeated in this
section. section.
1.2. What are Capabilities? 1.2. What are Capabilities?
Currently, RPL specification does not have a mechanism whereby a node Currently RPL specification does not have a mechanism whereby a node
can signal the set of features that are available on its end. Such a can signal the set of features that are available on its end. Such a
mechanism could help the root to advertise its capabilities and in mechanism could help the root to advertise its capabilities and in
response also determine some advanced information about the response also determine some advanced information about the
capabilities of the joining nodes. This document defines capabilities of the joining nodes. This document defines
Capabilities and corresponding messaging handshakes that could be Capabilities which could be supported by the nodes and handshaked as
supported by the nodes. Capabilities are embedded as an RPL Control part of RPL signaling. Capabilities are embedded as an RPL Control
Message Option as defined in Section 6.7 of [RFC6550]. Message Option as defined in Section 6.7 of [RFC6550].
2. Requirements for this document 2. Requirements for this document
Following are the requirements considered for this documents: Following are the requirements considered for this documents:
REQ1: Optional capabilities handshake. Capabilities are features, REQ1: Backwards compatibility. The new options and new fields in
possibly optional, which could be indicated between the nodes the DIO message should be backward compatible i.e. if there
are nodes which support old MOPs they could still operate in
their own instances.
REQ2: Optional capabilities handshake. Capabilities are features,
possibly optional, which could be handshaked between the nodes
and the root within an RPL Instance. and the root within an RPL Instance.
REQ2: Capabilities handshake could be optionally added with existing REQ3: Capabilities handshake could be optionally added with existing
MOPs. Capabilities, being optional, could be put to use with MOPs. Capabilities been optional in nature could be put to
existing MOPs. Capabilities and MOP-extension are mutually use with existing MOPs. Capabilities and MOP-extension is
independent i.e. a DIO can have a capabilities option, MOP- mutually independent i.e. a DIO can have a capabilities
extension option, or both in the same message. option, MOP-extension option or both in the same message.
REQ3: Capabilities could be explicitly queried. REQ4: Capabilities could be explicitly queried.
2.1. How are Capabilities different from existing RPL primitives? 2.1. How are Capabilities different from existing RPL primitives?
The Mode of Operation (MOP) field in RPL mandates the operational The Mode of Operation (MOP) field in RPL mandates the operational
requirement for the nodes joining as routers. MOP and DIO requirement for the nodes joining as routers. MOP and DIO
Configuration Option is strictly controlled by the Root node in RPL. Configuration Option is strictly controlled by the Root node in RPL.
Intermediate 6LRs cannot modify these fields. Also, the MOP never Intermediate 6LRs cannot modify these fields. Also, the MOP never
changes for the lifetime of the RPL Instance. Changes in DIO changes for the lifetime of the RPL Instance. Changes in DIO
Configuration Option are possible but are rare. Capabilities, on the Configuration Option are possible but are rare. Capabilities, on the
other hand, might change more dynamically. other hand, might change more dynamically.
RPL DIO message also carries routing metrics and constraints as RPL DIO message also carries routing metrics and constraints as
specified in [RFC6551]. Metrics and constraints are used in addition specified in [RFC6551]. Metrics and constraints are used as part of
to an objective function to determine a node's rank calculation. A objective function which aids in node's rank calculation. A router
router may use capabilities carried in DIO messages as additional may use capabilities carried in DIO message as additional metrics/
metrics/constraints. However, capabilities have a larger scope and constraints. However, capabilities have a larger scope and may be
might be carried in messages other than DIO and can flow in either carried in other messages other than DIO and can flow in both the
direction (upstream and downstream). directions (upstream and downstream).
3. Capabilities 3. Capabilities
Handling of Capabilities MUST be supported if the network uses MOPex Handling of Capabilities MUST be supported if the network uses MOPex
[I-D.ietf-roll-mopex]. [I-D.ietf-roll-mopex].
Note that capabilities and MOPex are mutually exclusive and it is Note that capabilities and MOPex are mutually exclusive and it is
possible for an implementation to support either or both of the possible for an implementation to support either or both of the
options. options.
3.1. Capability Control Message Option 3.1. Capability Control Message Option
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TODO | Option Length | Capabilities TLVs | Type = TODO | Option Length | Capabilities TLVs
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Capabilities Option Figure 1: Capabilities Option
Multiple capabilities can be sent in the same message. The length Multiple capabilities could be sent in the same message. The length
field allows the message parser to skip the capability TLV parsing. field allows the message parser to skip the capability TLV parsing.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CapType | Len |J|I|C| Flags | ... | CapType | Len |J|I|C| Flags | ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Capabilities TLV Figure 2: Capabilities TLV
Every capability is identified by its type and it may have an Every capability is identified by its type and it may have an
optional Capability Info. Note that a given capability may or may optional Capability Info. Note that a given capability may or may
not be disseminated with additional information depending on the not be diseminated with additional information depending on the scope
scope of the capability indicated by the I bit. of the capability indicated by the I bit.
Len: 8-bit unsigned integer, representing the length in octets of the Len: 8-bit unsigned integer, representing the length in octets of the
TLV, not including the CapType, Length and Flags fields. TLV, not including the CapType, Length and Flags fields.
J = Join only as leaf if capability not understood. J = Join only as leaf if capability not understood.
I = Ignore the message if this capability is not understood. I = Ignore the message if this capability is not understood.
C = Flag indicating that the capability MUST be copied in the C = Flag indicating that the capability MUST be copied in the
downstream message. downstream message.
3.2. Capabilities Handshake 3.2. Capabilities Handshake
The root node can advertise the set of capabilities it supports in The root node could advertise the set of capabilities it supports in
the DIO message. A node can take advantage of the knowledge that the the DIO message. A node could take advantage of the knowledge that
root supports a particular capability. Similarly, a node can the root supports a particular capability. Similarly a node could
advertise its capabilities in the DAO message using the capability advertise its capabilities in the DAO message using the capability
control message option defined in this document. Capabilities control message option defined in this document. Capabilities
advertised by non-root nodes is strictly a subset of the capabilities advertised by non-root nodes are strictly a subset of the
advertised by the root. capabilities advertised by the root.
In storing MOP, the DAO message from the 6LR can contain multiple In storing MOP, the DAO message from the 6LR could contain multiple
target options because of the DAO-Aggregation. The targets of the target options because of the DAO-Aggregation. The targets of the
capabilities option are indicated by one or more Target options that capabilities option are indicated by one or more Target options that
precede the Capabilities Option. This handling is similar to the precede the Capabilities Option. This handling is similar to the
Transit Information Option as supported in Section 6.7.8. of Transit Information Option as supported in Section 6.7.8. of
[RFC6550]. [RFC6550].
4. Querying Capabilities 4. Querying Capabilities
Nodes may be interested in knowing the capabilities of another node Nodes may be interested in knowing the capabilities of another node
before taking an action. For example, consider before taking an action. For e.g., Consider
[I-D.ietf-roll-dao-projection], in which the Root may want to know [I-D.ietf-roll-dao-projection], the Root may want to know the
the capabilities of the nodes along a network segment before it capabilities of the nodes along a network segment before it initiates
initiates a projected DAO to install the routes along that segment. a projected DAO to install the routes along that segment.
Caps can be carried in existing RPL Control messages as Control Caps can be carried in existing RPL Control messages as Control
Options, however, Caps can also be queried explicitly. This section Options, however Caps can also be queried explicitly. This section
provides a way for a node to query the capability set of another provides a way for a node to query capability set of another node.
node. The capability query and subsequent response messages are The capability query and subsequent response messages are directly
directly addressed between the two peers. addressed between the two peers.
4.1. Capability Query (CAPQ) 4.1. Capability Query (CAPQ)
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 | Flags | reserved | CAPQSequence | | RPLInstanceID | Flags | reserved | CAPQSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: CAPQ base object Figure 3: CAPQ base object
CAPQSequence: One byte, Sequence number sent by the CAPQ sender and CAPQSequence: One byte, Sequence number sent by the CAPQ sender
reflected back by the responder in the CAPS message. which is reflected back by the responder in the CAPS message.
Flags: One byte, set to zero by sender, ignored by receiver. Flags: One byte, set to zero by sender, ignored by receiver.
reserved: One byte, set to zero by sender, ignored by receiver. reserved: One byte, set to zero by sender, ignored by receiver.
The CAPQ base object may be followed by one or more options. The CAPQ base object may be followed by one or more options. The
Capability Type List Control Option (see Figure 4) is used to carry a Capability Type List Control Option Figure 4 is used to carry a set
set of capability types to query about. of capability types to query about.
If the sender does not send a Capability Type List Control Option, If the sender does not send Figure 4 option, this would indicate that
this indicates that the node intends to query the Capability Type the node intends to query the capability type list Figure 4 supported
List supported by the target node. by the target node.
4.1.1. Capability Type List Control Option 4.1.1. Capability Type List Control Option
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = TODO | Option Length | CapType1 | CapType2 | | Type = TODO | Option Length | CapType1 | CapType2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CapType3 | ..... | CapType3 | .....
+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 7, line 49 skipping to change at page 8, line 4
4.2. Capability Set Response (CAPS) 4.2. Capability Set Response (CAPS)
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 | Flags | Reserved | CAPQSequence | | RPLInstanceID | Flags | Reserved | CAPQSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 5: CAPS base object
Figure 5: CAPS base object
Flags: One byte, set to zero by sender, ignored by receiver. Flags: One byte, set to zero by sender, ignored by receiver.
reserved: One byte, set to zero by sender, ignored by receiver. reserved: One byte, set to zero by sender, ignored by receiver.
CAPQSequence: One byte, Sequence number copied from CAPQSequence CAPQSequence: One byte, Sequence number copied from CAPQSequence
received in the CAPQ message. received in the CAPQ message.
CAPS message SHOULD contain the capability set Figure 1 queried by CAPS message SHOULD contain the capability set Figure 1 queried by
the CAPQ sender. If the target node does not support a subset of the the CAPQ sender. If the target node does not support subset of the
queried capabilities then the Capability Type List with the queried capabilities then the Figure 4 option with the unsupported
unsupported cap-types SHOULD be sent back indicating the queried cap-types SHOULD be sent back indicating the queried capabilities
capabilities not-supported by the target node. For example, check not-supported by the target node. For an example, check Appendix A.3
Appendix A.3
If the CAPQ message does not contain any Capability Type List option If the CAPQ message does not contain any Figure 4 option then the
then the receiver MUST respond with the cap types it supports using a receiver MUST respond with the cap types it supports using Figure 4.
Capability Type List Option (see Figure 4).
If the capability set cannot be transmitted in a single message (for If the capability set cannot be transmitted in a single message (for
e.g., because of MTU limitations) then multiple CAPS messages could e.g., because of MTU limitations) then multiple CAPS messages could
be used. All the CAPS messages MUST use the same CAPQSequence number be used. All the CAPS message MUST use the same CAPQSequence number
copied from the corresponding CAPQ message. copied from the corresponding CAPQ message.
4.2.1. Secure CAPS 4.2.1. Secure CAPS
A Secure CAPS message follows the format in [RFC6550] Figure 7, where A Secure CAPS message follows the format in [RFC6550] Figure 7, where
the base message format is the CAPS message shown in Figure 5. the base message format is the CAPS message shown in Figure 5.
5. Guidelines for defining new capabilities 5. Guidelines for defining new capabilities
This section provides guidelines/recommendations towards defining new This section provides guidelines/recommendations towards defining new
capabilities. Note that the capabilities might be carried as part of capabilities. Note that the capabilities might be carried as part of
the multicast messaging such as DIO and hence the set should be used the multicast messaging such as DIO and hence the set should be used
sparingly. in restrictive manner as far as possible.
5.1. Handling Capability flags 5.1. Handling Capability flags
A node MUST drop or discard the message with an unknown capability A node MUST drop or discard the message with an unknown capability
with the 'D' flag set. The message MUST be discarded silently. with 'D' flag set. The message MUST be discarded silently.
The 'J' (join) flag can be set in context to a capability either by a The 'J' (join) flag can be set in context to a capability either by a
6LR or the root. The 'J' flag indicates that if the capability is 6LR or the root. The 'J' flag indicates that if the capability is
not supported by a node then it can join the instance only as a 6LN not supported by a node then it can join the instance only as a 6LN
(or do not join as 6LR). (or do not join as 6LR).
The 'C' (copy) flag is set by the node indicating that the The 'C' (copy) flag is set by the node indicating that the
capabilities MUST be copied downstream by the node even if the node capabilities MUST be copied downstream by the node even if the node
does not understand the capability. does not understand the capability.
5.1.1. Rules to handle capabilities flag 5.1.1. Rules to handle capabilities flag
How should a node react to capability it does On receiving a capability it does not support, the node MUST check
not support before joining the Instance? the 'J' flag of the capability before joining the Instance. If the
On receiving a capability it does not support, the node MUST check 'J' flag is set then it can only join as a 6LN.
the 'J' flag of the capability before joining the Instance. If
the 'J' flag is set then it can only join as a 6LN.
How should a node react to capability it does not support after
joining the Instance?
If the node is operating as 6LR and subsequently it receives a
capability from its preferred parent which it does not understand
with 'J' flag set, then the node has to switch itself to 6LN mode.
During switching, the node needs to inform its downstream peers of
its changed status by sending a DIO with infinite rank as
mentioned in RFC6550. Alternatively, a node may decide to switch
to another parent with compatible and known capabilities.
When to use and when not to use Capabilities? If the node is operating as 6LR and subsequently it receives a
capability from its preferred parent which it does not understand
with 'J' flag set, then the node has to switch itself to 6LN mode.
During switching the node needs to inform its downstream peers of its
changed status by sending a DIO with infinite rank as mentioned in
RFC6550. Alternatively, a node may decide to switch to another
parent with compatible and known capabilities.
Capabilities are used to indicate a feature that is supported by Capabilities are used to indicate a feature that is supported by the
the node. Capabilities are not meant for configuration management node. Capabilities are not meant for configuration management for
for e.g., setting a threshold. e.g., setting a threshold.
6. Node Capabilities 6. Node Capabilities
6.1. Capability Indicators 6.1. Capability Indicators
Capability Indicators indicate the capabilities supported by the node Capability Indicators indicates the capabilities supported by the
in the form of simple flags. Capabilities that do not need node in the form of simple flags. Capabilities who do not have
additional information to be specified can make use of these flags to additional information to be specified could make use of these flags
indicate their support. to indicate their support.
6.1.1. Format of Capability Indicators 6.1.1. Format of Capability Indicators
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CapType=0x01 | Len |J|I|C| Flags |T|..Indicators.. | CapType=0x01 | Len |J|I|C| Flags |T|..Indicators..
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: Capability Indicators TLV Figure 6: Capability Indicators TLV
Flags: LRs MUST set it to 0. I bit will always be set to 0. Flags: LRs MUST set it to 0. I bit will always be set to 0.
T flag (Bit 1): Indicates whether the node supports 6LoRH [RFC8138]. T flag (Bit 1): Indicates whether the node supports 6LoRH [RFC8138].
6.2. Routing Resource Capability 6.2. Routing Resource Capability
Storing Mode of Operation requires each intermediate router in the Storing mode of operation requires each intermediate router in the
LLN to maintain routing state information in the routing table. LLN LLN to maintain routing states' information in the routing table.
routers typically operate with constraints on processing power, LLN routers typically operate with constraints on processing power,
memory, and energy (battery power). Memory limits the size of the memory, and energy (battery power). Memory limits the number of
routing state an LR and BR can maintain. When the routing table of routing states an LR and BR can maintain. When the routing table of
an LR or BR is full, it will either reject the new DAO messages an LR or BR is full, it will either reject the new DAO messages
received or will use some replacement policy to remove a routing received or will use some replacement policy to remove a routing
entry and add the new one. Rejection of DAO messages will lead to an entry and add the new one. Rejection of DAO messages will lead to an
increase in DAO message transmission that impacts the energy and increase in DAO message transmission that impacts the energy and
network convergence time. Routing state replacement leads to network convergence time. Routing state replacement leads to
downward path downtime. downward path downtime.
One possible way to solve problems due to routing table size One possible way to solve problems due to routing table size
constraint is to use this information to add neighbors to the DAO constraint is to use this information to add neighbors to the DAO
parent set. Routing resource capability can be used by LR and BR to parent set. Routing resource capability can be used by LR and BR to
advertise their current routing table usage details in the network. advertise their current routing table usage details in the network.
LR or LNs in LLN can use this information in the selection of the DAO LR or LNs in LLN can use this information in the selection of the DAO
parent set. PCE can use this information to select intermediate parent set. PCE can use this information to select intermediate
routers for the projected routes. Routing Resource is an optional routers for the projected routes. Routing Resource is an optional
capability. capability.
Routing resource capabablity sent in DIO message has link local scope Routing resource capabablity sent in DIO message has link local scope
and it MUST NOT be forwarded. The 'C' bit of this capability MUST be and it MUST not be forwarded. The 'C' bit of this capability MUST be
set to 0. set to 0.
6.2.1. Format of Routing Resource Capability 6.2.1. Format of Routing Resource Capability
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CapType=0x02 | Len=3 |J|I|C| Flags | Reserved | | CapType=0x02 | Len=3 |J|I|C| Flags | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total Capacity | | Total Capacity |
skipping to change at page 11, line 18 skipping to change at page 11, line 18
7. Acknowledgements 7. Acknowledgements
Thanks to Georgios Papadopoulos, Li Zhao for early review and Thanks to Georgios Papadopoulos, Li Zhao for early review and
feedback. feedback.
8. IANA Considerations 8. IANA Considerations
IANA is requested to allocate new codes for the CAPQ and CAPS IANA is requested to allocate new codes for the CAPQ and CAPS
messages from the RPL Control Codes registry. messages from the RPL Control Codes registry.
+------+----------------------------+---------------+ +======+============================+===============+
| Code | Description | Reference | | Code | Description | Reference |
+------+----------------------------+---------------+ +======+============================+===============+
| TBD1 | Capability Query | This document | | TBD1 | Capability Query | This document |
+------+----------------------------+---------------+
| TBD2 | Capability Response | This document | | TBD2 | Capability Response | This document |
+------+----------------------------+---------------+
| TBD3 | Secure Capability Query | This document | | TBD3 | Secure Capability Query | This document |
+------+----------------------------+---------------+
| TBD4 | Secure Capability Response | This document | | TBD4 | Secure Capability Response | This document |
+------+----------------------------+---------------+ +------+----------------------------+---------------+
New RPL Control Messages Table 1: New RPL Control Messages
The MSB of the codes allocated to "Secure" messages above should be The MSB of the codes allocated to "Secure" messages above should be
set. set.
8.1. New option: Capabilities 8.1. New option: Capabilities
New entry is required for supporting new Capabilities option and new New entry is required for supporting new Capabilities option and new
Capability Type List Option in the "RPL Control Message Options" Capability Type List Option in the "RPL Control Message Options"
space [RFC6550]. space [RFC6550].
+-------+-----------------------------+---------------+ +=======+=============================+===============+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+-----------------------------+---------------+ +=======+=============================+===============+
| TODO | Capability Option | This document | | TODO | Capability Option | This document |
+-------+-----------------------------+---------------+
| TODO | Capability Type List Option | This document | | TODO | Capability Type List Option | This document |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
New options Table 2: New options
8.2. Capability Sub-Type 8.2. Capability Sub-Type
IANA is requested to create a registry for the Capabilities Type as IANA is requested to create a registry for the Capabilities Type as
described in Figure 2 of this document. This registry should be described in Figure 2 of this document. This registry should be
located in TODO. New Capabilities types may be allocated only by an located in TODO. New Capabilities types may be allocated only by an
IETF review. IETF review.
+-------+-----------------------------+---------------+ +=======+=============================+===============+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+-----------------------------+---------------+ +=======+=============================+===============+
| 0x01 | Capability Indicators | This document | | 0x01 | Capability Indicators | This document |
+-------+-----------------------------+---------------+
| 0x02 | Routing Resource Capability | This document | | 0x02 | Routing Resource Capability | This document |
+-------+-----------------------------+---------------+ +-------+-----------------------------+---------------+
Type Table 3: Type
8.3. New Registry for CAPQ Flags 8.3. New Registry for CAPQ Flags
IANA is requested to create a registry for the Capabilities flags as IANA is requested to create a registry for the Capabilities flags as
described in Section 4.1 of this document. This registry should be described in Section 4.1 of this document. This registry should be
located in TODO. New Capabilities flags may be allocated only by an located in TODO. New Capabilities flags may be allocated only by an
IETF review. Currently no flags are defined by this document. Each IETF review. Currently no flags are defined by this document. Each
value is tracked with the following qualities: value is tracked with the following qualities:
o Flag * Flag
o Description * Description
o Defining RFC * Defining RFC
8.4. New Registry for Capabilities Flags 8.4. New Registry for Capabilities Flags
IANA is requested to create a registry for the Capabilities flags as IANA is requested to create a registry for the Capabilities flags as
described in Section 2.1 of this document. This registry should be described in Section 2.1 of this document. This registry should be
located in TODO. New Capabilities flags may be allocated only by an located in TODO. New Capabilities flags may be allocated only by an
IETF review. Currently no flags are defined by this document. Each IETF review. Currently no flags are defined by this document. Each
value is tracked with the following qualities: value is tracked with the following qualities:
o Flag * Flag
o Description * Description
o Defining RFC * Defining RFC
8.5. New Registry for Capabilities Indicators 8.5. New Registry for Capabilities Indicators
IANA is requested to create a registry for the Capabilities IANA is requested to create a registry for the Capabilities
Indicators as described in Section 6.1 of this document. This Indicators as described in Section 6.1 of this document. This
registry should be located in TODO. New Capabilities indicators may registry should be located in TODO. New Capabilities indicators may
be allocated only by an IETF review. Each value is tracked with the be allocated only by an IETF review. Each value is tracked with the
following qualities: following qualities:
o Flag * Flag
o Description * Description
o Defining RFC
* Defining RFC
9. Security Considerations 9. Security Considerations
The options defined in this document are carried in the base message The options defined in this document are carried in the base message
objects as defined in [RFC6550]. The RPL control message options are objects as defined in [RFC6550]. The RPL control message options are
protected by the same security mechanisms that protect the base protected by the same security mechanisms that protect the base
messages. messages.
Capabilities flag can reveal that the node has been upgraded or is Capabilities flag can reveal that the node has been upgraded or is
running a old feature set. This document assumes that the base running a old feature set. This document assumes that the base
skipping to change at page 13, line 26 skipping to change at page 13, line 39
mechanisms and thus are not visible to a malicious node. mechanisms and thus are not visible to a malicious node.
[TODO] implications of malicious attack involving setting the [TODO] implications of malicious attack involving setting the
capability flags. capability flags.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-roll-mopex] [I-D.ietf-roll-mopex]
Jadhav, R., Thubert, P., and M. Richardson, "Mode of Jadhav, R. A., Thubert, P., and M. Richardson, "Mode of
Operation extension", draft-ietf-roll-mopex-02 (work in Operation extension", Work in Progress, Internet-Draft,
progress), September 2020. draft-ietf-roll-mopex-03, 31 March 2021,
<https://www.ietf.org/archive/id/draft-ietf-roll-mopex-
03.txt>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network "IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>. April 2017, <https://www.rfc-editor.org/info/rfc8138>.
10.2. Informative References 10.2. Informative References
[I-D.ietf-lwig-nbr-mgmt-policy]
Jadhav, R. A., Sahoo, R. N., Duquennoy, S., and J.
Eriksson, "Neighbor Management Policy for 6LoWPAN", Work
in Progress, Internet-Draft, draft-ietf-lwig-nbr-mgmt-
policy-03, 21 February 2019,
<https://www.ietf.org/archive/id/draft-ietf-lwig-nbr-mgmt-
policy-03.txt>.
[I-D.ietf-roll-dao-projection] [I-D.ietf-roll-dao-projection]
Thubert, P., Jadhav, R., and M. Gillmore, "Root initiated Thubert, P., Jadhav, R. A., and M. Gillmore, "Root
routing state in RPL", draft-ietf-roll-dao-projection-16 initiated routing state in RPL", Work in Progress,
(work in progress), January 2021. Internet-Draft, draft-ietf-roll-dao-projection-21, 27
September 2021, <https://www.ietf.org/archive/id/draft-
ietf-roll-dao-projection-21.txt>.
[I-D.thubert-roll-turnon-rfc8138]
Thubert, P. and L. Zhao, "Configuration option for RFC
8138", Work in Progress, Internet-Draft, draft-thubert-
roll-turnon-rfc8138-03, 8 July 2019, <http://www.ietf.org/
internet-drafts/draft-thubert-roll-turnon-rfc8138-03.txt>.
[RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N., [RFC6551] Vasseur, JP., Ed., Kim, M., Ed., Pister, K., Dejean, N.,
and D. Barthel, "Routing Metrics Used for Path Calculation and D. Barthel, "Routing Metrics Used for Path Calculation
in Low-Power and Lossy Networks", RFC 6551, in Low-Power and Lossy Networks", RFC 6551,
DOI 10.17487/RFC6551, March 2012, DOI 10.17487/RFC6551, March 2012,
<https://www.rfc-editor.org/info/rfc6551>. <https://www.rfc-editor.org/info/rfc6551>.
Appendix A. Capability Handshake Example Appendix A. Capability Handshake Example
A.1. Query supported Cap Types A.1. Query supported Cap Types
skipping to change at page 14, line 51 skipping to change at page 15, line 35
| opts={CapTypeList=[Cap1, Cap2]})| | opts={CapTypeList=[Cap1, Cap2]})|
|---------------------------------->| |---------------------------------->|
| | | |
| | | |
| CAPS(seq=2, | | CAPS(seq=2, |
| opts={Cap1=Cap1Value, | | opts={Cap1=Cap1Value, |
| Cap2=Cap2Value}) | | Cap2=Cap2Value}) |
|<----------------------------------| |<----------------------------------|
| | | |
Figure 9: Query specific Cap Set Figure 9: Query specific Cap Set
This flow indicates the case where the Root probes for specific This flow indicates the case where the Root probes for specific
Capabilities of the peer node and the peer node responds with the Capabilities of the peer node and the peer node responds with the
value of indicated Capability set. value of indicated Capability set.
A.3. CAPS with partial Cap Set A.3. CAPS with partial Cap Set
Root 6LR/6LN Root 6LR/6LN
| | | |
| CAPQ(seq=3, | | CAPQ(seq=3, |
| opts={CapTypeList=[Cap1, Cap2, | | opts={CapTypeList=[Cap1, Cap2, |
| Cap3, Cap4]})| | Cap3, Cap4]})|
|---------------------------------->| |---------------------------------->|
| | | |
| | | |
| CAPS(seq=3, | | CAPS(seq=3, |
| opts={Cap2=Cap2Value, | | opts={Cap2=Cap2Value, |
skipping to change at page 15, line 26 skipping to change at page 16, line 19
|---------------------------------->| |---------------------------------->|
| | | |
| | | |
| CAPS(seq=3, | | CAPS(seq=3, |
| opts={Cap2=Cap2Value, | | opts={Cap2=Cap2Value, |
| Cap3=Cap3Value, | | Cap3=Cap3Value, |
| CapTypeList=[Cap1,Cap4]})| | CapTypeList=[Cap1,Cap4]})|
|<----------------------------------| |<----------------------------------|
| | | |
Partial Capability Set handshake Figure 10: Partial Capability Set handshake
Assume that Root queries for capabilities {Cap1, Cap2, Cap3, Cap4} Assume that Root queries for capabilities {Cap1, Cap2, Cap3, Cap4}
from the peer node. However the peer node does not support or does from the peer node. However the peer node does not support or does
not understand capability {cap1, cap4}. In this case the peer node not understand capability {cap1, cap4}. In this case the peer node
will respond back with value of Cap2 and Cap3 (which it understands) will respond back with value of Cap2 and Cap3 (which it understands)
and set the CapTypeList option with {Cap1, Cap4} type. and set the CapTypeList option with {Cap1, Cap4} type.
Authors' Addresses Authors' Addresses
Rahul Arvind Jadhav (editor) Rahul Arvind Jadhav (editor)
Marathahalli Huawei
Bangalore, Karnataka 560037 Kundalahalli Village, Whitefield,
Bangalore 560037
Karnataka
India India
Phone: +91-080-49160700
Email: rahul.ietf@gmail.com Email: rahul.ietf@gmail.com
Pascal Thubert Pascal Thubert
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D
45 Allee des Ormes - BP1200 45 Allee des Ormes - BP1200
MOUGINS - Sophia Antipolis 06254 06254 MOUGINS - Sophia Antipolis
France France
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Michael Richardson Michael Richardson
Sandelman Software Works Sandelman Software Works
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
Rabi Narayan Sahoo Rabi Narayan Sahoo
 End of changes. 77 change blocks. 
148 lines changed or deleted 165 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/