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.
-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
