Discussion:
New LINKTYPE_ for EPON
Philip Rosenberg-Watt
2014-04-18 12:40:04 UTC
Permalink
Hello:

I apologize if this is a duplicate message. I sent a request on Monday but
I have not received a response, so I'm trying again, this time as a member
of the list. I also did not S/MIME sign this message in case that was the
issue.

CableLabs specifies Ethernet Passive Optical Network as the foundation for
DPoE (DOCSIS Provisioning over EPON). We would like to request a separate
LINKTYPE for EPON, as all EPON frames will contain a fixed-size 8-byte
preamble before the Ethernet header.

The relevant standard is IEEE 802.3-2012, Section 5, Clause 65.


Thanks again,


--
Phil Rosenberg-Watt

Engineering Technician III, Systems Evaluation
CableLabs
303-661-3361
p.rosenberg-***@cablelabs.com
Guy Harris
2014-04-18 17:10:47 UTC
Permalink
On Apr 18, 2014, at 5:40 AM, Philip Rosenberg-Watt <P.Rosenberg-***@cablelabs.com> wrote:

> I apologize if this is a duplicate message. I sent a request on Monday but
> I have not received a response, so I'm trying again, this time as a member
> of the list.

I think non-member messages need to be moderated.

> I also did not S/MIME sign this message in case that was the
> issue.

Not as far as I know.

> CableLabs specifies Ethernet Passive Optical Network as the foundation for
> DPoE (DOCSIS Provisioning over EPON). We would like to request a separate
> LINKTYPE for EPON, as all EPON frames will contain a fixed-size 8-byte
> preamble before the Ethernet header.
>
> The relevant standard is IEEE 802.3-2012, Section 5, Clause 65.

So a frame would start with the 8-byte preamble described by 802.3-2012 section 65.1.3.2 "Transmit", followed immediately by a regular Ethernet frame?
Guy Harris
2014-04-21 21:58:30 UTC
Permalink
On Apr 21, 2014, at 6:38 AM, Philip Rosenberg-Watt <P.Rosenberg-***@cablelabs.com> wrote:

> The frames as captured do not look like they've passed through the receive
> function. Here's an example preamble as captured:
>
> D5 55 55 3C 02 44
>
> As you can see, The first two bytes of the preamble have been stripped
> according to the note in 65.1.3.2.1 "SLD." The first byte we get to see,
> which is the third byte of the preamble, is the SLD 0xD5. Then two bytes
> of 0x55, then the LLID 0x3C02, then the CRC-8 0x44.
>
> Everything after those 6 bytes is a normal Ethernet frame, starting with
> the destination MAC.

...

> So I believe we will only need one LINKTYPE_ which will be for EPON frames
> that have not been processed by the receive function (or straight off of
> the optical fiber).

OK, so frames for LINKTYPE_ETHERNET_P2MP, or whatever we end up calling it, are:

the last 6 octets of the modified preamble as specified by 65.1.3.2 "Transmit" in 802.3-2012

followed by

a regular Ethernet frame (with the destination MAC being the MAC of the splitter, rather than the MAC of the final destination?)?

> Any sniffing after an EPON preamble has been processed
> through the receive function will appear to be a normal Ethernet frame.

And those would be LINKTYPE_ETHERNET, with just a regular Ethernet frame with the right destination MAC, and nothing preceding the destination MAC?
Guy Harris
2014-04-21 22:42:48 UTC
Permalink
On Apr 21, 2014, at 3:24 PM, Philip Rosenberg-Watt <P.Rosenberg-***@cablelabs.com> wrote:

> On 4/21/14 15:58 , "Guy Harris" <***@alum.mit.edu> wrote:
>
>> OK, so frames for LINKTYPE_ETHERNET_P2MP, or whatever we end up calling
>> it, are:
>>
>> the last 6 octets of the modified preamble as specified by 65.1.3.2
>> "Transmit" in 802.3-2012
>
> Correct.

OK - is LINKTYPE_ETHERNET_P2MP a good name, or might there be other flavors of point-to-multipoint in the future, so that we should call this LINKTYPE_ETHERNET_P2MP_EPON or something such as that?

