Subject: Re: [Roll] Next items ...

From: Mukul Goyal <[email-masked]>
Date: Tue, 1 Sep 2009 15:24:47 -0500 (CDT)

Pascal,

Just need a clarification.

Quoating from your response:
"I would assume that a listener would use MLD over its link to its router."

The implication seems to be that in an LLN running a "roll over" routing protocol, some nodes may not be routers. That is against my understanding that a "roll over" protocol considers all LLN nodes to be routers. Isn't it so? 

If "mesh under" routing were available, I would think that some LLN nodes may not be "roll over" routers. But it seems that there is not going to be any "mesh under" routing available any time soon. Hence, my understanding is that all LLN nodes would be "roll over" routers.

Please clarify.

Thanks
Mukul
 
----- Original Message -----
From: "Pascal Thubert (pthubert)" <[email-masked]>
To: "nicolas riou" <[email-masked]>, [email-masked]
Sent: Wednesday, August 26, 2009 11:03:57 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Next items ...

Salut Nicolas, 

Yes we need to beef up the description of multicast. 

Basically you can see DAO as a transport for MLD registrations. I would assume that a listener would use MLD over its link to its router. If the router is using ROLL, it would carry that registration as a DAO to its parent(s). Note that strictly speaking that should be only one parent (the preferred one) so we have real mcast tree. Note that passing the registration to multiple parents improves the reliability but is more costly and a pruning process is required. 

At the same time, the router populates its MRIB/MFIB so that it keeps an entry to forward a mcast packet to all its children router that passed a DAO, as well as all the attached node that registered. 

For unicast, It is expected that the sink of the RPL DAG terminates RPL and inject RPL routes in the infrastructure using whatever protocol is used there. For mcast/IPv6 the sink can proxy MLDV2/3 for all the nodes attached to the RPL routers ( that’s needed iff the source can be in the infrastructure). For such a source, the packet will be replicated has it flows down the preferred tree along the states installed from the DAO. 

For a source inside the DAG, the packet is passed up the tree and to all the registered children but the one that passed the packet. Then again, if there is a listener in the infrastructure then the sink has to propagate the packet in the infrastructure. 

Makes sense? 

Pascal 

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked] 
Sent: mercredi 12 août 2009 22:43 
To: [email-masked] 
Cc: [email-masked] 
Subject: Re: [Roll] Next items ... 

Hi DT and rollers, 

I’m arriving a bit late on the mailing list but I would like to say that I fully support Jerry and Mukul regarding P2P support. Efficient P2P support is essential for building application systems, especially for time-sensitive applications (lighting control, fire…). 
Beyond P2P, I would also like to get better understanding on multicast support with RPL. Even though multicast should be avoided when possible in a LLNs, it is still required for multiple building automation applications (to control banks of lights simultaneously, to control complex and time-sensitive automation scenes, to quickly trigger emergency procedures and disseminate information to multiple devices…) and to allow for future publish/subscribe architectures. In building scenarios, multicast traffic will not necessarily be initiated from the DAG root toward leaves but from any arbitrary node in the lowpan to a group of arbitrary nodes. Except in section 3.3.3.1 “DAO can convey multicast listeners”, the draft provides little information on how multicast traffic will be spread. Is it possible to get some more details on multicast support in RPL? Is it conceivable to operate MLD into lowpans (I assume no), else is there any plan to define a tailored lightweight MLD protocol to avoid flooding the whole network and irrigate only zones where multicast flow subscribers exist? 

Thanks and Best regards, 
Nicolas 
_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 2 Sep 2009 09:57:46 +0200

Hi Mukul,

Please see below

>The implication seems to be that in an LLN running a "roll over" routing protocol, some nodes may not be
>routers. That is against my understanding that a "roll over" protocol considers all LLN nodes to be routers.
>Isn't it so?

In the IP world, the traditional model is hosts attached to routers, and routing happening between routers. I do not see why ROLL would be any different. RPL defines a routing protocol between routers. Why would that imply that no host can be attached to the routers?

>If "mesh under" routing were available, I would think that some LLN nodes may not be "roll over" routers. But
>it seems that there is not going to be any "mesh under" routing available any time soon. Hence, my
>understanding is that all LLN nodes would be "roll over" routers.

There are very few mesh under solutions in the IP world today. Mostly FR and ATM. And we learnt a few things from that including that it is very hard to make good routing decisions at L3 when L2 has hidden costs in a switched topology. 

