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: roll-boun...@ietf.org [mailto:roll-boun...@ietf.org] On Behalf Of > Daniel Gavelle > Sent: Friday, January 07, 2011 4:28 PM > To: r...@ietf.org; ipv6@ietf.org > 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 <d...@exegin.com> > To: internet-dra...@ietf.org > CC: r...@ietf.org, i-d-annou...@ietf.org > 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, internet-dra...@ietf.org 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 > > r...@ietf.org > > 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 > r...@ietf.org > https://www.ietf.org/mailman/listinfo/roll -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
