Subject: [6lo] Request for Ethertype for 6lowpan-encoded IPv6

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Fri, 19 Feb 2016 19:55:10 +0000

(BCC: [email-masked])

Paul Duffy and I recently published draft-droms-6lo-ethertype-request-00.  The purpose of this document is to demonstrate IETF consensus for requesting an Ethertype to be used with IPv6 datagrams encoded according to RFC 4944/6282, in L2 protocols that have a protocol switch.

We'd like to move this document along quickly, because Wi-SUN Alliance would like to specify the Ethertype in the Wi-SUN FAN specification.  Please take a look at the document (it's barely over 3 pages, including all the boilerplate) and respond to the 6lo WG mailing list with comments.

- Ralph

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 22 Feb 2016 12:59:43 +0000

Hello Ralph and Paul:

Substantive:
-----------------
The draft is specific that the ethertype means what it names 6loENC.

1) What would be the position of new work such as
- https://tools.ietf.org/html/draft-ietf-6lo-routing-dispatch and 
- https://tools.ietf.org/html/draft-thubert-6lo-inner-compression ?

2) The group flirted with Jonathan's idea of having more than one ethertype. For instance, we could have an ethertype that is more specific than "anything 6loENC can encode with paging" to more specific stuff that could be even better compressed. An example that was discussed was a route-over ethertype and a mesh-under ethertype so for instance page 1 does not have to be signaled in a route-over ethertype. 
Could that be envisioned?

Typos:
---------
Datatgrams 

Cheers,

Pascal

> -----Original Message-----
> From: Ralph Droms (rdroms)
> Sent: vendredi 19 février 2016 20:55
> To: [email-masked] WG <[email-masked]>
> Subject: Request for Ethertype for 6lowpan-encoded IPv6
> 
> (BCC: [email-masked])
> 
> Paul Duffy and I recently published draft-droms-6lo-ethertype-request-00.
> The purpose of this document is to demonstrate IETF consensus for
> requesting an Ethertype to be used with IPv6 datagrams encoded according
> to RFC 4944/6282, in L2 protocols that have a protocol switch.
> 
> We'd like to move this document along quickly, because Wi-SUN Alliance
> would like to specify the Ethertype in the Wi-SUN FAN specification.  Please
> take a look at the document (it's barely over 3 pages, including all the
> boilerplate) and respond to the 6lo WG mailing list with comments.
> 
> - Ralph
>

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Mon, 22 Feb 2016 15:15:41 +0000

> On Feb 22, 2016, at 7:59 AM 2/22/16, Pascal Thubert (pthubert) <[email-masked]> wrote:
> 
> Hello Ralph and Paul:
> 
> Substantive:
> -----------------

I would consider those documents to be out of scope of this document as "future work".  One way to handle those extensions would be to have them include explicit text about applying to IPv6 as carried by the Ethertype assigned through draft-droms-6lo-ethertype-request.

> Could that be envisioned?

I could imagine defining additional Ethertypes but I would consider those extensions to be out of scope of this document, as well.

- Ralph

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 22 Feb 2016 16:36:34 +0100

Pascal Thubert (pthubert) wrote:
> what it names 6loENC

Editorial note:
Do we have to invent a term for RFC 6282 (implying RFC 4944)?
Can't we just say 6Lo framing or some such?
And, if we really have to, can we find a better term for the framing?
Maybe avoid the term "encoding", which this is not about?

Technical note:
I indeed find it irksome to waste an ethertype on a configuration that
does not make a lot of sense (legacy mesh headers over 802? Ouch).
But maybe it is easier to do the wrong thing here for now.

Question:
More generally, would it not be preferable to simply use PV1 for 6Lo
over 802.11ah (halow)?

Technical comment:
If the PV0 frames are ever bridged into a real Ethernet, the approach of
https://tools.ietf.org/html/draft-bormann-rohc-over-802-02 could be used
to avoid uncontrolled padding.  As proposed in
draft-droms-6lo-ethertype-request-00.txt, this simply does not work.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Tue, 23 Feb 2016 11:16:27 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > 2) The group flirted with Jonathan's idea of having more than one
    > ethertype. For instance, we could have an ethertype that is more
    > specific than "anything 6loENC can encode with paging" to more specific
    > stuff that could be even better compressed. An example that was
    > discussed was a route-over ethertype and a mesh-under ethertype so for
    > instance page 1 does not have to be signaled in a route-over ethertype.

I would also like to have this resolved.
The document very explicitely says: RFC 4944, RFC 6282, but it's unclear
if it would include subsequent amendments.

I also agree with Pascal that it would be better to have two ethertypes:
mesh-under and route-over.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Don Sturek <[email-masked]>
Date: Tue, 23 Feb 2016 08:39:00 -0800

Hi Michael (and Pascal),

I admit I haven't kept up with 6lo as I should, but.....

Why would we need 2 Ethertypes for 6LoWPAN (including 6lo).   Here are my
observations (please correct where they are wrong):
1)  Ethertypes typically work in conjunction with a dispatch value that
the protocol creates (in this case 6LoWPAN/6lo).  Isn't the Dispatch Value
Bit Pattern in Figure 2 of RFC 4944 that dispatch?
2)  If the Dispatch Value Bit is the sub-typing on Ethertype for RFC 4944
then that would seem to cover the legacy mesh under, IPv6, HC1 (both
with/without fragmentation)  plus broadcast/multicast.
3)  I think I saw a thread discussing how to add support for 6lo (the DECT
work, the lobac work, etc.) and make those dispatch values backward
compatible with the RFC 4944 Dispatch).  Was that determined to be not
feasible?  If the 6lo Dispatch is compatible with RFC 4944 then again we
are still at 1 EtherType.
4)  Certainly we want room for expansion and the dispatch value is only 6
bits.  However, it is followed by a type-specific header.  Couldn't we use
say a byte of that as an expansion field of the Dispatch?

