Subject: [Roll] [roll] #25: RPL satisfying the MUST requirements

From: "roll issue tracker" <[email-masked]>
Date: Tue, 09 Mar 2010 04:51:50 -0000

#25: RPL satisfying the MUST requirements
--------------------------------+-------------------------------------------
 Reporter:  jpv@…               |       Owner:  jpv@…        
     Type:  task                |      Status:  new          
 Priority:  major               |   Milestone:               
Component:  rpl                 |     Version:               
 Severity:  Active WG Document  |    Keywords:               
--------------------------------+-------------------------------------------
 The Working has produced four "application-specific" requirements
 documents listing a series of "MUST", SHOULD and MAY using RFC 2119
 language.

 The object of this ticket is to track the list of MUST and make sure that
 RPL as specified in draft-ietf-roll-rpl meets (at least) the MUST
 requirements. This is currently being taken care of in the Appendix A:

 Appendix A. Requirements

 A.1. Protocol Properties Overview

 RPL demonstrates the following properties, consistent with the
 requirements specified by the application-specific requirements documents.

 A.1.1. IPv6 Architecture

 RPL is strictly compliant with layered IPv6 architecture.

 Winter, et al. Expires August 7, 2010 [Page 72]

 Internet-Draft draft-ietf-roll-rpl-06 February 2010

 Further, RPL is designed with consideration to the practical support and
 implementation of IPv6 architecture on devices which may operate under
 severe resource constraints, including but not limited to memory,
 processing power, energy, and communication. The RPL design does not
 presume high quality reliable links, and operates over lossy links
 (usually low bandwidth with low packet delivery success rate).

 A.1.2. Typical LLN Traffic Patterns

 Multipoint-to-Point (MP2P) and Point-to-multipoint (P2MP) traffic flows
 from nodes within the LLN from and to egress points are very common in
 LLNs. Low power and lossy network Border Router (LBR) nodes may typically
 be at the root of such flows, although such flows are not exclusively
 rooted at LBRs as determined on an application- specific basis. In
 particular, several applications such as building or home automation do
 require P2P (Point-to-Point) communication.

 As required by the aforementioned routing requirements documents, RPL
 supports the installation of multiple paths. The use of multiple paths
 include sending duplicated traffic along diverse paths, as well as to
 support advanced features such as Class of Service (CoS) based routing, or
 simple load balancing among a set of paths (which could be useful for the
 LLN to spread traffic load and avoid fast energy depletion on some, e.g.
 battery powered, nodes). Conceptually, multiple instances of RPL can be
 used to send traffic along different topology instances, the construction
 of which is governed by different Objective Functions (OF). Details of RPL
 operation in support of multiple instances are beyond the scope of the
 present specification.

 A.1.3. Constraint Based Routing

 The RPL design supports constraint based routing, based on a set of
 routing metrics and constraints. The routing metrics and constraints for
 links and nodes with capabilities supported by RPL are specified in a
 companion document to this specification, [I-D.ietf-roll-routing-metrics].
 RPL signals the metrics, constraints, and related Objective Functions
 (OFs) in use in a particular implementation by means of an Objective Code
 Point (OCP). Both the routing metrics, constraints, and the OF help
 determine the construction of the Directed Acyclic Graphs (DAG) using a
 distributed path computation algorithm.

 A.2. Deferred Requirements

 NOTE: RPL is still a work in progress. At this time there remain several
 unsatisfied application requirements, but these are to be addressed as RPL
 is further specified.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/roll/trac/ticket/25>
roll <http://tools.ietf.org/wg/roll/>