Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554

"Pascal Thubert (pthubert)" <> Thu, 21 June 2012 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DEF8221F86DD for <>; Thu, 21 Jun 2012 10:08:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -10.598
X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ry4ntvokVAxk for <>; Thu, 21 Jun 2012 10:08:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BCD2021F86DB for <>; Thu, 21 Jun 2012 10:08:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=13545; q=dns/txt; s=iport; t=1340298536; x=1341508136; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VGH1b8YPZ8Ec6TvMyo7sSuVgJ68IYrgw5BrozH5zYmk=; b=jk3gLjwPCPcLWJGoCNxtPWU7TmdXsr7AIT9seKo/GI79Rq9kHcx7h1ds DiEp9ZHxlCmknPbb+adYQtbYmOmVs6yQJkD6nGUIa/O2EAnMquMRCUUam A50LGcg3RFtg1K27wK6QEap3WqeDEfNrV24S7LcOzt2XrG46lx1O40xUX 0=;
X-IronPort-AV: E=Sophos; i="4.77,452,1336348800"; d="scan'208,217"; a="94642784"
Received: from ([]) by with ESMTP; 21 Jun 2012 17:08:56 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id q5LH8usF029310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Jun 2012 17:08:56 GMT
Received: from ([]) by ([]) with mapi id 14.02.0298.004; Thu, 21 Jun 2012 12:08:56 -0500
From: "Pascal Thubert (pthubert)" <>
To: Dario Tedeschi <>, Jonathan Hui <>
Thread-Topic: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554
Thread-Index: AQHNT8erVPW3MkC8Mke3tJq8Hxbtt5cE/SMg
Date: Thu, 21 Jun 2012 17:08:55 +0000
Deferred-Delivery: Thu, 21 Jun 2012 17:08:00 +0000
Message-ID: <>
References: <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-tm-as-product-ver: SMEX-
x-tm-as-result: No--39.108200-8.000000-31
x-tm-as-user-approved-sender: No
x-tm-as-user-blocked-sender: No
Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD807D093FFxmbrcdx01ciscoc_"
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Routing Over Low power and Lossy networks <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Jun 2012 17:09:00 -0000

Hi Dario:

The root might be using more than one path  to go to a target via a node Y. So even in a given instance there might be more than possible RH.
What the root needs to know is that connectivity from Y to child Z is broken. Then it can clean up all instances that use Y->Z.
Z can be found in the RH in the packet in error that should be passed with the ICMP. But that's not too practical.
It would be better if we had a new icmp error where Y could signal that connectivity to Z is lost.



From: [] On Behalf Of Dario Tedeschi
Sent: jeudi 21 juin 2012 18:05
To: Jonathan Hui
Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554

Hi Jonathan

Sorry, for late response to your email.

Consider the scenario where a DODAG root node supports two or more RPL instances under one prefix. Each instance providing different routing objectives (i.e. different objective functions). Potentially, the source-route to a destination under one instance can be different to the source-route to the same destination under a different instance. For example: Instance 1 could have a source-route R-->X-->Y-->D, while instance 2 could have a source-route R-->X-->Z-->D. Lets say node Y sent a Destination Unreachable ("Error in source-route") back to R, because D was unreachable from Y. How would R know which source-route needed repair and, consequently, which instance needed a DTSN update?


On 01/06/2012 7:46 PM, Jonathan Hui wrote:

I don't understand the need for knowing the RPLInstanceID when handling an ICMP Destination Unreachable error.  The SRH does not follow any RPL Instance, just the IPv6 addresses listed in the SRH.  Receiving an ICMP Destination Unreachable error from a node S simply means that S could not forward to the next IPv6 address in the SRH.  The inability of S to forward to the specified next hop would be true regardless of what RPL Instance the SRH was constructed from.

Jonathan Hui

On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote:

Yes, I noticed this as well. It is unfortunate because as you say, there is now no way to identify which instance a Error in SRH is for, and subsequently the root node can't just remove that routing entry in a specific instance. Instead it must either remove that entry from all instances or do nothing and wait for the next DAO to update the entry.


On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote:

I have observed that the RPLInstanceID field from Source Routing header (present in  draft-ietf-6man-rpl-routing-header-07) was removed in RFC6554.
Are there particular reasons for this? This field is necessary at the DODAG Root when it receives a  Destination Unreachable with code "Error in Source Routing Header" to identify the instance with the problem (only if there are two instances with the same prefix and if the node is Root in both of them).

Andreea Tecuceanu
(Freescale Semiconductor)


Roll mailing list<>

Roll mailing list<>