>>
>> followed by
>>
>> a regular Ethernet frame (with the destination MAC being the MAC of the
>> splitter, rather than the MAC of the final destination?)?
>
> The destination MAC is the same as defined for Ethernet in IEEE 802.1. I
> can't find anything in the specification that says that the ONU/OLT will
> rewrite the destination MAC. The ONU/OLT has an internal mapping to
> associate LLIDs with MACs of connected devices, and uses it for forwarding
> packets to the appropriate Ethernet port.

So why doesn't the destination MAC suffice to determine which is the appropriate Ethernet port?

>> And those would be LINKTYPE_ETHERNET, with just a regular Ethernet frame
>> with the right destination MAC, and nothing preceding the destination MAC?
>
> Yes, because the sniffer would be connected downstream of the ONU/OLT

E.g., connected to the Ethernet in the subscriber's home?
Guy Harris
2014-04-22 20:17:31 UTC
Permalink
On Apr 22, 2014, at 11:12 AM, Philip Rosenberg-Watt <P.Rosenberg-***@cablelabs.com> wrote:

> I'm fine with LINKTYPE_EPON. You're right that the P2MP is implied in the PON and of course the Ethernet in the E.

OK, I've assigned 259 as LINKTYPE_EPON/DLT_EPON.
Guy Harris
2014-04-22 22:16:33 UTC
Permalink
(Resending to the list.)

On Apr 22, 2014, at 1:28 PM, Philip Rosenberg-Watt <p.rosenberg-***@cablelabs.com> wrote:

> Great! I just submitted my Wireshark dissector with the appropriate
> LINKTYPE.

Hmm.

That dissector does

/* Start_of_Packet delimiter (/S/) can either happen in byte 1 or byte 2,
* making the captured preamble either 7 or 6 bytes in length. If the
* preamble starts with 0x55, then /S/ happened in byte 1, making the
* captured preamble 7 bytes in length.
*
* If for some reason the sniffer adds two bytes of 0x55 idle before SLD,
* do not change the offset, but raise an error later.
*/
if (tvb_get_ntohs(tvb, 0) == 0x5555) {
offset -= 0;
} else if (tvb_get_ntohs(tvb, 0) == 0x55D5) {
offset -= 1;
} else if (tvb_get_ntohs(tvb, 0) == 0xD555) {
offset -= 2;
} else {
item = proto_tree_add_item(tree, proto_epon, tvb, offset, 0, ENC_NA);
expert_add_info(pinfo, item, &ei_epon_sld_bad);
return 0;
}

The code current starts out with offset = 0, and appears to always add 2 to offset; I'll suggest replacing that with

/* Start_of_Packet delimiter (/S/) can either happen in byte 1 or byte 2,
* making the captured preamble either 7 or 6 bytes in length. If the
* preamble starts with 0x55, then /S/ happened in byte 1, making the
* captured preamble 7 bytes in length.
*
* If for some reason the sniffer adds two bytes of 0x55 idle before SLD,
* do not change the offset, but raise an error later.
*/
if (tvb_get_ntohs(tvb, 0) == 0x5555) {
offset += 2;
} else if (tvb_get_ntohs(tvb, 0) == 0x55D5) {
offset += 1;
} else if (tvb_get_ntohs(tvb, 0) == 0xD555) {
offset += 0;
} else {
item = proto_tree_add_item(tree, proto_epon, tvb, offset, 0, ENC_NA);
expert_add_info(pinfo, item, &ei_epon_sld_bad);
return 0;
}

and subtract 2 from the offsets passed to code adding items to the protocol tree, to make the code a bit more understandable (in terms of offsets from the beginning of the packet data).

This suggests that the description of LINKTYPE_EPON needs to be changed, to indicate that:

the preamble in the capture file is between 6 and 8 octets long, *not* a fixed 6 octets long;

if it begins with 0x55 0x55, the preamble is 8 octets long, and what follows the 0x55 0x55 is the 6 octets in question;

if it begins with 0x55 0xD5, the preamble is 7 octets long, and what follows the initial 0x55 is the 6 octets in question;

if it begins with 0xD5 0x55, the preamble is 6 octets long, and is the 6 octets in question.

