Pascal,
I agree that it is easier to swap the header before generating the response.
It also makes parsing the response on the root node easier, as the destination
address will be the address of the node that is no longer reachable.
Daniel.
-----Original Message-----
From: Pascal Thubert (pthubert) [mailto:[email protected]]
Sent: 07 January 2011 16:44
To: Daniel Gavelle; [email protected]; [email protected]
Subject: RE: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and
draft-ietf-6man-rpl-routing-header-01
Hi Daniel:
Thanks for the heads up.
The text in RPL assumes that the node receives a packet, processes the
RH (swaps the destination) and then forwards to the new next hop. If
that fails, it seems easier to pass the resulting packet as it now
stands than to recomputed the packet as it was received. I think the RH
draft should adapt to that . Would you agree?
Pascal
http://www.xtranormal.com/watch/7011357/
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf
Of
Daniel Gavelle
Sent: Friday, January 07, 2011 4:28 PM
To: [email protected]; [email protected]
Subject: [Roll] Discrepancy between draft-ietf-roll-rpl-17 and
draft-ietf-
6man-rpl-routing-header-01
A discrepancy between the ROLL and 6man-rpl-routing-header draft was
spotted a few weeks ago. I haven't seen any comments on this on the
ROLL
list. I've posted it to the 6Man list as it also affects a draft in
this WG. It is
important that everyone generates the destination unreachable in the
same
way because the RPL root node will process the destination unreachable
to
determine which link has failed.
Daniel.
-------- Original Message --------
Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-17.txt
Date: Fri, 17 Dec 2010 14:40:24 -0800
From: Dario Tedeschi<[email protected]>
To: [email protected]
CC: [email protected], [email protected]
References: <20101215230001.30256.8767.idtrac...@localhost>
There seems to be a discrepancy between draft-ietf-roll-rpl-17 and
draft-ietf-6man-rpl-routing-header-01:
The following pseudo code in the RPL RH draft:
else if i< n and Address[i] is not on-link {
send an ICMP Destination Unreachable, Code 7, message to
<--***
the Source Address and discard the packet
}
else {
swap the IPv6 Destination Address and Address[i]
<--***
if the IPv6 Hop Limit is less than or equal to 1 {
send an ICMP Time Exceeded -- Hop Limit Exceeded in
Transit message to the Source Address and discard the
packet
}
does not correlate with the following wording in the RPL draft
(section
11.2.2.3):
.... .... The "Error in Source Routing Header"
message has the
same format as the "Destination Unreachable Message" as specified
in
[RFC4443]. The portion of the invoking packet that is sent back
in
the ICMP message should record at least up to the routing header,
and
the routing header should be consumed by this node so that the
destination in the IPv6 header is the next hop that this node
could
<--***
not reach.
Dario
On 15/12/2010 3:00 PM, [email protected] wrote:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Routing Over Low power and Lossy
networks Working Group of the IETF.
Title : RPL: IPv6 Routing Protocol for Low power and
Lossy
Networks
Author(s) : T. Winter, et al.
Filename : draft-ietf-roll-rpl-17.txt
Pages : 159
Date : 2010-12-15
Low power and Lossy Networks (LLNs) are a class of network in which
both the routers and their interconnect are constrained. LLN
routers
typically operate with constraints on processing power, memory, and
energy (battery power). Their interconnects are characterized by
high
loss rates, low data rates, and instability. LLNs are comprised of
anything from a few dozen and up to thousands of routers.
Supported traffic flows include point-to-point (between devices
inside
the LLN), point-to-multipoint (from a central control point to a
subset of devices inside the LLN), and multipoint-to-point (from
devices inside the LLN towards a central control point). This
document specifies the IPv6 Routing Protocol for LLNs (RPL), which
provides a mechanism whereby multipoint-to-point traffic from
devices
inside the LLN towards a central control point, as well as point-to-
multipoint traffic from the central control point to the devices
inside the LLN, is supported. Support for point-to-point traffic is
also available.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-17.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Roll mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/roll
Regards,
Daniel.
--
__________________________________________________
Daniel Gavelle, Software Team Leader
Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors
Furnival
Street, Sheffield, S1 4QT, UK
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Comp Reg No: 3191371 - Registered In England http://www.nxp.com
http://www.jennic.com
__________________________________________________
_______________________________________________
Roll mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/roll
