Subject: [Roll] Subnet Gateway Protocol

From: Ulrich Herberg <[email-masked]>
Date: Thu, 11 Nov 2010 14:13:17 +0800

Hi,

I just became aware during the ROLL meeting, that there is a "Subnet Gateway
Protocol" contained in RPL, but I did not really find a description of that
in the draft (there is some general description in section 1.2, but that
still leaves open many questions). A few that came to my mind:
  - how does the Subnet Gateway Protocol work in detail?
  - are classical link properties kept? (some being mentioned in RFC 4903)
If a node sends a link-local multicast, will all other nodes within the same
subnet receive the packets? Without TTL decrement? Is the same prefix
on-link for all interfaces on the link?
  - Is ROLL chartered to include ND/autoconfiguration into RPL? Does it
belong in the same spec?

Ulrich

P.S: I did not find the RPL slides in the "materials" list of the IETF web
page. Will they be available for download?

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 11 Nov 2010 14:32:59 +0800

Hi Ulrich,

On Nov 11, 2010, at 14:13, Ulrich Herberg wrote:

> Hi,
> 
> I just became aware during the ROLL meeting, that there is a "Subnet Gateway Protocol" contained in RPL, but I did not really find a description of that in the draft (there is some general description in section 1.2, but that still leaves open many questions). A few that came to my mind:

I also don't know what an SGP is.

But I do know how 6LoWPAN works and how its subnet is kept together.

First of all, I probably don't need to point you to RFC 5889.

>   - are classical link properties kept? (some being mentioned in RFC 4903)

Not all of them.  Because 6LoWPAN is not used for general Internet access, this is a bit less of a problem than it would be for, say, laptop Internet access.

> If a node sends a link-local multicast, will all other nodes within the same subnet receive the packets?

No.  Just the nodes in the radio range.

> Without TTL decrement?

(N/A)

> Is the same prefix on-link for all interfaces on the link?

No.  (All prefixes are off-link.)

>   - Is ROLL chartered to include ND/autoconfiguration into RPL? Does it belong in the same spec? 

No.  