In addition, the code *still* has a preference to indicate whether the octet preceding the mode/LLID is just 0x55 or an encryption enabled/key ID field. Either

1) there should be *two* LINKTYPE_ values - LINKTYPE_EPON, in which that field is just part of the preamble, and LINKTYPE_DPON or LINKTYPE_CABLELABS_DPOE, in which it's an encryption enabled/key ID field

or

2) if that field will *never* have the value 0x55 in a DPoE capture, and will *always* have the value 0x55 in a regular EPON capture, use that to determine what the field is.

(Any time a tcpdump link-layer printer for a given DLT_ value, or a Wireshark dissector for a WTAP_ENCAP_ value, requires a preference/command line option to control how the octets of the link-layer header are parsed, God kills a kitten. Please, think of the kittens.)

(Slide 5 of

http://www.ieee802.org/3/epoc/public/mar12/schmitt_02_0312.pdf

says, emphatically, that this "Is NOT DOCSIS over fiber", so I assume what follows the DPoE preamble is an Ethernet frame, *not* a DOCSIS frame.)
Guy Harris
2014-04-23 22:29:16 UTC
Permalink
On Apr 23, 2014, at 6:58 AM, Philip Rosenberg-Watt <P.Rosenberg-***@cablelabs.com> wrote:

> I sent this to the list -- twice -- but it never showed up, so I'll just
> resend it to you. I don't know what's going on.

Moderation? Michael?

> I only put in the first "if" clause because some PON sniffer manufacturers
> may interpret the standard differently, and instead of dumping them out of
> the dissector entirely, I thought I could throw them a helpful error with
> a hint towards fixing their implementation. I believe the description
> should stay the same: that the preamble is 6 octets long with an optional
> idle (0x55) octet preceeding, depending on system alignment. 8 octets
> would be an error and needs correction in the PON sniffer implementation.

If that's what the description says, then the Wireshark dissector should treat frames with two 0x55's as an error, rather than trying to work around them.

Wireshark or tcpdump dissectors shouldn't "extend" the description on tcpdump.org; the whole point of those descriptions is to allow people to write dissectors for a given LINKTYPE_/DLT_ value *without* having to look at tcpdump or Wireshark source - if the description doesn't allow somebody to write a program that handles those headers the same way tcpdump or Wireshark do, because they also need to know about special processing tcpdump or Wireshark does, then the description is incomplete and needs to be completed.

> Here's the problem as I see it: DPoE is simply an extension of (the unused
> and ignored) part of EPON, not a completely different format.

But it requires that the header be processed differently; "completely" is irrelevant - the purpose of a LINKTYPE_/DLT_ value is to indicate to the code processing a capture how it should process the header indicated by the value.

> Another problem is that EPON and DPoE system equipment can interoperate to
> some level, and the PON sniffer has no way of knowing whether the traffic
> it's seeing is DPoE or regular EPON. There would be no determine which
> LINKTYPE_ to put in the pcap file without human intervention.

...

> A piece of equipment
> sniffing the data should already know what it's capturing is EPON.

Unless I'm missing something, the first of those paragraphs says the hardware *doesn't* know whether the octet in question is 0x55 or an encryption field, so it doesn't know whether it's capturing standard EPON or EPON with the DPoE encryption extension.

If that's the case, so that a human has to indicate how the octet should be interpreted in any case, a single LINKTYPE_/DLT_ value is OK.
Michael Richardson
2014-04-24 00:38:37 UTC
Permalink
Guy Harris <***@alum.mit.edu> wrote:
>> I sent this to the list -- twice -- but it never showed up, so I'll just
>> resend it to you. I don't know what's going on.

> Moderation? Michael?

Nothing in the local queue.
Nothing in spam trap. That suggests that your email failed SPF or something
that caused it to never get to lists.tcpdump.org. Send mail logs please...

>> I only put in the first "if" clause because some PON sniffer manufacturers
>> may interpret the standard differently, and instead of dumping them out of
>> the dissector entirely, I thought I could throw them a helpful error with
>> a hint towards fixing their implementation. I believe the description
>> should stay the same: that the preamble is 6 octets long with an optional
>> idle (0x55) octet preceeding, depending on system alignment. 8 octets
>> would be an error and needs correction in the PON sniffer implementation.