So I agree that ROLL is not about mesh under though RPL could probably be adapted at layer 2. 

>Please clarify.

Whether you can connect hosts to a router and whether a L2 network relies on mesh under are orthogonal concepts. Are you opposing them in any fashion?

>Basically you can see DAO as a transport for MLD registrations. I would assume that a listener would use MLD
>over its link to its router. If the router is using ROLL, it would carry that registration as a DAO to its
>parent(s). Note that strictly speaking that should be only one parent (the preferred one) so we have real
>mcast tree. Note that passing the registration to multiple parents improves the reliability but is more costly
>and a pruning process is required.
>
>
>
>At the same time, the router populates its MRIB/MFIB so that it keeps an entry to forward a mcast packet to
>all its children router that passed a DAO, as well as all the attached node that registered.
>
>
>
>For unicast, It is expected that the sink of the RPL DAG terminates RPL and inject RPL routes in the
>infrastructure using whatever protocol is used there. For mcast/IPv6 the sink can proxy MLDV2/3 for all the
>nodes attached to the RPL routers ( that’s needed iff the source can be in the infrastructure). For such a
>source, the packet will be replicated has it flows down the preferred tree along the states installed from the
>DAO.
>
>
>
>For a source inside the DAG, the packet is passed up the tree and to all the registered children but the one
>that passed the packet. Then again, if there is a listener in the infrastructure then the sink has to
>propagate the packet in the infrastructure.
>
>
>
>
>Makes sense?
>
>
>
>Pascal
>
>
>
>
>I’m arriving a bit late on the mailing list but I would like to say that I fully support Jerry and Mukul
>regarding P2P support. Efficient P2P support is essential for building application systems, especially for
>time-sensitive applications (lighting control, fire…).
>Beyond P2P, I would also like to get better understanding on multicast support with RPL. Even though multicast
>should be avoided when possible in a LLNs, it is still required for multiple building automation applications
>(to control banks of lights simultaneously, to control complex and time-sensitive automation scenes, to
>quickly trigger emergency procedures and disseminate information to multiple devices…) and to allow for future
>publish/subscribe architectures. In building scenarios, multicast traffic will not necessarily be initiated
>from the DAG root toward leaves but from any arbitrary node in the lowpan to a group of arbitrary nodes.
>Except in section 3.3.3.1 “DAO can convey multicast listeners”, the draft provides little information on how
>multicast traffic will be spread. Is it possible to get some more details on multicast support in RPL? Is it
>conceivable to operate MLD into lowpans (I assume no), else is there any plan to define a tailored lightweight
>MLD protocol to avoid flooding the whole network and irrigate only zones where multicast flow subscribers
>exist?
>
>Thanks and Best regards,
>Nicolas

---

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Sep 2009 09:15:31 -0400

>>>>> "Pascal" == Pascal Thubert <(pthubert)" <[email-masked]>> writes:
    Pascal> Hi Mukul,

    Pascal> Please see below

    >> Quoating from your response: "I would assume that a listener
    >> would use MLD over its link to its router."
    >> 
    >> The implication seems to be that in an LLN running a "roll over"
    >> routing protocol, some nodes may not be routers. That is against
    >> my understanding that a "roll over" protocol considers all LLN
    >> nodes to be routers.  Isn't it so?

    Pascal> In the IP world, the traditional model is hosts attached to
    Pascal> routers, and routing happening between routers. I do not see
    Pascal> why ROLL would be any different. RPL defines a routing
    Pascal> protocol between routers. Why would that imply that no host
    Pascal> can be attached to the routers?

  My understanding is that one perfers all devices to be able to act as
routers.  My reading of RPL is that a device which does not participate
in the protocol will not be reachable by other nodes, as it wont be in
the DAG.

  Although I would imagine that the RA/DIO's emitted by most devices
will be announcing self-address/128, I can see that a device could be
acting as a router for a number of other devices which are directly
reachable to it (for instance, maybe reachable by wired connections).

  (I intentionally used the word "device" with roles "router" and "host")

- -- 
]       He who is tired of Weird Al is tired of life!           |  firewalls  [
]   Michael Richardson, Sandelman Software Works, Ottawa, ON    |net architect[
] [email-masked] http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 3 Sep 2009 09:28:52 +0200

Hi Michael:

Please see below

>in the protocol will not be reachable by other nodes, as it wont be in

