[Roll] Some confusions in RFC 6719 (MRHOF)
Duong Ngoc Nguyen <nduong@purdue.edu> Wed, 07 November 2012 19:55 UTC
Return-Path: <nduong@purdue.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 5F34C21F8850 for <roll@ietfa.amsl.com>; Wed, 7 Nov 2012 11:55:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 yjQnbOi9B9jx for <roll@ietfa.amsl.com>; Wed, 7 Nov 2012 11:55:19 -0800 (PST)
Received: from mailhub128.itcs.purdue.edu (mailhub128.itcs.purdue.edu [128.210.5.128]) by ietfa.amsl.com (Postfix) with ESMTP id A4D6F21F87F6 for <roll@ietf.org>; Wed, 7 Nov 2012 11:55:19 -0800 (PST)
Received: from mailhub022.itcs.purdue.edu (mailhub022.itcs.purdue.edu [128.210.5.22]) by mailhub128.itcs.purdue.edu (8.14.4/8.14.4/mta-nopmx.smtp.purdue.edu) with ESMTP id qA7JtI0l009756 for <roll@ietf.org>; Wed, 7 Nov 2012 14:55:18 -0500
Date: Wed, 07 Nov 2012 14:55:18 -0500
From: Duong Ngoc Nguyen <nduong@purdue.edu>
To: roll@ietf.org
Message-ID: <157212510.61589.1352318118568.JavaMail.root@mailhub022.itcs.purdue.edu>
In-Reply-To: <mailman.1872.1352129713.3373.roll@ietf.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [128.210.5.219]
X-Mailer: Zimbra 6.0.10_GA_2692 (ZimbraWebClient - SAF3 (Linux)/6.0.10_GA_2692)
X-PMX-Version: 5.5.9.388399
X-PerlMx-Virus-Scanned: Yes
Subject: [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, 07 Nov 2012 19:55:20 -0000
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. 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. A possible typo. Section 3.5 states: In the absence of a Metric Container, MRHOF uses ETX as its metric. It locally computes the ETX of links to its neighbors and adds this value to their advertised Rank to compute the associated Rank of routes... ==> Adding ETX of link and value of advertised rank is to compute cost of a route, not rank of a route. Rank of a route is computed by adding MinHopRankIncrease (instead of link's ETX) with advertised rank (as in section 3.3) Sincerely thanks, Duong Nguyen
- [Roll] Some confusions in RFC 6719 (MRHOF) Duong Ngoc Nguyen
- Re: [Roll] Some confusions in RFC 6719 (MRHOF) Philip Levis
- Re: [Roll] Some confusions in RFC 6719 (MRHOF) Duong Ngoc Nguyen