Hi Jonathan, >> RFC2460 said: >> >> If, while processing a received packet, a node encounters a Routing >> header with an unrecognized Routing Type value, the required >> behavior of the node depends on the value of the Segments Left field, >> as follows: >> >> - If Segments Left is non-zero, the node must discard the packet >> and send an ICMP Parameter Problem, Code 0, message to the >> packet's Source Address, pointing to the unrecognized Routing >> Type. >> >> This means that packets will be dropped when a new header is encountered. > 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. >> Also in your particular case we are adding the header mid-way the >> reply should be probably sent to the RPL Border node as it added the >> header. We may want to add that field into the RH4 header too. > > 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. 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. Also do we intend to have only one node doing the insertion or not? 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 --------------------------------------------------------------------