You seem to have a host oriented vision. DAOs can carry prefixes, for
instance /64 just the way they can carry addresses or mcast groups being
listened to ("/128s"). In that case a host attached to a router is
reachable at an address that it autoconfs from the router's /64. Nothing
new. 

>reachable to it (for instance, maybe reachable by wired connections).

Or you can use RPL in the context of 6LoWPAN (see
http://www.ietf.org/id/draft-ietf-6lowpan-nd-05.txt)
In that case the router learns the host global address from the ND
registration process and injects it as a specific DAO.

The protocol does not dictate any deployment, like address only, mcast
only, or whatever.

Cheers,

Pascal

---

From: JP Vasseur <[email-masked]>
Date: Thu, 3 Sep 2009 15:09:05 +0200

Adding a few words on the subject matter

On Sep 2, 2009, at 9:57 AM, Pascal Thubert (pthubert) wrote:

>> routing protocol, some nodes may not be
>> routers. That is against my understanding that a "roll over"  
>> protocol considers all LLN nodes to be routers.
>> Isn't it so?
>
> In the IP world, the traditional model is hosts attached to routers,  
> and routing happening between routers. I do not see why ROLL would  
> be any different. RPL defines a routing protocol between routers.  
> Why would that imply that no host can be attached to the routers?
>
>> If "mesh under" routing were available, I would think that some LLN  
>> nodes may not be "roll over" routers. But
> There are very few mesh under solutions in the IP world today.  
> Mostly FR and ATM. And we learnt a few things from that including  
> that it is very hard to make good routing decisions at L3 when L2  
> has hidden costs in a switched topology.
>

This is a bit of funny discussion. Mukul you seem surprised to hear  
that RPL is an IP routing protocol ? Yes it is. If you decide you run  
another routing protocol at L2, it will be transparent to RPL. I  
personally think that multi-layer routing in this context in a  
complete non-sense (look at how difficult it is in non constrained  
environments) but this is another story.

>
>> Please clarify.
>
>
> Whether you can connect hosts to a router and whether a L2 network  
> relies on mesh under are orthogonal concepts.

Indeed.

> Are you opposing them in any fashion?
>
>> Thanks
>> Mukul
>>
>> Basically you can see DAO as a transport for MLD registrations. I  
>> would assume that a listener would use MLD
>> parent(s). Note that strictly speaking that should be only one  
>> parent (the preferred one) so we have real
>> mcast tree. Note that passing the registration to multiple parents  
>> improves the reliability but is more costly
>> At the same time, the router populates its MRIB/MFIB so that it  
>> keeps an entry to forward a mcast packet to
>> infrastructure using whatever protocol is used there. For mcast/ 
>> IPv6 the sink can proxy MLDV2/3 for all the
>> nodes attached to the RPL routers ( that’s needed iff the source  
>> can be in the infrastructure). For such a
>> source, the packet will be replicated has it flows down the  
>> preferred tree along the states installed from the
>> DAO.
>>
>>
>>
>> For a source inside the DAG, the packet is passed up the tree and  
>> to all the registered children but the one
>> From: [email-masked] [mailto:[email-masked]] On  
>> Behalf Of [email-masked]
>> regarding P2P support. Efficient P2P support is essential for  
>> building application systems, especially for
>> Beyond P2P, I would also like to get better understanding on  
>> multicast support with RPL. Even though multicast
>> should be avoided when possible in a LLNs, it is still required for  
>> multiple building automation applications
>> quickly trigger emergency procedures and disseminate information to  
>> multiple devices…) and to allow for future
>> publish/subscribe architectures. In building scenarios, multicast  
>> traffic will not necessarily be initiated
>> multicast traffic will be spread. Is it possible to get some more  
>> details on multicast support in RPL? Is it
>> conceivable to operate MLD into lowpans (I assume no), else is  
>> there any plan to define a tailored lightweight

---

From: [email-masked]
Date: Thu, 3 Sep 2009 09:42:16 -0500

JP, All,

I guess I am confused on this issue too. 

As Mukal, my understanding was that all RPL nodes in the DAG are IP 
Routers, not hosts.  Yes, I agree that there could be implementations 
where a DAG IP Router could have wired hosts attached; however due to the 
bandwidth and resource constraints of these devices, this would be 
atypical.  In any case, these wired devices would not be part of the DAG. 
Hence, for all intents and purposes the LLN is composed of all IP routers 
which are all members of the DAG.  Is this true?

