Re: [Roll] Some confusions in RFC 6719 (MRHOF)

Philip Levis <pal@cs.stanford.edu> Wed, 28 November 2012 21:27 UTC

Return-Path: <pal@cs.stanford.edu>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A67FA21F85C9 for <roll@ietfa.amsl.com>; Wed, 28 Nov 2012 13:27:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b-oPe-844sy0 for <roll@ietfa.amsl.com>; Wed, 28 Nov 2012 13:27:22 -0800 (PST)
Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 3082A21F86C6 for <roll@ietf.org>; Wed, 28 Nov 2012 13:27:22 -0800 (PST)
Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[10.111.222.25]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from <pal@cs.stanford.edu>) id 1TdpA8-0000Y5-RC; Wed, 28 Nov 2012 13:27:21 -0800
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset="us-ascii"
From: Philip Levis <pal@cs.stanford.edu>
In-Reply-To: <157212510.61589.1352318118568.JavaMail.root@mailhub022.itcs.purdue.edu>
Date: Wed, 28 Nov 2012 13:27:25 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <75DCAA86-EF9A-4401-B125-0FFC5E743667@cs.stanford.edu>
References: <157212510.61589.1352318118568.JavaMail.root@mailhub022.itcs.purdue.edu>
To: Duong Ngoc Nguyen <nduong@purdue.edu>
X-Mailer: Apple Mail (2.1283)
X-Scan-Signature: fb418a055a615a79fddacbea7bf2a8e8
Cc: roll@ietf.org
Subject: Re: [Roll] Some confusions in RFC 6719 (MRHOF)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/roll>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 28 Nov 2012 21:27:22 -0000

Phil

On Nov 7, 2012, at 11:55 AM, Duong Ngoc Nguyen wrote:

> As I work with MRHOF, I find some statements are not consistent that I cannot resolve by myself. I'm very grateful if someone can help me overcome this confusion.
> 
> 1. Which path cost is carried in Metric Container?
> 
> Section 3.2.2 states:
> 
>   Once the preferred parent is selected, the node sets its
>   cur_min_path_cost variable to the path cost corresponding to the
>   preferred parent.  The value of the cur_min_path_cost is carried in
>   the Metric Container corresponding to the selected metric when DIO
>   messages are sent.
> 
> ==> it suggests Metric Container carries the cost through the best (i.e. preferred) parent.
> 
> While section 3.4 states:
> 
>   Once the preferred parent is selected, the node sets its
>   cur_min_path_cost variable to the path cost corresponding to its
>   preferred parent.  It then calculates the metric it will advertise in
>   its metric container.  This value is the path cost of the member of
>   the parent set with the highest path cost.  Thus, while
>   cur_min_path_cost is the cost through the preferred parent, a node
>   advertises the highest cost path from the node to the root through a
>   member of the parent set.  The value of the highest cost path is
>   carried in the metric container corresponding to the selected metric
>   when DIO messages are sent.
> 
> ==> it suggests Metric Container carries the cost through the worst parent.

3.4 is correct.

> 2. Which value is written to Rank field of DIO messsage's base object in case ETX is used?
> 
> When ETX is the metric, node must not include Metric container, thus the rank field in DIO's base object is the only information to advertise to neighbors.
> 
> Section 3.4 states:
> 
>   If ETX is the selected metric, a node MUST NOT advertise it in a
>   metric container.  Instead, a node MUST advertise an approximation of
>   its ETX in its advertised Rank value, following the rules described
>   in Section 3.3...
> 
> ==> The phrase "in its advertised Rank value, following the rules described in Section 3.3." means we would write the value of node rank (computed by rules in section 3.3) into the rank field of DIO message.
> 
> On the other hand, section 3.5 states:
> 
>   ... Once parent selection and rank computation is performed
>   using the ETX metric, the node advertises the Rank and MUST NOT
>   include a metric container in its DIO messages.  While assigning Rank
>   in this case, use the representation of ETX described in [RFC6551],
>   i.e., assign Rank equal to ETX * 128.
> 
> ==> The phrase "assign Rank equal to ETX * 128" suggests that we should write value of ETX of path cost to the rank field of DIO message.
> 

3.4 is correct. The term "assign" is meant to describe the transformation between ETX and rank values, not the Rank in the DIO.

Phil