No (but that's just my personal technical judgement).

Gruesse, Carsten

---

From: JP Vasseur <[email-masked]>
Date: Thu, 11 Nov 2010 17:35:00 +0800

Let me clarify - This is ONLY a term that was used during the presentation trying to explain how PIO/RA works in reply to an IESG 
DISCUSS. We're working on clarifying this soon, but there IS NO CHANGE is how RPL works. Just clarification.

Thanks.

JP.

On Nov 11, 2010, at 2:13 PM, Ulrich Herberg wrote:

>   - are classical link properties kept? (some being mentioned in RFC 4903) If a node sends a link-local multicast, will all other nodes within the same subnet receive the packets? Without TTL decrement? Is the same prefix on-link for all interfaces on the link?
> P.S: I did not find the RPL slides in the "materials" list of the IETF web page. Will they be available for download?
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: David Culler <[email-masked]>
Date: Thu, 11 Nov 2010 13:22:32 -0800

Indeed, the RPL document is what defines the protocol.  It does not contain a "subnet gateway protocol".

>> P.S: I did not find the RPL slides in the "materials" list of the IETF web page. Will they be available for download?

David Culler
[email-masked]
Chair Computer Science
Associate Chair EECS

---

From: Ulrich Herberg <[email-masked]>
Date: Fri, 12 Nov 2010 13:08:28 +0800

Thanks for the clarification. I have misunderstood the presentation
that this would become part of RPL. I am still a bit confused about
the following sentence in section 1.1 of RPL:

"RPL also introduces the
   capability to bind a subnet together and route within that subnet."

Does that preserve the subnet model (with respect to issues mentioned
in RFC4903)? Why does RPL need to "route within a subnet"? In a
subnet, routing is not required, TTL is not decremented.

Ulrich

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Nov 2010 14:52:03 +0800

On Nov 12, 2010, at 13:08, Ulrich Herberg wrote:

> RFC4903

The more interesting RFC here may be RFC 5889.
RFC 4903 describes why multi-link subnets are not trivial.
RFC 5889 describes a model for multi-link subnets that is used e.g. in 6LoWPANs.

> Why does RPL need to "route within a subnet"?

It may have to when the subnet is built out of of multiple links.

> In a subnet, routing is not required, TTL is not decremented.

One a single link, routing is not required (at least not at the L3 level of that link -- it may very well be required *within the implementation* of that link, which may be another network, based on its own IP addresses or something else).

A subnet composed out of multiple links does require some forwarding, which may be supported by a routing protocol such as RPL.

Gruesse, Carsten

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 12 Nov 2010 22:45:57 +0100

Le 12/11/2010 07:52, Carsten Bormann a écrit :
> The more interesting RFC here may be RFC 5889. RFC 4903 describes why
> multi-link subnets are not trivial. RFC 5889 describes a model for
> multi-link subnets that is used e.g. in 6LoWPANs.
>
> One a single link, routing is not required (at least not at the L3
> level of that link -- it may very well be required *within the
> implementation* of that link, which may be another network, based on
>  its own IP addresses or something else).
>
> A subnet composed out of multiple links does require some
> forwarding,

hmm... 'some forwarding'.

Forwarding is when a packet is transmitted from left to right, assuming
right and left are distinct media.

A packet heard on an interface and repeated on the same interface is not
forwarding.

Forwarding using a single interface interferes with the originator.

If forwarding using two interfaces then multiple links per subnet are
not needed - there are multiple subnets, and that is good.

(by 'forwarding' I assume 'IP forwarding').

> which may be supported by a routing protocol such as RPL.

May it be...

Alex

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

---

From: Ulrich Herberg <[email-masked]>
Date: Mon, 15 Nov 2010 11:32:40 +0100

Carsten,

> The more interesting RFC here may be RFC 5889.

I agree that RFC 5889 should apply to RPL router interfaces, but here
we are talking about subnets for hosts, so I see that as a separate
problem.

> It may have to when the subnet is built out of of multiple links.

Well, I think that this is a very complicated issue (we discussed
about that a lot in AUTOCONF this IETF). And moreover, it is a
routing-protocol-independent issue.

> A subnet composed out of multiple links does require some forwarding, which may be supported by a routing protocol such as RPL.

Yes, it would require some forwarding, either on L2 or some L3
tunneling to preserve the IP header (and guarantee that TTL is not
decremented, and that link-local broadcast works correctly). It is
non-trivial to preserve the link-model, allow aggregation of routes
and correct routing within the RPL network if hosts preserve their
address and "move" to another router (handover, mobile IP?, security
issues,..). I definitely think that it is out of scope of a routing
protocol, and is not well described in the RPL draft (only a few
sentences in section 1.1 of RPL). The flexible "message option" format
of RPL would allow to allow forwarding of RIO/PIOs while specifying it
outside of RPL in another spec.

This would allow to 1) specify the exact behavior of splitting a
subnet in another spec (if such splitting is wanted, which I am not
convinced), and to 2) reduce the overhead of the RPL spec. I have
already mentioned here on the list that I am convinced that the RPL
draft is far too overloaded. I would much rather prefer a single
framework draft and several optional or mandatory modules (such as
upward routes, storing mode, non-storing, security extension,...).
Splitting out the subnet issue would at least reduce the size of the
draft. And I think for a "standards track" document, the subnet
splitting is not well understood enough anyways.

Ulrich

---

From: "Anders Brandt" <[email-masked]>
Date: Wed, 17 Nov 2010 14:50:45 +0100

Dear P2P'ers 

The current RPL P2P draft
http://tools.ietf.org/html/draft-dt-roll-p2p-rpl-02

appears to be a little unclear on the terms

* hop-by-hop route
* source route
* RPL Storing mode
* RPL Non-storing mode

The introduction does a nice job of explaining the
difference of the two uncompatible modes but forgets
to point out the detail that the
RPL Non-storing mode is using source routes while
RPL Storing mode implements hop-by-hop routes.