> If that's what the description says, then the Wireshark dissector
> should treat frames with two 0x55's as an error, rather than trying to
> work around them.

> Wireshark or tcpdump dissectors shouldn't "extend" the description on
> tcpdump.org; the whole point of those descriptions is to allow people
> to write dissectors for a given LINKTYPE_/DLT_ value *without* having
> to look at tcpdump or Wireshark source - if the description doesn't
> allow somebody to write a program that handles those headers the same
> way tcpdump or Wireshark do, because they also need to know about
> special processing tcpdump or Wireshark does, then the description is
> incomplete and needs to be completed.

+5

>> A piece of equipment
>> sniffing the data should already know what it's capturing is EPON.

> Unless I'm missing something, the first of those paragraphs says the
> hardware *doesn't* know whether the octet in question is 0x55 or an
> encryption field, so it doesn't know whether it's capturing standard
> EPON or EPON with the DPoE encryption extension.

> If that's the case, so that a human has to indicate how the octet
> should be interpreted in any case, a single LINKTYPE_/DLT_ value is
> OK.

But, if the human has to say which thing is being captured, shouldn't we want
to capture what the human thought as different types?

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
Guy Harris
2014-04-24 04:02:13 UTC
Permalink
On Apr 22, 2014, at 2:29 PM, Guy Harris <***@alum.mit.edu> wrote:

> In addition, the code *still* has a preference to indicate whether the octet preceding the mode/LLID is just 0x55 or an encryption enabled/key ID field. Either
>
> 1) there should be *two* LINKTYPE_ values - LINKTYPE_EPON, in which that field is just part of the preamble, and LINKTYPE_DPON or LINKTYPE_CABLELABS_DPOE, in which it's an encryption enabled/key ID field
>
> or
>
> 2) if that field will *never* have the value 0x55 in a DPoE capture, and will *always* have the value 0x55 in a regular EPON capture, use that to determine what the field is.

According to

http://www.cablelabs.com/wp-content/uploads/specdocs/DPoE-SP-SECv2.0-I03-140327.pdf