I think you will get a lot of pushback from the IEEE 802.1 folks around 2
Ethertypes unless we can justify it.

Don Sturek

On 2/23/16 8:16 AM, "6lo on behalf of Michael Richardson"
<[email-masked] on behalf of [email-masked]> wrote:

>_______________________________________________
>6lo mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/6lo

---

From: Paul Duffy <[email-masked]>
Date: Tue, 23 Feb 2016 11:52:55 -0500

> if it would include subsequent amendments.

I can't get my head around this statement.  The draft as you mentioned 
is explicit re: 4944 and 6282.

How can the authors make any assumptions re: guaranteed future RFC-ed 
amendments emerging from 6lo?

> mesh-under and route-over.

As Don has mentioned, any request to IEEE for two Ethertypes had best 
come with very very compelling justification.

---

From: "Ralph Droms (rdroms)" <[email-masked]>
Date: Tue, 23 Feb 2016 17:18:48 +0000

> On Feb 23, 2016, at 11:16 AM 2/23/16, Michael Richardson <[email-masked]> wrote:
> 
> 

Having this document consider subsequent amendments would be like having the Ethertype assignment for IPv6 consider all the future RFCs that have an effect on the IPv6 header.

Perhaps this document could use another sentence to the effect of "Future documents that modify or extend the protocols used with this Ethertype will explicitly state that relationship."

> mesh-under and route-over.

In my opinion, what is needed is an Ethertype for RFC 4944 and RFC 6282, which are published today.  Future alternatives, which might be optimized for different compression, routing and other considerations, can apply for a separate Ethertype when those new mechanisms are published.

- Ralph

---

From: Robert Cragie <[email-masked]>
Date: Tue, 23 Feb 2016 19:37:44 +0000

It seems unnecessary to have to expect draft-droms-6lo-ethertype-request-00
to consider esoteric uses of e.g. eliding addition of page 1 for
route-over. The whole point of the paging is to ensure backwards
compatibility with the existing RFC 4944/6282, so I can't see the need for
allocating two ethertypes at this point either.

Robert

On 23 February 2016 at 17:18, Ralph Droms (rdroms) <[email-masked]> wrote:

> Having this document consider subsequent amendments would be like having
> the Ethertype assignment for IPv6 consider all the future RFCs that have an
> effect on the IPv6 header.
>
> Perhaps this document could use another sentence to the effect of "Future
> documents that modify or extend the protocols used with this Ethertype will
> explicitly state that relationship."
>
> >
> In my opinion, what is needed is an Ethertype for RFC 4944 and RFC 6282,
> which are published today.  Future alternatives, which might be optimized
> for different compression, routing and other considerations, can apply for
> a separate Ethertype when those new mechanisms are published.
>
> - Ralph
>
> >
> > --

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Feb 2016 20:20:27 +0000

Hello Ralph

The 6LoRH work is getting ready for last call.

If the demand comes from environments that use RPL, It should most certainly be included.

What is the requirement in terms of time frame?

Pascal

> Le 22 févr. 2016 à 16:15, Ralph Droms (rdroms) <[email-masked]> a écrit :
> 
>

---

From: Paul Duffy <[email-masked]>
Date: Tue, 23 Feb 2016 15:27:17 -0500

> What is the requirement in terms of time frame?

Immediate if possible.    This request is coming after months of false 
starts with IEEE.

6LoRH is not in scope of the impacted effort.

> .

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 23 Feb 2016 20:31:34 +0000

I'm not following you Paul

In one hand you claim that an ethertype is hard to get and in the other you are asking to use that bullet with an incomplete scope? What will the next protocol that needs this new work do?

Pascal

> Le 23 févr. 2016 à 21:27, Paul Duffy (paduffy) <[email-masked]> a écrit :
> 
> Immediate if possible.    This request is coming after months of false starts with IEEE.
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Feb 2016 08:39:11 +0000

Hello Ralph:

> Having this document consider subsequent amendments would be like
> having the Ethertype assignment for IPv6 consider all the future RFCs that
> have an effect on the IPv6 header.

My point exactly. If we had limited the ethertype for IPv6 to RFC 2460, we could never have had all the updates that we are now putting together in draft-ietf-6man-rfc2460bis.
And when that draft becomes RFC, it will not need another ethertype, will it?

My ask to the authors is to use the adequate wording so that we can use the upcoming updates on how we use the dispatch space within the ethertype that we are asking for. How was that worded for IPv6?

One way could be to indicate RFC 4944 as the base document, and say that all the updates to the dispatch space following proper IETF process, such as RFC 6282, are covered by the ethertype. This is similar to an IETF draft referencing an undated IEEE specification.

One the side, the paging and the routing dispatch are WG doc, ready for last call. They are way beyond visions in a crystal ball. So why not list them if we start listing things?

Cheers,

Pascal

> From: 6lo [mailto:[email-masked]] On Behalf Of Ralph Droms (rdroms)
> Sent: mardi 23 février 2016 18:19
> To: Michael Richardson <[email-masked]>
> Cc: Paul Duffy (paduffy) <[email-masked]>; [email-masked]
> Subject: Re: [6lo] Request for Ethertype for 6lowpan-encoded IPv6
> 
> 
> >> specific than "anything 6loENC can encode with paging" to more
> >> specific stuff that could be even better compressed. An example that
> >> was discussed was a route-over ethertype and a mesh-under ethertype
> >> so for instance page 1 does not have to be signaled in a route-over
> ethertype.
> > The document very explicitely says: RFC 4944, RFC 6282, but it's
> > unclear if it would include subsequent amendments.
> 
> Having this document consider subsequent amendments would be like
> having the Ethertype assignment for IPv6 consider all the future RFCs that
> have an effect on the IPv6 header.
> 
> for different compression, routing and other considerations, can apply for a
> separate Ethertype when those new mechanisms are published.
> 
> - Ralph
> 
> >
> > --

---

From: Alexandre Petrescu <[email-masked]>
Date: Wed, 24 Feb 2016 14:21:11 +0100

> mesh-under and route-over.

Sidequestion: do we know which mesh-under header would carry that 
ethertype?  For route-over ethertype I would say that the header 
carrying that ethertype would be the IEEE's "Logical-Link Control 
Header"(?).

Alex

---

From: Robert Cragie <[email-masked]>
Date: Wed, 24 Feb 2016 14:07:33 +0000

As stated in the draft, the requested ethertype is for use in the
IEEE 802.15.9 Multiplexed Data Information Element. The consideration of
any other ethertype would seem to purely hypothetical at this point.

Robert

On 24 February 2016 at 13:21, Alexandre Petrescu <
[email-masked]> wrote:

>> specific
> ethertype?  For route-over ethertype I would say that the header carrying
> that ethertype would be the IEEE's "Logical-Link Control Header"(?).
>
> Alex
>
>
>> --

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 24 Feb 2016 14:13:18 +0000

If the ether type is to be encoded in an 802.15.9 protocol element, would this same ether type then be used in a future implementation of 802.15.12 ?

R.

On Feb 24, 2016, at 9:07 AM, Robert Cragie <[email-masked]<mailto:[email-masked]>> wrote:

As stated in the draft, the requested ethertype is for use in the IEEE 802.15.9 Multiplexed Data Information Element. The consideration of any other ethertype would seem to purely hypothetical at this point.

Robert

On 24 February 2016 at 13:21, Alexandre Petrescu <[email-masked]<mailto:[email-masked]>> wrote:

Sidequestion: do we know which mesh-under header would carry that ethertype?  For route-over ethertype I would say that the header carrying that ethertype would be the IEEE's "Logical-Link Control Header"(?).

Alex

--
Michael Richardson <[email-masked]<mailto:[email-masked]>>, Sandelman Software Works
  -= IPv6 IoT consulting =-

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

_______________________________________________
6lo mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/6lo

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Feb 2016 09:45:14 -0500

Paul Duffy <[email-masked]> wrote:
    >> I would also like to have this resolved.  The document very
    >> explicitely says: RFC 4944, RFC 6282, but it's unclear if it would
    >> include subsequent amendments.

    > is explicit re: 4944 and 6282.

yes. Is it: 4944 and 6282 *ONLY*, or
     6282-as-amended/updated-by-IETF-standards action?

It would be easier if 6282 was at Internet Standard state, because then we
could say STDxx, and it would be clear that things can be extended.

    >> I also agree with Pascal that it would be better to have two
    >> ethertypes: mesh-under and route-over.

    > come with very very compelling justification.

Because if we had two ethertypes, then it would be easier to reuse the code
space in the future.   LLNs are generally quite well controlled ecosystems,
which is why we felt we might be able to reuse the mesh-under codes for
additional route-over compression.  In the end, we decided not to do go this
way... NOW.

If we have a single ethertype, then we can never do that.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Feb 2016 09:48:04 -0500

Ralph Droms (rdroms) <[email-masked]> wrote:
    >>> ethertype.  Could that be envisioned?
    >>

    > having the Ethertype assignment for IPv6 consider all the future RFCs
    > that have an effect on the IPv6 header.

But, 86DD does do exactly that.
If the IETF creates a new extension header for IPv6, we can put it into 86DD,
after the IPv6 header.

The reason it is less clear here is because we have an encoding of the IPv6
header, and also we have codes for things that may not even be IPv6.

    > In my opinion, what is needed is an Ethertype for RFC 4944 and RFC
    > 6282, which are published today.  Future alternatives, which might be
    > optimized for different compression, routing and other considerations,
    > can apply for a separate Ethertype when those new mechanisms are
    > published.

If ethertypes are really that cheap and easy to get, then we should ask for
two types today.  If they aren't that cheap, then we should make sure that
that this an ethertype for all 6lo specified standards track work.

---

From: Don Sturek <[email-masked]>
Date: Wed, 24 Feb 2016 06:48:31 -0800

Hi Randy,

IEEE 802.15.9 is an attempt at providing a key management protocol
interface/protocol dispatch (much like a link layer controller would) for
IEEE 802.15.4.

Once IEEE 802.15.12 is complete, I would expect to see re-use of the
EtherType for 6LoWPAN/6lo requested below in their work (I certainly plan to
get involved in IEEE 802.15.12 and make that point, however, I think it has
been assumed in all meetings I have attended of the study group to date).
The first actual meeting of IEEE 802.15.12 is coming up in March at IEEE
802.

For those not familiar, IEEE 802.15.4 has never had a proper link layer
control interface.  IEEE 802.15.12 is a new project to define one for IEEE
802.15.4.

Don

From:  6lo <[email-masked]> on behalf of "Turner, Randy"
<[email-masked]>
Date:  Wednesday, February 24, 2016 6:13 AM
To:  "[email-masked]" <[email-masked]>
Cc:  Alexandre Petrescu <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject:  Re: [6lo] Request for Ethertype for 6lowpan-encoded IPv6

If the ether type is to be encoded in an 802.15.9 protocol element, would
this same ether type then be used in a future implementation of 802.15.12 ?

R.

