Hi Jonathan, There are two cases, where a node knows about the header but does not support its processing (Security or whatever reason). In that case we can add information like you said. Also in case we assume all RPL nodes have the stack as we define in the spec, we can assume the behavior.
So we can add the information you said but we should assume thatwe still may have cases where the behavior is not supported. Let us discuss the design offline and not burden the WG list with all possible options. We can focus the discussion on only one node adding the RH4 header. If we want to make that a constraint we should make that clear in the draft. Let us take this discussion offline. Thanks, Vishwas On Mon, May 31, 2010 at 12:34 PM, Jonathan Hui <[email protected]> wrote: > > Hi Vishwas, > > On May 31, 2010, at 12:05 PM, Vishwas Manral wrote: > >>> This should be OK for our intended usage of RH4 since it is constrained >>> to a >>> RPL routing domain. The current RPL specification requires all RPL >>> routers >>> to implement the source routing mechanism we are trying to specify. >> >> This is great. >> >>> Yes, we realized this after submitting the draft. One way is simply to >>> include the inserting nodes' address as Address[0] and set Segments Left >>> to >>> n-1. Doing so will make the inserting node a part of the "record route" >>> functionality given by the first "Segments Left" entries in a RH4. Do >>> you >>> think that is sufficient? >> >> This cannot work in all cases. If a node does not know the header it >> may not know that the address[0] is the inserting node address. > > If the node does not know the header when processing it, then it can't > utilize any information included in RH4. Did you have something else in > mind when you said "We may want to add that field into the RH4 header too" > in an earlier mail? > >> One thing that needs evaluated is are we ok sending a wrong >> information versus the case of filtering at the edge of RPL and not >> letting the wrong infromation propagate at all. > > We really intend the routing header to only be used within a RPL routing > domain hence the filtering rolls. So far, we are trying to stay very > focused on the needs of RPL. If there are other good use cases for RH4, > that's fine too - unless it adds complexity. > >> Also do we intend to have only one node doing the insertion or not? > > I would like to focus on the case where there is only one RH4 in the > datagram at a time. > > -- > Jonathan Hui > >> >> Thanks, >> Vishwas >> >>>> >>>> Thanks, >>>> Vishwas >>>> >>>> On Fri, May 28, 2010 at 10:52 PM, JP Vasseur <[email protected]> wrote: >>>>> >>>>> Dear all, >>>>> Let me share a bit of context about this ID. As some of you many know, >>>>> the >>>>> ROLL WG >>>>> (http://datatracker.ietf.org/wg/roll/charter/) >>>>> is specifying a new routing protocol called RPL in Low power and Lossy >>>>> Networks (LLNs: >>>>> also referred to as Sensor Networks), where nodes are usually >>>>> constrained >>>>> in >>>>> terms of >>>>> memory, processing power, ... and are interconnected with lossy links >>>>> (links >>>>> flapping, >>>>> high error rates, ...). The base specifications of RPL >>>>> (http://datatracker.ietf.org/doc/draft-ietf-roll-rpl/) >>>>> is maturing with the aim to Last Call it in July. Some of these >>>>> networks >>>>> comprise nodes >>>>> that are highly constrained and cannot even store routing tables, in >>>>> which >>>>> case, it is >>>>> necessary to perform source routing (as a matter of fact, several of >>>>> the >>>>> proprietary >>>>> solutions deployed so far are using source routing for this kind of >>>>> environment). So the >>>>> whole point of this simple ID is to propose a new Routing Header. The >>>>> proposal (RH4) >>>>> is in many ways similar to the RH0 (minus the security issues since RH4 >>>>> can >>>>> only be >>>>> used within LLNs) and we added a very simple compression scheme too. >>>>> Comments/suggestions/... would be extremely welcome since this RH is >>>>> critical for ROLL. >>>>> Thanks. >>>>> JP. >>>>> Begin forwarded message: >>>>> >>>>> From: [email protected] >>>>> Date: May 26, 2010 8:45:02 PM CEDT >>>>> To: [email protected] >>>>> Subject: I-D Action:draft-hui-6man-rpl-routing-header-00.txt >>>>> Reply-To: [email protected] >>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>> directories. >>>>> >>>>> Title : A Source Routing Header for RPL >>>>> Author(s) : J. Hui, et al. >>>>> Filename : draft-hui-6man-rpl-routing-header-00.txt >>>>> Pages : 13 >>>>> Date : 2010-05-26 >>>>> >>>>> In Low power and Lossy Networks (LLNs), memory constraints on routers >>>>> may limit them to maintaining at most a few routes. In some >>>>> configurations, it is necessary to use these memory constrained >>>>> routers to deliver datagrams to nodes within the LLN. The Routing >>>>> for Low Power and Lossy Networks (RPL) protocol can be used in some >>>>> deployments to store most, if not all, routes on one (e.g. the >>>>> Directed Acyclic Graph (DAG) root) or few routers and forward the >>>>> IPv6 datagram using a source routing technique to avoid large routing >>>>> tables on memory constrained routers. This document specifies a new >>>>> IPv6 Routing header type for delivering datagrams within a RPL >>>>> domain. >>>>> >>>>> A URL for this Internet-Draft is: >>>>> >>>>> >>>>> http://www.ietf.org/internet-drafts/draft-hui-6man-rpl-routing-header-00.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. >>>>> _______________________________________________ >>>>> I-D-Announce mailing list >>>>> [email protected] >>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>> Internet-Draft directories: http://www.ietf.org/shadow.html >>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>> >>>>> >>>>> -------------------------------------------------------------------- >>>>> IETF IPv6 working group mailing list >>>>> [email protected] >>>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>>> -------------------------------------------------------------------- >>>>> >>>>> >>>> -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> [email protected] >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> -------------------------------------------------------------------- >>> >>> > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