If this is true, then I'm confused of the MLD protocol.  I thought that 
MLD was a protocol where hosts proxied through its router for multicast 
messages.  If the LLN is made up of entirely of IP routers, then I don't 
understand where MLD comes in.  Do the routers somehow also register 
themselves to some 'uber' router to form some sort of router tree?

Furthermore, MLD seems to be a protocol in the wrong direction.  It seems 
to expect that every destination device somehow know a priori what 
multicast groups to which it belongs.  In the commercial building world, a 
typical multicast application would be a lighting panel controlling banks 
of lights.  Multicast is required since the lights need all come on 
instantly in unison.  If unicast was used, the lights would come on 
individually over time.  So the lighting panel will source a multicast 
packet to a group of lights.  The lighting panel knows a priori the 
members of the multicast group, not the lights.  The lights themselves are 
dumb and will turn on when they get the packet.  We could ill afford to 
have to go to every lighting fixture in the building and program it every 
time a new lighting scene was required.

Jerry

JP Vasseur <[email-masked]> 
Sent by: [email-masked]
09/03/2009 08:10 AM

To
Mukul Goyal <[email-masked]>, "Pascal Thubert (pthubert)" 
<[email-masked]>
cc
ROLL WG <[email-masked]>, nicolas riou 
<[email-masked]>
Subject
Re: [Roll] Next items ...

Indeed.

>> nodes attached to the RPL routers ( that?s needed iff the source 
>> I?m arriving a bit late on the mailing list but I would like to say 
>> that I fully support Jerry and Mukul
>> time-sensitive applications (lighting control, fire?).
>> multiple devices?) and to allow for future
>> Except in section 3.3.3.1 ?DAO can convey multicast listeners?, the 
>> draft provides little information on how

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 3 Sep 2009 09:54:07 -0500 (CDT)

JP,

Please read my two messages on this issue carefully and provide the clarification I asked for. May I also suggest a little more civility in your replies as you are WG chair.

Thanks
Mukul

----- Original Message -----
From: "JP Vasseur" <[email-masked]>
To: "Mukul Goyal" <[email-masked]>, "Pascal Thubert (pthubert)" <[email-masked]>
Cc: "ROLL WG" <[email-masked]>, "nicolas riou" <[email-masked]>
Sent: Thursday, September 3, 2009 8:09:05 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Next items ...

Indeed.

---

From: Emmanuel Baccelli <[email-masked]>
Date: Thu, 3 Sep 2009 18:49:52 +0200

Hi JP,

On Thu, Sep 3, 2009 at 3:09 PM, JP Vasseur <[email-masked]> wrote:

> This is a bit of funny discussion. Mukul you seem surprised to hear that
> RPL is an IP routing protocol ? Yes it is. If you decide you run another
> routing protocol at L2, it will be transparent to RPL. I personally think
> that multi-layer routing in this context in a complete non-sense (look at
> how difficult it is in non constrained environments) but this is another
> story.
>
>

Jumping into this discussion, and looking back at the trail, I guess that
what Mukul wanted to know originally was the following (Mukul, please
correct me if I am wrong).

Concerning the targeted sensor network scenarios, what are we going after?

(i) ALL of the sensors IP routers, or
(ii) only SOME of the sensors are IP routers.

>From what I can gather, I suppose ROLL is targeting (i). Is it correct?

Regards,

Emmanuel

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 3 Sep 2009 19:19:40 +0200

Salut Emmanuel:

>From what I can gather, I suppose ROLL is targeting (i). Is it correct?

I have not seen the point where such an assumption (i) or (ii) was necessary. 

And that is neither the 6LoWPAN model nor the 802.15.4 FFD/RFD model.

Maybe a given deployment will have such constraint but the routing protocol itself is certainly agnostic.

A bientôt,

Pascal

From: [email-masked] [mailto:[email-masked]] On Behalf Of Emmanuel Baccelli
Sent: jeudi 3 septembre 2009 18:50
To: [email-masked]
Subject: Re: [Roll] Next items ...

Hi JP,

This is a bit of funny discussion. Mukul you seem surprised to hear that RPL is an IP routing protocol ? Yes it is. If you decide you run another routing protocol at L2, it will be transparent to RPL. I personally think that multi-layer routing in this context in a complete non-sense (look at how difficult it is in non constrained environments) but this is another story.

Jumping into this discussion, and looking back at the trail, I guess that what Mukul wanted to know originally was the following (Mukul, please correct me if I am wrong).

Regards,