> On Feb 24, 2016, at 9:07 AM, Robert Cragie <[email-masked]>
> wrote:
> 
> As stated in the draft, the requested ethertype is for use in the IEEE
> 802.15.9 Multiplexed Data Information Element. The consideration of any other
> ethertype would seem to purely hypothetical at this point.
> 
> Robert
> 
> On 24 February 2016 at 13:21, Alexandre Petrescu
> <[email-masked]> wrote:
>> 
>> 
>>>>      > specific than "anything 6loENC can encode with paging" to more >>>>
specific
>> Sidequestion: do we know which mesh-under header would carry that ethertype?
>> For route-over ethertype I would say that the header carrying that ethertype
>> would be the IEEE's "Logical-Link Control Header"(?).
>> 
>> Alex
>> 
>>> 
>>> --
>>> Michael Richardson <[email-masked] <mailto:[email-masked]>
>>> >, Sandelman Software Works

_______________________________________________ 6lo mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/6lo

---

From: Don Sturek <[email-masked]>
Date: Wed, 24 Feb 2016 06:56:09 -0800

Hi Michael,

I had a side bar e-mail with Ralph on the point below:   "If ethertypes
are really that cheap and easy to get, then we should ask for
two types today.  If they aren't that cheap, then we should make sure that
that this an ethertype for all 6lo specified standards track work."

For whatever reason, we have been working on this single EtherType request
for nearly a year now.  We have asked as IEEE 802.15 (declined), asked as
Wi-SUN Alliance (declined), asked to make the request via IETF (this
thread).  The general consensus I get from the process so far is
EtherTypes (right or wrong) are being treated as a very scarce commodity.

That said, I don't see why we can't ask for another EtherType later if we
have a concrete reason for one.  For sure, the case for 4944/6282 is clear
at this point.  I think as the 6loRH work progresses (or other similar
work) that a case can be made for an additional allocation.  I am just
hoping to conclude on our single EtherType request for what is known!
Keep in mind once the EtherType is allocated for 4944/6282, it is up to us
to define via the Dispatch code what it applies to.  We are free to extend
it via future RFCs as long as the Dispatch code allows.

Don

---

From: "Turner, Randy" <[email-masked]>
Date: Wed, 24 Feb 2016 15:14:44 +0000

Hi Don,

Yes, I was replying to Robert Cragie's email that indicated that:

"As stated in the draft, the requested ethertype is for use in the IEEE 802.15.9 Multiplexed Data Information Element. The consideration of any other ethertype would seem to purely hypothetical at this point."

Which in my email I was trying to figure out is this ethertype request ONLY for 15.9 or would this same ethertype (if approved)  be used in 15.12 as well...seems like it would.

R.

From: Don Sturek [mailto:[email-masked]]
Sent: Wednesday, February 24, 2016 9:49 AM
To: Turner, Randy; [email-masked]
Cc: Alexandre Petrescu; [email-masked]
Subject: Re: [6lo] Request for Ethertype for 6lowpan-encoded IPv6

Hi Randy,

IEEE 802.15.9 is an attempt at providing a key management protocol interface/protocol dispatch (much like a link layer controller would) for IEEE 802.15.4.

Once IEEE 802.15.12 is complete, I would expect to see re-use of the EtherType for 6LoWPAN/6lo requested below in their work (I certainly plan to get involved in IEEE 802.15.12 and make that point, however, I think it has been assumed in all meetings I have attended of the study group to date).  The first actual meeting of IEEE 802.15.12 is coming up in March at IEEE 802.

For those not familiar, IEEE 802.15.4 has never had a proper link layer control interface.  IEEE 802.15.12 is a new project to define one for IEEE 802.15.4.

Don

From: 6lo <[email-masked]<mailto:[email-masked]>> on behalf of "Turner, Randy" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, February 24, 2016 6:13 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: Alexandre Petrescu <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [6lo] Request for Ethertype for 6lowpan-encoded IPv6

R.

Robert

Alex

_______________________________________________ 6lo mailing list [email-masked]<mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/6lo

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Feb 2016 15:16:07 +0000

Hello Don:

I was taken by surprise that the 802.15.9 ethertype space is already crowded. I did not expect that.

The point of 2 ethertypes is to save bytes in the frame. I'm sure IEEE802.15 understands that need very clearly. How expensive bytes in the air are vs. limited resources like ethertype is always a difficult discussion since we are not comparing apples to apples.

I'm raising the case here because none of the ethertypes in question would cover the full spectrum of what the 6LoWPAN dispatch can address. If we get this particular ethertype that covers it all, then we'll be asking later for 2 other ethertypes. Or we'll drop the idea completely.

But then, I buy the idea to make the case there as opposed to this thread. I understand and agree with the need for the ethertype and that's all that's really needed from this side. 

Cheers,

Pascal

> From: 6lo [mailto:[email-masked]] On Behalf Of Don Sturek
> Sent: mercredi 24 février 2016 15:56
> To: Michael Richardson <[email-masked]>; Ralph Droms (rdroms)
> <[email-masked]>
> are really that cheap and easy to get, then we should ask for two types
> today.  If they aren't that cheap, then we should make sure that that this an
> ethertype for all 6lo specified standards track work."
> 
> for nearly a year now.  We have asked as IEEE 802.15 (declined), asked as Wi-
> SUN Alliance (declined), asked to make the request via IETF (this thread).
> The general consensus I get from the process so far is EtherTypes (right or
> wrong) are being treated as a very scarce commodity.
> 
> That said, I don't see why we can't ask for another EtherType later if we have
> a concrete reason for one.  For sure, the case for 4944/6282 is clear at this
> point.  I think as the 6loRH work progresses (or other similar
> work) that a case can be made for an additional allocation.  I am just hoping
> to conclude on our single EtherType request for what is known!
> Keep in mind once the EtherType is allocated for 4944/6282, it is up to us to
> define via the Dispatch code what it applies to.  We are free to extend it via
> future RFCs as long as the Dispatch code allows.
> 
> Don
> 
> 
> 
> 
> >If the IETF creates a new extension header for IPv6, we can put it into
> >86DD, after the IPv6 header.
> >
> >If ethertypes are really that cheap and easy to get, then we should ask
> >for two types today.  If they aren't that cheap, then we should make
> >sure that that this an ethertype for all 6lo specified standards track
> >work.
> >
> >--

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Feb 2016 10:55:37 -0500

Don Sturek <[email-masked]> wrote:
    > That said, I don't see why we can't ask for another EtherType later if
    > we have a concrete reason for one.  For sure, the case for 4944/6282 is
    > clear at this point.  I think as the 6loRH work progresses (or other
    > similar work) that a case can be made for an additional allocation.  I
    > am just hoping to conclude on our single EtherType request for what is
    > known!  Keep in mind once the EtherType is allocated for 4944/6282, it
    > is up to us to define via the Dispatch code what it applies to.  We are
    > free to extend it via future RFCs as long as the Dispatch code allows.

I don't want to do it this way: having two ethertype code points that support
route-over 4944 is dump: that way just breaks compability, and fails to
accomplish what Pascal, myself and others want: which is seperation of
route-over and mesh-under bridged traffic.

I would be happy if this was a request for RFC4944-6282++ using the 4944
registry (meaning, that 6LoRH, and future route-over extensions would be
assumed to be welcome), but
   specifying that the mesh-under code points are not welcome.

(This is Carsten's position that if you say 4944, then really all 6loRH work
is included)

Then, if the mesh-under people need an ethertype, that they would ask for
one, and as you say, that could happen later.

I'm ignorant of what the Wi-SUN runs as a protocol. Is it route-over?

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Feb 2016 11:02:02 -0500

> The point of 2 ethertypes is to save bytes in the frame. I'm sure
    > IEEE802.15 understands that need very clearly. How expensive bytes in
    > the air are vs. limited resources like ethertype is always a difficult
    > discussion since we are not comparing apples to apples.

In the "add a layer of indirection" motive:
   Pascal, we *could* specify a new encapsulation (even a single byte) for
   this new single ethertypes which indicates if it's route-over or mesh-under.

It's not like ethernet (1500 bytes) encapsulation of 127 byte 6lo packets is
lacking for space.

I think, since this is encapsulating 4944, and not
  802.15.4(INSERTLETTER-FOR-PHY-OF-WEEK),
that this would encapsulate 6lo over BTLE and BACnet, etc. equally well.

I can see this encapsulation being used in preference to IPv6 straight
routing to connect parts of a BTLE LLN to parts of a 15.4 LLN as a single
Admin-scoped LLN.

I wonder if there are things that we would need across ethernet that we would
otherwise not need (or could not afford!) across the various low powered
radios that would justify having that encapsulation layer.

---

From: Don Sturek <[email-masked]>
Date: Wed, 24 Feb 2016 08:24:08 -0800

Hi Michael,

In Wi-SUN we support both route over (RPL) and mesh under (an L2 routing
solution specified in TIA TR51 4957-210).  Obviously, for a given Wi-SUN
FAN deployment, it is either one or the other.

What we did in IEEE 802.15.9 is:
1)  Define a Multiplex ID.  If the value is less than 1500, the multiplex
is defined within IEEE 802.15 (these values correspond to the
legacy/reserved EtherTypes).   For example, the Multplex ID value of 1 is
defined in the IEEE 802.15.9 specification for the Key Management Protocol
(we have 8 available as sub-types in the initial 15.9 specificatiion).
Multiplex ID values 2-1279 are available via an ANA process in IEEE
802.15.   Multplex ID values 1280-1500 are vendor specified.  If the
Multplex ID value is 1501 or higher then the value is an assigned
EtherType. 
2)  So we will ask for an allocation for Wi-SUN of an IEEE 802.15.9
Multiplex ID in the range 2-1279 and define a sub-type for our mesh under
protocol.   
3)  For Multiplex ID of 1500 or higher, these are actual EtherTypes.
This is where the request for an EtherType for 6LoWPAN comes in (and 6lo
as well since it shares the same Dispatch).

While it is possible to define the Multiplex ID for 6LoWPAN as a locally
defined IEEE 802.15, it seemed useful to ask for an actual EtherType
allocation.  That allocation can also cover the rest of the currently
defined 6lo protocols (BTLE, lowpanz, etc.) where a locally defined value
in IEEE 802.15 would not make sense.

Don

---

From: Robert Cragie <[email-masked]>
Date: Wed, 24 Feb 2016 18:13:41 +0000

Hi Michael,

AFAICT, this is nothing to do with separation of route-over/mesh-under
traffic. All it seems to be (as Pascal points out) is that having another
Ethertype could be a way of saving bytes (only one?) by not having to use
the currently defined RFC4944/6282 dispatch space, which is being extended
currently (and draft-droms-6lo-ethertype-request-00 is clear it applies to
this as well) to use a paged dispatch.

The headers being defined in 6LoRH are not "mesh-under" or "route-over".
They have a specific purpose and some, as encapsulating headers and
depending on their placement, could serve as either. The mesh header in
RFC4944 is not (as seems to be commonly misunderstood) a "mesh-under"
header. It is also an encapsulating header. Thread, for example, uses it as
an optimised IP-in-IP header.

Maybe I am missing something here but what I find faintly baffling in all
of this conversation outside of the Wi-SUN application specifically
requested is the notion of the use of Ethertypes at all. Any inclusion of
these are above the MAC so will consume minimum of 2 bytes and probably
extra if we are looking at SNAP or the like. All the 6LoRH proposals are
aimed at trying to reduce the number of bytes and assume placement of the
resulting packet with 6LoRH headers into the MAC SDU - not some LLC SDU.