Since a given implementation is going to be either
non-storing or storing one may consider having
dedicated sections (or documents?) explaining
what is required for making a system work for
non-storing or storing mode, respectively.

Obviously, the frame format descriptions should 
be common.

Just my $.05

---

From: Philip Levis <[email-masked]>
Date: Wed, 17 Nov 2010 09:14:24 -0800

> Obviously, the frame format descriptions should

I think it make sense to keep them as separate sections of the same  
document. They should definitely be separate, concrete sections,  
though. I think there's always a push to break things up into many  
tiny documents because of short attention spans. But it's easier to  
keep them consistent in a single document, and the aggregate length  
is shorter.

Phil

---

From: Mukul Goyal <[email-masked]>
Date: Wed, 17 Nov 2010 13:48:15 -0600 (CST)

Hi Anders,

[Anders]

* hop-by-hop route
* source route
* RPL Storing mode
* RPL Non-storing mode

[Mukul]

The introduction section does say that

"In non-storing mode operation, only the DAG root maintains downward routing
   information and hence a packet travels all the way to the DAG root,
   which then sends it towards its destination using a source route."

Then it describes the storing mode operation

"In storing mode operation, if the destination is a DAG descendant and
   the source maintains "downwards" routing state about this descendant,
   it can forward the packet along this route.  Otherwise, the source
   sends the packet to a DAG parent, which then applies the same set of
   rules to forward the packet further."

I guess I could modify the first sentence as follows

"In storing mode operation, if the destination is a DAG descendant and
   the source maintains "downwards" HOP-BY-HOP routing state about this descendant,
   it can forward the packet along this route..."

Would this change be sufficient?

[Anders]

[Mukul]

Are you suggesting that hop-by-hop P2P routes can not be used in an LLN using non-storing mode RPL operation? It seems to me that both types of P2P routes (hop-by-hop; source) can be used irrespective of whether core RPL operation is storing mode or non-storing mode.

Thanks
Mukul

---

From: "Anders Brandt" <[email-masked]>
Date: Thu, 18 Nov 2010 11:42:01 +0100

Hi Mukul

(see inline)

Cheers,
  Anders 

> -----Original Message-----
> From: Mukul Goyal [mailto:[email-masked]] 
> Sent: Wednesday, November 17, 2010 20:48
> To: Anders Brandt
> Cc: ROLL WG
> Subject: Re: [Roll] RPL P2P - Clarify that hop-by-hop is 
> identical to RPLStoring mode
> 
> Hi Anders,
> 
> [Anders]
> 
> The introduction does a nice job of explaining the difference 
> of the two uncompatible modes but forgets to point out the 
> detail that the RPL Non-storing mode is using source routes 
> while RPL Storing mode implements hop-by-hop routes.
> 
> [Mukul]
> 
>    it can forward the packet along this route."
> 

[Anders]

Yes, this definitely helps. But the last part
" ...forward the packet along this route."
seems to mix things up.

May I suggest:
" ...forward the packet to a descendant router closer to the
destination..."

> non-storing or storing one may consider having dedicated 
> sections (or documents?) explaining what is required for 
> making a system work for non-storing or storing mode, respectively.
> 
> [Mukul]
> 
> Are you suggesting that hop-by-hop P2P routes can not be used 
> in an LLN using non-storing mode RPL operation? It seems to 
> me that both types of P2P routes (hop-by-hop; source) can be 
> used irrespective of whether core RPL operation is storing 
> mode or non-storing mode.
> 
> Thanks
> Mukul
>

---

From: Mukul Goyal <[email-masked]>
Date: Fri, 19 Nov 2010 08:03:22 -0600 (CST)

Hi Anders

I will include the change in the next version.

Thanks
Mukul

----- Original Message -----
From: "Anders Brandt" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>
Sent: Thursday, November 18, 2010 4:42:01 AM
Subject: RE: [Roll] RPL P2P - Clarify that hop-by-hop is identical to RPLStoring mode

Hi Mukul

(see inline)

Cheers,
  Anders 

[Anders]

May I suggest: