Hi Vishwas,
On May 31, 2010, at 11:14 AM, Vishwas Manral wrote:
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.
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?
Thanks.
--
Jonathan Hui
Thanks,
Vishwas
On Fri, May 28, 2010 at 10:52 PM, JP Vasseur <j...@cisco.com> 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: internet-dra...@ietf.org
Date: May 26, 2010 8:45:02 PM CEDT
To: i-d-annou...@ietf.org
Subject: I-D Action:draft-hui-6man-rpl-routing-header-00.txt
Reply-To: internet-dra...@ietf.org
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
i-d-annou...@ietf.org
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
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
