On Aug 27, 2007, at 10:16 PM, Joe Polastre wrote:
To me, its a matter of defining abstractions clearly. Data link
traditionally meant two points connected directly with the use of a
physical wire (ie, it sits right above the "physical layer").
In this domain, we have this quirky ability to have multiple direct
connections. For example, I may be able to directly connect with
Kris, but I can also connect with Kris via John. From a software
layering perspective, I can leverage both options at L2/L2.5 to make
it look to the network layer like I have a reliable direct data-link
connection to Kris, regardless of whether I reach Kris directly or
talk to him via John. This becomes murkier if all of your "direct"
connections are not direct at all or have no possible direct
path--then you're potentially treading on the realm of L3 protocols.
This is why this mesh networking domain has had the problem of
communicating data and metadata between layers transparently, since
each of the layers seems to muddle in other layers' business.
I agree that MPLS is probably most applicable here, and really is one
of these L2.5 services because it is abstracting all kinds of ugly
mess underneath to look like a single data link to L3 protocols.
To avoid confusion, MPLS Routing is performed at layer 3 !
It is the dataplane that does not involve IP lookup but the routing
function
is definitely at the IP layer: LDP paths follow the IGP shortest
paths and
TE LSPs are computed using the TED that is fed by the routing protocols;
then constrained-based routing is used to compute a constrained
path and TE LSP establishment is performed via RSVP-TE.
Thanks.
JP.
-Joe
On 8/27/07, Kris Pister <[EMAIL PROTECTED]> wrote:
Carsten - I'm using 6lowpan in the broad sense of the original
acronym, not
just RFC4919. That may be incorrect, and I should use different
terminology.
Joe - what layer does MPLS fit in? MPLS looks a little weird,
and a little
"2.5"-ish, but to me it's the approach that makes the most sense for
6lowpan. I haven't gone back to read all of the discussion, but
it seems
like the only thing that got added in v6 was the flow label. This
flow
label provides a wonderful opportunity to work with protocols like
HART and
sp100 that use an L3 graph-ID to govern L2 operation. I think
that we could
define a different HC that keeps the v6 flow label and uses that
to control
L2. I'm not sure how much of RSVP, etc would be needed to pull
this off,
but it seems like it should be possible to do something very
similar to what
already exists for MPLS (but probably simplified, compressed,
etc). I'd
like to work on this with someone who is more facile with all of
the L3
stuff (which I am not).
ksjp
Joe Polastre wrote:
For now, RFC4919 takes the stance that L2 routing ("mesh") is an
integral part of the 6lowpan requirements.
First comment is that mesh is a networking protocol, not a data-link
protocol. Thus, it cannot be an L2 "routing" requirement.
Since IP is at L3, I agree with Kris--mesh can either be L2.5 (which
is a bit weird IMHO), it can co-exist with IP (in an undefined way),
or it can be leveraged above IP similar to overlays.
-Joe
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
