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 <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
--------------------------------------------------------------------