Emmanuel

---

From: Mukul Goyal <[email-masked]>
Date: Thu, 3 Sep 2009 11:57:49 -0500 (CDT)

Emmanuel

This is exactly what I wanted to know.

Thanks
Mukul

----- Original Message -----
From: "Emmanuel Baccelli" <[email-masked]>
To: [email-masked]
Sent: Thursday, September 3, 2009 11:49:52 AM GMT -06:00 US/Canada Central
Subject: Re: [Roll] Next items ...

Hi JP, 

On Thu, Sep 3, 2009 at 3:09 PM, JP Vasseur < [email-masked] > wrote: 

  

Regards, 

Emmanuel

---

From: [email-masked]
Date: Thu, 3 Sep 2009 12:58:05 -0500

Hmmm.  So now I am even a bit more confused than normal.

If some of the LLN devices might be hosts only, then I would expect that 
as normal IP works, the host devices communicate directly to each other if 
they share the same subnet (excuse my IPv4 parlance, don't know what it's 
called in IPv6).  If hosts need to route to other subnets they would post 
the packet to the router that would forward the packet as needed.  This 
all sounds good for wired implementations when every node in the subnet 
can be directly accessed by every other node in the subnet.

However, in a wireless implementation two hosts may not be in radio range 
but share the same router which happens to be within radio range of both 
hosts.  Is it 'legal' for a host to forward a packet to a router who will 
then forward it to another device on the same subnet?  I thought that was 
verboten.

Jerry

"Pascal Thubert (pthubert)" <[email-masked]> 
Sent by: [email-masked]
09/03/2009 12:25 PM

To
"Emmanuel Baccelli" <[email-masked]>, <[email-masked]>
cc

Subject

Salut Emmanuel:

 
>From what I can gather, I suppose ROLL is targeting (i). Is it correct?

I have not seen the point where such an assumption (i) or (ii) was 
necessary. 
And that is neither the 6LoWPAN model nor the 802.15.4 FFD/RFD model.
Maybe a given deployment will have such constraint but the routing 
protocol itself is certainly agnostic.
 
A bientôt,
 
Pascal
From: [email-masked] [mailto:[email-masked]] On Behalf Of 
Emmanuel Baccelli
Sent: jeudi 3 septembre 2009 18:50
To: [email-masked]
Subject: Re: [Roll] Next items ...
 
Hi JP,

 

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

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 3 Sep 2009 14:11:48 -0700

On Sep 3, 2009, at 10:58 AM, [email-masked] wrote:
> If some of the LLN devices might be hosts only, then I would expect  
> that as normal IP works, the host devices communicate directly to  
> each other if they share the same subnet (excuse my IPv4 parlance,  
> don't know what it's called in IPv6).  If hosts need to route to  
> other subnets they would post the packet to the router that would  
> forward the packet as needed.  This all sounds good for wired  
> implementations when every node in the subnet can be directly  
> accessed by every other node in the subnet.
>
> However, in a wireless implementation two hosts may not be in radio  
> range but share the same router which happens to be within radio  
> range of both hosts.  Is it 'legal' for a host to forward a packet  
> to a router who will then forward it to another device on the same  
> subnet?  I thought that was verboten.

Using IPv6 terminology, the router may advertise one or more "on-link"  
prefixes using RAs.  A host may then communicate directly with another  
host if the destination matches one of the on-link prefixes advertised  
by the router.  But there is no requirement for a router to advertise  
on-link prefixes.  If the destination is not on-link, then the  
datagram would normally be forwarded to the router even if the  
destination can be reached with a single IP hop.  On an ethernet link,  
routers typically advertise one or more "on-link" prefixes for that  
subnet.  In the wireless world, the use of "on-link" prefixes doesn't  
make as much sense if the link is non-transitive.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 4 Sep 2009 08:17:18 +0200

Hi Jerry:

> If some of the LLN devices might be hosts only, then I would expect that as normal IP works, the host devices communicate directly to each other if they share the same subnet (excuse my IPv4 parlance, don't know what it's called in IPv6).  If hosts need to route to other subnets they would post the packet to the router that would forward the packet as needed.  This all sounds good for wired implementations when every node in the subnet can be directly accessed by every other node in the subnet. 

This is the spirit. 

Conceptually, this is why NAs are used to carry DAO. You could imagine that some ROLL routers temporarily do act as routers (refrain from sending RA-DIOs) but still belong in a termination role - as hosts.