Robert

---

From: Randy Turner <[email-masked]>
Date: Wed, 24 Feb 2016 13:28:44 -0500

Hi Robert,

It would be nice to have whatever mechanism is being discussed OUTSIDE the LLC discussion (meaning the mux on some value contained somewhere else) to be compatible, and preferably within the same namespace as what will come out of the LLC 15.12 work.  I would prefer not to have two ways to do the same thing, and have the “thing” that identifies a particular mapping to be different.

There are APIs in a number of stacks that “register” their interest in accessing an interface based on ether type — I would hope that we can reuse this idea

R.

> On Feb 24, 2016, at 1:13 PM, Robert Cragie <[email-masked]> wrote:
> 
> Hi Michael,
> 
> AFAICT, this is nothing to do with separation of route-over/mesh-under traffic. All it seems to be (as Pascal points out) is that having another Ethertype could be a way of saving bytes (only one?) by not having to use the currently defined RFC4944/6282 dispatch space, which is being extended currently (and draft-droms-6lo-ethertype-request-00 is clear it applies to this as well) to use a paged dispatch.
> 
> The headers being defined in 6LoRH are not "mesh-under" or "route-over". They have a specific purpose and some, as encapsulating headers and depending on their placement, could serve as either. The mesh header in RFC4944 is not (as seems to be commonly misunderstood) a "mesh-under" header. It is also an encapsulating header. Thread, for example, uses it as an optimised IP-in-IP header.
> 
> Maybe I am missing something here but what I find faintly baffling in all of this conversation outside of the Wi-SUN application specifically requested is the notion of the use of Ethertypes at all. Any inclusion of these are above the MAC so will consume minimum of 2 bytes and probably extra if we are looking at SNAP or the like. All the 6LoRH proposals are aimed at trying to reduce the number of bytes and assume placement of the resulting packet with 6LoRH headers into the MAC SDU - not some LLC SDU.
> 
> Robert
> 
> On 24 February 2016 at 15:55, Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> Don Sturek <[email-masked] <mailto:[email-masked]>> wrote:
> Michael Richardson <[email-masked] <mailto:[email-masked]>>, Sandelman Software Works
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/6lo <https://www.ietf.org/mailman/listinfo/6lo>
> 
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 24 Feb 2016 18:32:32 +0000

Hello Robert:

There will be 6LoWPAN over LLC, quite certainly. And that will come at a price, including an LLC ethertype probably. That day, we’ll want to get benefit to compensate the extra bytes, but I agree with you that the byte we save in coding dispatch will not compensate the 2 bytes we lose in ethertype. Unless we define a format for 15.12 that has only a subset of values and can be encoded in a single octet?

The discussion of 2 ethertypes (or more) really has to be related to Jonathan’s proposal at 6lo. In some intermediate 6LoRH draft, this proposal was referred to as a sur-compression, since it can be seen as a compression of 6LoWPAN, or rather a reduction of dimension that would project all the pages into one for a particular type of network. As Michael said, this is doable for all known 6LoWPAN use cases with just 2 ethertypes, one for mesh under and one for route over. We could enforce that page 1 is only for route-over in which case all you can do with 6LoRHH would also be limited to route-over. In that case, the route-over ethertype would enable to elide the page switch, and yes, that is just one octet saved.

We may not be fully ready for that discussion, and we probably need an ethertype for flat RFC 4944 + updates, considering that the 2 ethertype may not enable to address any future combination. So maybe the best way is to get this one ethertype first and then fight later for the 2 ethertypes separately, with a clear and limited scope each.

Does this make sense?

Pascal

From: 6lo [mailto:[email-masked]] On Behalf Of Robert Cragie
Sent: mercredi 24 février 2016 19:14
To: Michael Richardson <[email-masked]>
Cc: Paul Duffy (paduffy) <[email-masked]>; Ralph Droms (rdroms) <[email-masked]>; Don Sturek <[email-masked]>; [email-masked]
Subject: Re: [6lo] Request for Ethertype for 6lowpan-encoded IPv6

Hi Michael,

Robert

On 24 February 2016 at 15:55, Michael Richardson <[email-masked]<mailto:[email-masked]>> wrote:

---

From: Robert Cragie <[email-masked]>
Date: Wed, 24 Feb 2016 18:54:20 +0000

Hi Pascal,

What you say makes sense. I think the term "sur-compression" is confusing
to an English speaker (is that the French meaning of "sur" (i.e.
"over"/"upon")?). IIRC this was really just defining the dispatch space
without taking into consideration the existing dispatch space in
RFC4944/6282, i.e. repurposing the mesh header for 6LoRH without using an
explicit page 1 dispatch code (which is what you have been describing).

Robert

On 24 February 2016 at 18:32, Pascal Thubert (pthubert) <[email-masked]>
wrote:

> Hello Robert:
>
>
>
> There will be 6LoWPAN over LLC, quite certainly. And that will come at a
> price, including an LLC ethertype probably. That day, we’ll want to get
> benefit to compensate the extra bytes, but I agree with you that the byte
> we save in coding dispatch will not compensate the 2 bytes we lose in
> ethertype. Unless we define a format for 15.12 that has only a subset of
> values and can be encoded in a single octet?
>
>
>
> The discussion of 2 ethertypes (or more) really has to be related to
> Jonathan’s proposal at 6lo. In some intermediate 6LoRH draft, this proposal
> was referred to as a sur-compression, since it can be seen as a compression
> of 6LoWPAN, or rather a reduction of dimension that would project all the
> pages into one for a particular type of network. As Michael said, this is
> doable for all known 6LoWPAN use cases with just 2 ethertypes, one for mesh
> under and one for route over. We could enforce that page 1 is only for
> route-over in which case all you can do with 6LoRHH would also be limited
> to route-over. In that case, the route-over ethertype would enable to elide
> the page switch, and yes, that is just one octet saved.
>
>
>
> We may not be fully ready for that discussion, and we probably need an
> ethertype for flat RFC 4944 + updates, considering that the 2 ethertype may
> not enable to address any future combination. So maybe the best way is to
> get this one ethertype first and then fight later for the 2 ethertypes
> separately, with a clear and limited scope each.
>
>
>
> Does this make sense?
>
>
>
> Pascal
>
>
>
> *From:* 6lo [mailto:[email-masked]] *On Behalf Of *Robert Cragie
> *Sent:* mercredi 24 février 2016 19:14
> *To:* Michael Richardson <[email-masked]>
> *Cc:* Paul Duffy (paduffy) <[email-masked]>; Ralph Droms (rdroms) <
> [email-masked]>; Don Sturek <[email-masked]>; [email-masked]
> *Subject:* Re: [6lo] Request for Ethertype for 6lowpan-encoded IPv6
>
>
>
> Hi Michael,
>
>
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Feb 2016 15:40:04 -0500

Robert Cragie <[email-masked]> wrote:
    > Maybe I am missing something here but what I find faintly baffling in
    > all of this conversation outside of the Wi-SUN application specifically
    > requested is the notion of the use of Ethertypes at all. Any inclusion
    > of these are above the MAC so will consume minimum of 2 bytes and

This is about being able to bridge/switch LLNs over wired ethernets (or
high-power Wifi which looks like ethernet).   This is particularly relevant
for mesh-under systems which I would expect are not able to do layer-3
operations at the LLN/wired interface, and would want to switch fraglets
across the wired network.

Saving bytes on the bridged link is irrelevant.

I agree that the dispatch bytes are not exclusive for over or under, but in
general, they are never connected together, so seperating their wired traffic
makes sense to me at it would better allow both to evolve seperately.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 24 Feb 2016 15:42:01 -0500

Pascal Thubert (pthubert) <[email-masked]> wrote:
    > with 6LoRHH would also be limited to route-over. In that case, the
    > route-over ethertype would enable to elide the page switch, and yes,
    > that is just one octet saved.

But, that octet is saved on the LLN side, while the 2-byte expense of the
ethertype is on the wired side.

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Feb 2016 09:45:31 +0100

> crowded. I did not expect that.

If I am not wrong,

One easy indicator of crowdedness is the current list of allocations. 
Note however it's harder to evaluate _tendencies_ (how many requests are 
being received, or expected to be received - few people are in the know).

IANA reflects the list of ethertype allocations maintained 
authoritatively at IEEE:

http://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xhtml

Another aspect in allocations is that it is often good to have one tool 
for many applications.  Otherwise risks of interoperability problems loom.

In the above list if one searches for "IPv6" one finds only one, and 
it's good, I think.

Alex

> the air are vs. limited resources like ethertype is always a
> difficult discussion since we are not comparing apples to apples.
>
> I'm raising the case here because none of the ethertypes in question
> would cover the full spectrum of what the 6LoWPAN dispatch can
> address. If we get this particular ethertype that covers it all, then
> we'll be asking later for 2 other ethertypes. Or we'll drop the idea
> completely.
>
> But then, I buy the idea to make the case there as opposed to this
> thread. I understand and agree with the need for the ethertype and
> that's all that's really needed from this side.
>
> Cheers,
>
> Pascal
>
>
>> -----Original Message----- From: 6lo [mailto:[email-masked]]
>> On Behalf Of Don Sturek Sent: mercredi 24 février 2016 15:56 To:
>> Michael Richardson <[email-masked]>; Ralph Droms (rdroms)
>> <[email-masked]> Cc: Paul Duffy (paduffy) <[email-masked]>;
>> [email-masked] Subject: Re: [6lo] Request for Ethertype for
>> 6lowpan-encoded IPv6
>>
>> Hi Michael,
>>
>> I had a side bar e-mail with Ralph on the point below:   "If
>> ethertypes are really that cheap and easy to get, then we should
>> ask for two types today.  If they aren't that cheap, then we should
>> make sure that that this an ethertype for all 6lo specified
>> standards track work."
>>
>> For whatever reason, we have been working on this single EtherType
>> request for nearly a year now.  We have asked as IEEE 802.15
>> (declined), asked as Wi- SUN Alliance (declined), asked to make the
>> request via IETF (this thread). The general consensus I get from
>> the process so far is EtherTypes (right or wrong) are being treated
>> as a very scarce commodity.
>>
>> That said, I don't see why we can't ask for another EtherType later
>> if we have a concrete reason for one.  For sure, the case for
>> 4944/6282 is clear at this point.  I think as the 6loRH work
>> progresses (or other similar work) that a case can be made for an
>> additional allocation.  I am just hoping to conclude on our single
>> EtherType request for what is known! Keep in mind once the
>> EtherType is allocated for 4944/6282, it is up to us to define via
>> the Dispatch code what it applies to.  We are free to extend it
>> via future RFCs as long as the Dispatch code allows.
>>
>> Don
>>
>>
>>
>>
>>>>>> 2) The group flirted with Jonathan's idea of having more
>>>>>> than one ethertype. For instance, we could have an
>>>>>> ethertype that is more specific than "anything 6loENC can
>>>>>> encode with paging" to more specific stuff that could be
>>>>>> even better compressed. An example
>>> that
>>>>> explicitely says: RFC 4944, RFC 6282, but it's unclear if it
>>>>> would include subsequent amendments.
>>>
>>>> Having this document consider subsequent amendments would be
>>>> like having the Ethertype assignment for IPv6 consider all the
>>>> future
>>> RFCs
>>> But, 86DD does do exactly that. If the IETF creates a new
>>> extension header for IPv6, we can put it into 86DD, after the
>>> IPv6 header.
>>>
>>> The reason it is less clear here is because we have an encoding
>>> of the IPv6 header, and also we have codes for things that may
>>> not even be IPv6.
>>>
>>>> In my opinion, what is needed is an Ethertype for RFC 4944 and
>>>> RFC 6282, which are published today.  Future alternatives,
>>>> which
>>> might be
>>>> can apply for a separate Ethertype when those new mechanisms
>>>> are published.
>>>
>>> If ethertypes are really that cheap and easy to get, then we
>>> should ask for two types today.  If they aren't that cheap, then
>>> we should make sure that that this an ethertype for all 6lo
>>> specified standards track work.
>>>
>>> -- Michael Richardson <[email-masked]>, Sandelman
>>> Software
>> Works