(BTW, 5 googolplex cheers to CableLabs for not putting their specifications behind a @#$%@@$$# paywall!), the octet before the LLID will always have the bit value 010101EK, where E is the "Enc", or "data transferred is cypher text" bit, and "K" is the "key identification number used to encrypt the frame", with the number in question being either 0 or 1, obviously.

So a value of 0x55, i.e. 01010101, has the "data transferred is cypher text" bit clear, and the "key identification number" bit being 1 but presumably being *irrelevant*, as the "data transferred is cypher text" bit is clear and the frame is *not* encrypted.

Furthermore, the spec also says "When encryption is disabled, the DPoE System MUST set the 1Down security octet to a value of 0x55."

So is there any technical reason *not* to dissect the frame by:

if that octet doesn't have the upper 6 bits as 010101, report it as an error;

if that octet is 0x55, show it as a preamble octet, and treat the frame as not encrypted;

if that octet is 0x54, report it as an error, as encryption is disabled but the security octet is *not* 0x55;

if that octet is 0x56, report it as "encryption enabled, key ID 0", and treat the frame as encrypted;

if that octet is 0x57, report it as "encryption enabled, key ID 1", and treat the frame as encrypted;

with no preference needed?
Guy Harris
2014-04-24 04:19:04 UTC
Permalink
On Apr 23, 2014, at 9:02 PM, Guy Harris <***@alum.mit.edu> wrote:

> So is there any technical reason *not* to dissect the frame by:
>
> if that octet doesn't have the upper 6 bits as 010101, report it as an error;
>
> if that octet is 0x55, show it as a preamble octet, and treat the frame as not encrypted;
>
> if that octet is 0x54, report it as an error, as encryption is disabled but the security octet is *not* 0x55;
>
> if that octet is 0x56, report it as "encryption enabled, key ID 0", and treat the frame as encrypted;
>
> if that octet is 0x57, report it as "encryption enabled, key ID 1", and treat the frame as encrypted;
>
> with no preference needed?

Or, as per 6.2 "10G Zero-Overhead Cipher Suite (10Down, 10Bi)" (hey, I'll take 10Gb to the home, or even the neighborhood!):

if that octet has the value 01010101, show it as a preamble octet, and treat the frame as not encrypted;

if that octet has the value XXXXXX00, where XXXXXX is not 010101, report it as an error, as encryption is disabled but the security octet is *not* 0x55;

if that octet has the value XXXXXX10, report it as "encryption enabled, key ID 0", treat the frame as encrypted, and show XXXXXX as "LSB of the MPCP time of the frame DA at the transmitter";

if that octet has the value XXXXXX11, report it as "encryption enabled, key ID 1", treat the frame as encrypted, and show XXXXXX as "LSB of the MPCP time of the frame DA at the transmitter".
Philip Rosenberg-Watt
2014-04-24 13:13:03 UTC
Permalink
>So is there any technical reason *not* to dissect the frame by:
>
> if that octet doesn't have the upper 6 bits as 010101, report it as an
>error;
>
> if that octet is 0x55, show it as a preamble octet, and treat the frame
>as not encrypted;
>
> if that octet is 0x54, report it as an error, as encryption is disabled
>but the security octet is *not* 0x55;
>
> if that octet is 0x56, report it as "encryption enabled, key ID 0", and
>treat the frame as encrypted;
>
> if that octet is 0x57, report it as "encryption enabled, key ID 1", and
>treat the frame as encrypted;
>
>with no preference needed?

I thought about that solution, and it's probably the best. The only thing
you lose is the positive confirmation that the information is *not*
encrypted, but if the ethernet dissector works on it, that's probably
confirmation enough, right? :)

I'll get to updating the code today and posting a new patch set.
Guy Harris
2014-04-24 17:51:24 UTC
Permalink
On Apr 24, 2014, at 6:13 AM, Philip Rosenberg-Watt <P.Rosenberg-***@cablelabs.com> wrote:

> I thought about that solution, and it's probably the best. The only thing
> you lose is the positive confirmation that the information is *not*
> encrypted,

You could show that octet as a preamble octet *and* show the 0x02 bit, so it'll be reported as being off.
Guy Harris
2014-04-24 22:30:31 UTC
Permalink
On Apr 24, 2014, at 6:31 AM, Philip Rosenberg-Watt <p.rosenberg-***@cablelabs.com> wrote:

> Then how are we to determine if the capture is 1G or 10G mode? Do we
> simply exclude the possibility of XXXXXX being 010101 for the MPCP LSB? Or
> are we back to a preference, but to select 1G vs 10G mode? Or maybe a
> LINKTYPE_EPON_10G?

Given that the downstream encryption mechanisms are different for 1G and 10G, and given that the sniffing hardware presumably knows whether it's sniffing 1G or 10G, I'd vote for LINKTYPE_EPON_1G and LINKTYPE_EPON_10G, with the differences being in the parsing of the octet in question and in the decryption of downstream traffic if the program reading the file supports that.
Philip Rosenberg-Watt
2014-04-25 12:43:53 UTC
Permalink
On 4/24/14 16:30 , "Guy Harris" <***@alum.mit.edu> wrote:

>
>On Apr 24, 2014, at 6:31 AM, Philip Rosenberg-Watt
><p.rosenberg-***@cablelabs.com> wrote:
>
>> Then how are we to determine if the capture is 1G or 10G mode? Do we
>> simply exclude the possibility of XXXXXX being 010101 for the MPCP LSB?
>>Or
>> are we back to a preference, but to select 1G vs 10G mode? Or maybe a
>> LINKTYPE_EPON_10G?
>
>Given that the downstream encryption mechanisms are different for 1G and
>10G, and given that the sniffing hardware presumably knows whether it's
>sniffing 1G or 10G, I'd vote for LINKTYPE_EPON_1G and LINKTYPE_EPON_10G,
>with the differences being in the parsing of the octet in question and in
>the decryption of downstream traffic if the program reading the file
>supports that.

Take a look at this and tell me what you think:
http://en.wikipedia.org/wiki/10G-EPON#Backward_compatibility
I'm not sure my original assumption was correct: that 1G and 10G were
mutually exclusive.
Loading...