Additionally and following our discussion, we are working on adding the capability to multicast the NA DAO to all nodes on link.

Trouble is a link is something difficult to define and maintain. So proximity will not be a guarantee that 2 nodes that implement the ROLL NA-DAO can actually communicate.

Finally, at the moment, we have not added the concept of RFD and FFD into ROLL. That is, we have not extracted the subset that a node should implement when it can never be a router but still participate to ROLL as a termination. Maybe we could.

> However, in a wireless implementation two hosts may not be in radio range but share the same router which happens to be within radio range of both hosts.  Is it 'legal' for a host to forward a packet to a router who will then forward it to another device on the same subnet?  I thought that was verboten. 

Complementing to Jonathan's good answer: not verboten. On the contrary, required for prefixes that are not 'on-link'. If the destination is actually on a same transit link then the router should issue an ICMP redirect to tell so to the source. But as Jonathan said, the non-transitive property of our links do not guarantee that even if node A sees router and router sees node B, then node A sees node B. Another thing that is not generally guaranteed is that the router should see B with the same MAC address as A does. For those reasons, 6LoWPAN ND does not use redirects, and advertises the prefixes as not onlink.

It is not strictly speaking wired against wireless. A frame relay cloud supporting a subnet will behave as a non transitive link as described above, and the DLCI from router to B will not be the DLCI from node A to node B if one exists at all. It is rather a link model. Ethernet is a transit link, and the infrastructure mode in 802.11 emulates of the Ethernet properties, allowing on-link subnets. The way it works is that every packet is relayed by the AP and only the STA to AP connectivity is maintained by an association. You realize that we are doing the same thing here at L3 between node and router.

Pascal

From: [email-masked] [mailto:[email-masked]] 
Sent: jeudi 3 septembre 2009 19:58
To: Pascal Thubert (pthubert)
Cc: Emmanuel Baccelli; [email-masked]; [email-masked]
Subject: Re: [Roll] Next items ...

If some of the LLN devices might be hosts only, then I would expect that as normal IP works, the host devices communicate directly to each other if they share the same subnet (excuse my IPv4 parlance, don't know what it's called in IPv6).  If hosts need to route to other subnets they would post the packet to the router that would forward the packet as needed.  This all sounds good for wired implementations when every node in the subnet can be directly accessed by every other node in the subnet. 

However, in a wireless implementation two hosts may not be in radio range but share the same router which happens to be within radio range of both hosts.  Is it 'legal' for a host to forward a packet to a router who will then forward it to another device on the same subnet?  I thought that was verboten. 

Jerry 

09/03/2009 12:25 PM 

To

cc

Subject

		

Salut Emmanuel: 

  

A bientôt, 
  
Pascal 
  
Hi JP, 

  

  
  
Regards,

---

From: JP Vasseur <[email-masked]>
Date: Fri, 4 Sep 2009 08:28:07 +0200

Hi,

> protocol itself is certainly agnostic.

Right, nothing different than with other routing protocols. A host may  
run a routing protocol.

Thanks.

JP.

> that RPL is an IP routing protocol ? Yes it is. If you decide you  
> run another routing protocol at L2, it will be transparent to RPL. I  
> Jumping into this discussion, and looking back at the trail, I guess  
> that what Mukul wanted to know originally was the following (Mukul,  
> please correct me if I am wrong).
>

---

From: JP Vasseur <[email-masked]>
Date: Fri, 4 Sep 2009 08:31:20 +0200

On Sep 3, 2009, at 11:11 PM, Jonathan Hui wrote:

>> subnet?

absolutely.

>> I thought that was verboten.
>
> Using IPv6 terminology, the router may advertise one or more "on- 
> link" prefixes using RAs.

if you want an IPv4 analogy Jerry, a router may advertise prefixes  
using a routing protocol such as RIP for example. If the destination  
is not on the same subnet, the router will send the packet to the  
router.

> A host may then communicate directly with another host if the  
> destination matches one of the on-link prefixes advertised by the  
> router.  But there is no requirement for a router to advertise on- 
> link prefixes.  If the destination is not on-link, then the datagram  
> would normally be forwarded to the router even if the destination  
> can be reached with a single IP hop.  On an ethernet link, routers  
> typically advertise one or more "on-link" prefixes for that subnet.   
> In the wireless world, the use of "on-link" prefixes doesn't make as  
> much sense if the link is non-transitive.
>
> --
> Jonathan Hui
>