Subject: [Roll] Fwd: New Version Notification for draft-hui-6man-rpl-routing-header-00

From: Jonathan Hui <[email-masked]>
Date: Thu, 27 May 2010 09:20:31 -0700

To address RPL ticket #35, we submitted a draft to 6man that proposes  
a new IPv6 routing header to support source routing in non-storing mode.

Some high-level details:
- Format is derived from RH0
- Format is extended to support simple compression of IPv6 address  
entries within the routing header
- Use of the RPL routing header is constrained to a RPL domain.

http://tools.ietf.org/html/draft-hui-6man-rpl-routing-header-00

Comments appreciated as always.

--
Jonathan Hui

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: May 26, 2010 11:41:21 AM PDT
> To: [email-masked]
> Cc: [email-masked],[email-masked]
> Subject: New Version Notification for  draft-hui-6man-rpl-routing- 
> header-00
>
>
> A new version of I-D, draft-hui-6man-rpl-routing-header-00.txt has  
> been successfully submitted by Jonathan Hui and posted to the IETF  
> repository.
>
> Filename:	 draft-hui-6man-rpl-routing-header
> Revision:	 00
> Title:		 A Source Routing Header for RPL
> Creation_date:	 2010-05-26
> WG ID:		 Independent Submission
> Number_of_pages: 13
>
> Abstract:
> 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.
>
>
>
> The IETF Secretariat.
>
>

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Thu, 27 May 2010 19:47:23 +0300

Hi,

Two small questions/comments about the following text (on page 6)

else if Address[i] is not an neighboring node {
              send an ICMP Destination Unreachable, Code 3, message to
              the Source Address and discard the packet

1) How does a non-storing device knows Address[i] is not an neighboring
node? It is non storing...
2) Code 3 - should be Code 7?

also consider changing header from: "RPL Routing Header" to: "Source
Routing Header for RPL"

Best Regards,
Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jonathan Hui
Sent: Thursday, May 27, 2010 7:21 PM
To: ROLL WG
Subject: [Roll] Fwd: New Version Notification for
draft-hui-6man-rpl-routing-header-00

Some high-level details:

--
Jonathan Hui

> IPv6 Routing header type for delivering datagrams within a RPL

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 27 May 2010 09:56:35 -0700

> node? It is non storing...

Non-storing means that it doesn't store routes for the destination.  A  
node presumably needs to maintain some notion of neighbors, whether  
that's through ND or something similar.  At the very least, a node  
could try forwarding the datagram and if it fails then it could  
indicate that it is not a neighbor.

> 2) Code 3 - should be Code 7?

Yes, you are right.  We originally had Code 3, but through creating a  
new code would be more appropriate.

> also consider changing header from: "RPL Routing Header" to: "Source

To be completely descriptive, maybe something like "An IPv6 Routing  
Header for Source Routing with RPL".  We are describing a new IPv6  
Routing type after all.

--
Jonathan Hui

---

From: Yoav Ben-Yehezkel <[email-masked]>
Date: Thu, 27 May 2010 20:11:08 +0300

Jonathan,

"Non-storing means that it doesn't store routes for the destination."
OK, so another question is if it is a non-storing node, does it have to
have the route back to the source stored (I guess so, because of the RPL
mechanism, right?)? Or does it use the symmetric route back as indicated
on the packet? And if so, should the text indicate this?

"At the very least, a node  could try forwarding the datagram and if it
fails then it could indicate that it is not a neighbor."
I completely agree, but my question is whether the text should indicate
this explicitly to avoid confusion (one may understand this check is only
internal database oriented)?

Thanks,
Yoav

-----Original Message-----
From: Jonathan Hui [mailto:[email-masked]]
Sent: Thursday, May 27, 2010 7:57 PM
To: Yoav Ben-Yehezkel
Cc: ROLL WG
Subject: Re: [Roll] Fwd: New Version Notification for

--
Jonathan Hui

---

From: JP Vasseur <[email-masked]>
Date: Sun, 30 May 2010 09:59:56 +0200

If you have any comment on that simple draft, let us know by end of  
this week. Then in the absence of opposition
I'll close the ticket #35, since the draft will be discussed in 6man  
WG and will only be reference in the RPL specification.

On May 27, 2010, at 6:20 PM, Jonathan Hui wrote:

>
> To address RPL ticket #35, we submitted a draft to 6man that  
> proposes a new IPv6 routing header to support source routing in non- 
> storing mode.
>
> Some high-level details: