18, 2010 4:53 PM
To: JP Vasseur
Cc: IPv6 WG; ROLL WG
Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable
Le 18 sept. 2010 à 02:22, JP Vasseur a écrit :
On Sep 15, 2010, at 8:51 AM, Carsten Bormann wrote:
...
However, it would be pretty easy to put something
: roll-boun...@ietf.org [mailto:roll-boun...@ietf.org] On Behalf Of Rémi
Després
Sent: Saturday, September 18, 2010 4:53 PM
To: JP Vasseur
Cc: IPv6 WG; ROLL WG
Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable
Le 18 sept. 2010 à 02:22, JP Vasseur a écrit :
On Sep 15
Pascal == Pascal Thubert (pthubert) pthub...@cisco.com writes:
Pascal Hi Rémi:
Pascal We'll be very glad that 6LoWPAN compresses RPL
Pascal optimally. But RPL being layer 2 agnostic cannot depend on
Only when the security is provide by the layer 2 can the layer 2 do any
today.
Take care,
Pascal
-Original Message-
From: Carsten Bormann [mailto:c...@tzi.org]
Sent: Tuesday, September 21, 2010 4:18 PM
To: Michael Richardson
Cc: Pascal Thubert (pthubert); ROLL WG; IPv6 WG
Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable
On Sep
Pascal
-Original Message-
From: Rémi Després [mailto:remi.desp...@free.fr]
Sent: Tuesday, September 21, 2010 2:28 PM
To: Pascal Thubert (pthubert)
Cc: JP Vasseur; IPv6 WG; ROLL WG
Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable
Le 21 sept. 2010 à 14:08
On Sep 21, 2010, at 15:48, Michael Richardson wrote:
Pascal We'll be very glad that 6LoWPAN compresses RPL
Pascal optimally. But RPL being layer 2 agnostic cannot depend on
Only when the security is provide by the layer 2 can the layer 2 do any
compression. Otherwise, the encryption
On Sep 15, 2010, at 8:51 AM, Carsten Bormann wrote:
Has anybody discussed adding a header with just the 3 bytes you need
*before* the IP header?
Yes. Ever since you proposed pretty much that at a previous IETF meeting,
I've been thinking that architecturally it makes a lot of sense to
Le 18 sept. 2010 à 02:22, JP Vasseur a écrit :
On Sep 15, 2010, at 8:51 AM, Carsten Bormann wrote:
...
However, it would be pretty easy to put something in 6lowpan to carry those
3 bytes.
(Consider it an advanced form of header compression for the 48-byte IP-in-IP
thing, if you don't
Has anybody discussed adding a header with just the 3 bytes you need *before*
the IP header?
Yes. Ever since you proposed pretty much that at a previous IETF meeting, I've
been thinking that architecturally it makes a lot of sense to think about ROLL
as a sub-IP protocol.
The downside is
Has anybody discussed adding a header with just the 3 bytes you need *before*
the IP header?
Yes. Ever since you proposed pretty much that at a previous IETF meeting, I've
been thinking that architecturally it makes a lot of sense to think about ROLL
as a sub-IP protocol.
The downside is
Le 15 sept. 2010 à 04:35, Erik Nordmark a écrit :
... Has anybody discussed adding a header with just the 3 bytes you need
*before* the IP header?
That avoids the overhead.
In www.ietf.org/mail-archive/web/ipv6/current/msg12204, I essentially proposed
that (quote below).
The downside is
So that might use the mesh network header part of the 6lowpan header?
On Sep 15, 2010, at 12:06 AM, Carsten Bormann wrote:
Has anybody discussed adding a header with just the 3 bytes you need
*before* the IP header?
Yes. Ever since you proposed pretty much that at a previous IETF meeting,
On Sep 15, 2010, at 7:19 AM, Fred Baker wrote:
So that might use the mesh network header part of the 6lowpan header?
We would need be using the compressed ID header
On Sep 15, 2010, at 12:06 AM, Carsten Bormann wrote:
Has anybody discussed adding a header with just the 3 bytes you need
On Sep 15, 2010, at 16:19, Fred Baker wrote:
So that might use the mesh network header part of the 6lowpan header?
That would be a bit more radical, I think (and there is no place to put a rank
or instance ID in RFC 4944).
But the effect is similar, as the ROLL-specific information would
On 08/11/10 04:41 PM, Philip Levis wrote:
Basically, RPL puts up to two pieces information in packets that it
routes. The first is which routing topology this packet should be
routed on: RPL supports multiple parallel topologies, e.g., one
optimized for low latency and a second optimized for
Pascal [Pascal] The FL based proposal for RPL uses 12 mutable
bits.
Pascal They are used as an in-band control plane that checks
the
Pascal consistency of routing states along a path. Those states
can
Pascal easily get out of sync due to the nature of the links,
but
Le 12 août 2010 à 10:47, Pascal Thubert (pthubert) a écrit :
We'll note that the Hop by Hop + IP in IP is costly but
solves the generic problem *within* the RPL network. The use of the Flow
label *within* the RPL network would be an alternate so it could have a
more limited applicability,
On Aug 11, 2010, at 3:00 AM, Pascal Thubert (pthubert) wrote:
Pascal [Pascal] The FL based proposal for RPL uses 12 mutable
bits.
Pascal They are used as an in-band control plane that checks the
Pascal consistency of routing states along a path. Those states
can
Pascal
On Aug 10, 2010, at 9:28 AM, Michael Richardson wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Carsten == Carsten Bormann caboc...@gmail.com writes:
Carsten On Aug 10, 2010, at 14:57, Michael Richardson wrote:
The only case where there is a problem is when there is a packet
On Aug 10, 2010, at 14:57, Michael Richardson wrote:
The rational for lots of bits would be to
encourage random allocation such that in the event that two
uncoordinated ROLL networks happened to merge (even for a few
minutes!!!) that the likelyhood of cross talk would be reduced.
Hmm. If
RPL networks consists of leafs and routers. Both typically act as hosts.
Routers are just hosts that happen to be between other nodes.
(Although, some hosts are too weak to be routers)
OK, I'm not talking of host as in originates or terminates traffic, but
host in the sense of does not
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philip == Philip Levis p...@cs.stanford.edu writes:
Philip I feel like we're running in circles, in part due to
Philip different expectations of how RPL will be used.
Philip It's clear that in proprietary or vertically integrated
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Carsten == Carsten Bormann caboc...@gmail.com writes:
RPL networks consists of leafs and routers. Both typically act as hosts.
Routers are just hosts that happen to be between other nodes.
(Although, some hosts are too weak to be
On Aug 10, 2010, at 11:21 AM, Carsten Bormann wrote:
OK, I'm not talking of host as in originates or terminates traffic, but
host in the sense of does not participate in routing.
It appears there is no such thing inside a RPL world then.
A RPL or Manet world doesn't have the
On Aug 10, 2010, at 1:09 PM, Michael Richardson wrote:
I guess I don't see the problem to be as big a deal as you suggest.
I'm happy if flow label 0 gets some default RPLinstanceID.
It would be convenient if the rules were relaxed such that on ingress,
the RPL edge router could *set*
On Aug 9, 2010, at 3:17 AM, Pascal Thubert (pthubert) wrote:
Hi Michael:
With http://tools.ietf.org/html/draft-ietf-roll-rpl-07#section-7.2 I
tried to stay within the lines of RFC 3697 as you also defend in your
mail.
I think the question we have now is not whether that proposal is
26 matches
Mail list logo
