Exactly, and to the best of my knowledge there is no FEC mechanisms that can recover from the loss of a string of 1000’s of bits that would happen with an Ethernet
frame loss. Ethernet has a CRC for error detection and then the underlying PHI will have various kinds of FEC depending on the speed/media etc. So FEC is not only redundant in this context it won’t help. IMHO, the only way you could survive frame loss with
CPRI over Ethernet in anything like the time required would be with 1+1 spared connection and even that is really hard (say 8ns to switch to the other connection and it has to be running with exactly the same delay as the primary).
On the security issue, I think there is an argument to make for securing the control channel, but the I/Q data is about to be converted to Analog (I*sin(carrier)
– Q*cos(carrier) or something like that) and broadcast, so it’s kind of easy to snoop the I/Q off the air no matter what E2E security were put in place to wrap around it.
Peter
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Wednesday, June 03, 2015 11:58 AM
To: Richard Maiden
Cc: Zhang, Sunny; AshwoodsmithPeter; Jouni Korhonen; STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: Re: FEC & Security
CPRI as far as I understand runs natively over some PHY, whereas here we will run over Ethernet, so it is not the same as OTN or CPRI itself. If we were to make apples-to-apples comparison, it would have to be some sort of L3+ protocol
operating over Ethernet, where FEC is not added. Ethernet as the transport layer provides it already on per-link basis
On 3 June 2015 at 11:54, Richard Maiden <rmaiden@xxxxxxxxxx> wrote:
Thanks Sunny and others,
I guess I'm looking to hear from operators if they feel this is important? I can not divulge any particulars but in my experience some FEC and encryption has been mandated within CPRI links. I'm not claiming it must be a part of 1904 but we should make a very
conscious decision to exclude it.
OTN standards in ITU have seen good reasons for FEC and in the absence of retransmission I can see some advantages/benefits of such an option.
I agree that loosing a few IQ samples is not likely to have a major impact but if we drop an entire packet containing an entire hyperframe/s worth of data, things might be more serious? Frankly I'm not sure how may fractions or complete hyperframes would need
to be missed before calls are dropped.
Perhaps I should have created a separate thread regarding encryption. I agree, the IQ data itself is perhaps less important, however, I imagine operators are very keen to protect their network from attack. If we foresee a world where RoE is the norm, we should
have some mechanism in place to protect these links.
Thanks
Richard
-----Original Message-----
From: Zhang, Sunny [sunny.zhang@xxxxxxxxx]
Sent: Wednesday, June 03, 2015 07:18 AM Pacific Standard Time
To: AshwoodsmithPeter; Marek Hajduczenia; Richard Maiden
Cc: Jouni Korhonen;
STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: RE: FEC & Security
For I/Q data, for security concern, it is similar like the over the air radio signal, you can always
sniff the radio signal, so I think the I/Q transmission doesn’t need encryption.
For error correction, what packet loss rate we are targeting.
For radio data, due to the wireless channel issue, if it is not packet loss, some I/Q data error
won’t have much impact, if the error rate is very low, likely no need FEC.
-Sunny
Guys, sorry I can’t make Beijing.
1-
I don’t think we should be adding any additional error correction above and beyond what is already done by Ethernet, besides a frame loss is impossible to recover from, only solution
there is just to perhaps replay last frame or something along those lines?
2-
I don’t think end to end encryption is practical here.
Peter
Richard,
FEC is fine, but (a) it eats into the link budget, (b) there has to be agreement as to what FEC is being used (ton of options are out there), and (c) lots of Ethernet PHYs already
include FEC of their own, at which case adding it at encapsulation process kind of makes no sense. FEC is closely tied with the specific link type, data rate, PHY technology, etc. and doing FEC E2E makes little sense, since Ethernet transport will guarantee
delivery at 10^-12 BER.
As far as E2E encryption is concerned, there are already plenty of mechanisms in place that allow end points to authenticate and encrypt traffic. Do we need to come up with a new
one or just allow these mechanism to just work?
On 2 June 2015 at 10:06, Richard Maiden <rmaiden@xxxxxxxxxx> wrote:
Jouni et al,
I apologize if these topics have been discussed previously.
An FEC option might be valuable in this standard. In almost every scenario I can think of, we can not afford to retransmit a packet. But I believe there would be some value in being able to recover data which has some corrupted payload content. FEC clearly
adds some overhead and frankly it may not work at all if the FCS dumps the packet. I would at least like to explore this option though.
A second query is in security. Do we have any provision to encrypt packets? I wonder if operators have some concerns around security? Maybe this is out of scope because higher layers can encompass this? Again, I'm interested to hear opinions.
Thanks,
Richard
-----Original Message-----
From: Jouni Korhonen [jouni.korhonen@xxxxxxxxxxxx]
Sent: Tuesday, May 05, 2015 03:19 PM Pacific Standard Time
To: STDS-1904-3-TF@xxxxxxxxxxxxxxxxx
Subject: IEEE1904.3 meeting in June
Folks,
The first week of June will arrive soon. So, few things to remind about the coming meeting:
1) we have a lot of time to spend on input papers and discussions.
Plan for that. White boarding and onsite documentation is
something we going to do as well - it has proven to be efficient.
2) The input papers must be submitted 10 days before the meeting.
That means Saturday, May 23 is the deadline. Input papers after
the deadline will be treated as late contributions i.e. do not
necessarily have an assigned agenda slot.
- Jouni
--
Jouni Korhonen, CTO Office, Networking, Broadcom Corporation
O: +1-408-922-8135, M:
+1-408-391-7160
Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments,
is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you.
Confidentiality Notice.
This message may contain information that is confidential or otherwise protected from disclosure. If you are not the intended recipient, you are hereby notified that any use, disclosure, dissemination, distribution, or copying of this message, or any attachments,
is strictly prohibited. If you have received this message in error, please advise the sender by reply e-mail, and delete the message and any attachments. Thank you.
|