---

From: Alexandre Petrescu <[email-masked]>
Date: Thu, 25 Feb 2016 09:54:22 +0100

Le 24/02/2016 19:54, Robert Cragie a écrit :
> Hi Pascal,
>
> What you say makes sense. I think the term "sur-compression" is
> confusing to an English speaker (is that the French meaning of "sur"
> (i.e. "over"/"upon")?).

I read it as "hyper-squeezed", high compression maybe with a loss of 
quality.

Alex

  IIRC this was really just defining the dispatch
> space without taking into consideration the existing dispatch space in
> RFC4944/6282, i.e. repurposing the mesh header for 6LoRH without using
> an explicit page 1 dispatch code (which is what you have been describing).
>
> Robert
>
> On 24 February 2016 at 18:32, Pascal Thubert (pthubert)
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hello Robert:____
>
>     __ __
>
>     There will be 6LoWPAN over LLC, quite certainly. And that will come
>     at a price, including an LLC ethertype probably. That day, we’ll
>     want to get benefit to compensate the extra bytes, but I agree with
>     you that the byte we save in coding dispatch will not compensate the
>     2 bytes we lose in ethertype. Unless we define a format for 15.12
>     that has only a subset of values and can be encoded in a single
>     octet?____
>
>     __ __
>
>     Jonathan’s proposal at 6lo. In some intermediate 6LoRH draft, this
>     proposal was referred to as a sur-compression, since it can be seen
>     as a compression of 6LoWPAN, or rather a reduction of dimension that
>     would project all the pages into one for a particular type of
>     network. As Michael said, this is doable for all known 6LoWPAN use
>     cases with just 2 ethertypes, one for mesh under and one for route
>     over. We could enforce that page 1 is only for route-over in which
>     case all you can do with 6LoRHH would also be limited to route-over.
>     In that case, the route-over ethertype would enable to elide the
>     page switch, and yes, that is just one octet saved. ____
>
>     __ __
>
>     We may not be fully ready for that discussion, and we probably need
>     an ethertype for flat RFC 4944 + updates, considering that the 2
>     ethertype may not enable to address any future combination. So maybe
>     the best way is to get this one ethertype first and then fight later
>     for the 2 ethertypes separately, with a clear and limited scope
>     each. ____
>
>     __ __
>
>     Does this make sense?____
>
>     __ __
>
>     Pascal____
>
>     __ __
>
>     *From:*6lo [mailto:[email-masked]
>     <mailto:[email-masked]>] *On Behalf Of *Robert Cragie
>     *To:* Michael Richardson <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:* Paul Duffy (paduffy) <[email-masked]
>     <mailto:[email-masked]>>; Ralph Droms (rdroms) <[email-masked]
>     <mailto:[email-masked]>>; Don Sturek <[email-masked]
>     <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>     *Subject:* Re: [6lo] Request for Ethertype for 6lowpan-encoded IPv6____
>
>     __ __
>
>     Hi Michael,____
>
>     __ __
>
>     AFAICT, this is nothing to do with separation of
>     route-over/mesh-under traffic. All it seems to be (as Pascal points
>     out) is that having another Ethertype could be a way of saving bytes
>     (only one?) by not having to use the currently defined RFC4944/6282
>     dispatch space, which is being extended currently (and
>     draft-droms-6lo-ethertype-request-00 is clear it applies to this as
>     well) to use a paged dispatch.____
>
>     __ __
>
>     The headers being defined in 6LoRH are not "mesh-under" or
>     "route-over". They have a specific purpose and some, as
>     encapsulating headers and depending on their placement, could serve
>     as either. The mesh header in RFC4944 is not (as seems to be
>     commonly misunderstood) a "mesh-under" header. It is also an
>     encapsulating header. Thread, for example, uses it as an optimised
>     IP-in-IP header.____
>
>     __ __
>
>     Maybe I am missing something here but what I find faintly baffling
>     in all of this conversation outside of the Wi-SUN application
>     specifically requested is the notion of the use of Ethertypes at
>     all. Any inclusion of these are above the MAC so will consume
>     minimum of 2 bytes and probably extra if we are looking at SNAP or
>     the like. All the 6LoRH proposals are aimed at trying to reduce the
>     number of bytes and assume placement of the resulting packet with
>     6LoRH headers into the MAC SDU - not some LLC SDU.____
>
>     __ __
>
>     Robert____
>
>     __ __
>
>     On 24 February 2016 at 15:55, Michael Richardson
>     <[email-masked] <mailto:[email-masked]>> wrote:____
>
>
>         I'm ignorant of what the Wi-SUN runs as a protocol. Is it
>         route-over?____
>
>
>         --
>         Michael Richardson <[email-masked]
>         <mailto:[email-masked]>>, Sandelman Software Works
>         ____
>         https://www.ietf.org/mailman/listinfo/6lo____
>
>     __ __
>
>
>
>