Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: [802.3_EPOC] What is the problem with the EPoC converter, and what is the CLT?



Team,

Thanks to everyone for the responses and follow-on thoughts. I guess we have not yet heard from those that oppose the idea of defining the conversion device as evidenced during the discussion generated in response to Mark Laubach "slide 19" during the January meeting. I look forward to hearing that opposing perspective.

Based on the discussions in this thread and additional parallel discussions, I now think that a bridge is not the best approach for the conversion box. I agree with Ed Boyd's and Eugene's comments in their Emails, and with Edwin's suggestion that a conversion below the MAC layer is better.

I particularly like an approach proposed by Marek, which I think he very nicely summarizes in the following slide, which Marek will present at the meeting in Hawaii:

I think that if what Marek outlines can be implemented, it would be a perfect way of achieving the key goals that I outlined, and that I know other MSOs and CableLabs agree with, which are:
  • Same OLT for ONU and CNU (FIRST KEY POINT in my original Email)
  • identical ONU and CNU operation (THIRD KEY POINT in my original Email)
  • Transparent operation of the converter (called OCU by Marek), which is the SECOND KEY POINT in my original Email, except that this is improved in Marek's proposal by enabling the OLT to discover RF channel characteristics from the converter/OCU so the OLT can adapt transmissions to the converter/OCU and the CNUs 'behind' it. 
Also, this proposal could be implemented in any of the Use Cases that we have outlined in a presentation that John Dickinson prepared, which has been reviewed and accepted by all MSOs, and that Edwin will present on J.D.'s behalf in Hawaii.
 
I think that Marek's proposal is brilliant! I wonder if others would agree. It seems to me that Marek's proposal would be very straightforward to operate and should eliminate all need for complex operation in the converter/OCU (which would make it easier to develop and implement). I just hope it is doable in the OLT via SW enhancements.

Hope this makes sense.

Regards,
Jorge


From: David Barr <David.Barr@xxxxxxxxxxxx>
Date: Fri, 2 Mar 2012 17:01:43 -0800
To: "Salinger, Jorge" <Jorge_Salinger@xxxxxxxxxxxxxxxxx>, EPoC Study Group <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [802.3_EPOC] What is the problem with the EPoC converter, and what is the CLT?

Yes, I agree with Jorge, Valy, Satish & Mr. Yao (SARFT), that a Bridge makes more sense.

 

‘Media Converter’ implies a PHY-layer hub, which will not be optimum for coax.

MACs are just digital logic, which are fully exposed to Moore’s Law.

Why preserve the MAC, if it becomes a vanishingly small part of the solution?

Particularly when preserving the sub-optimum MAC ruins the economics on coax.

 

‘Bridge’ is actually the more generic term.

The advisable approach is to bridge to coax-optimized technology,

with IEEE focusing on specifying the manageability & provisioning across that bridge.

-Dave

 

 

From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
Sent: Thursday, March 01, 2012 10:44 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] What is the problem with the EPoC converter, and what is the CLT?

 

Thanks Valy! Having a bridge in place of what I generically called a converter makes total sense to me. I was going to call it that, and then decided to just stay with the more generic term "converter". But, the device has to bridge because the interface characteristics will be different, not just in modulation characteristics, but in frame structure, data rates, etc. The bridge will receive a frame, convert it to the other frame format, and deliver it to the other media. In the process there will need to me buffering because one will likely be faster than the other (EPON faster than EPoC in most cases).

So, thanks for the response. Let's see what others think.

Thanks!
Jorge

 

From: Valentin Ossman [mailto:Valentin_Ossman@xxxxxxxxxxxxxx]
Sent: Friday, March 02, 2012 01:33 AM
To: Salinger, Jorge; STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
Subject: RE: [802.3_EPOC] What is the problem with the EPoC converter, and what is the CLT?
 

Hi Jorge,

 

I totally understand your concern and tried to raise this in the past meeting in Long Beach.

The conversion box in your description is simply called a bridge and is already defined by 802. That bridge has 2 interfaces, EPON for the fiber and an new one for the Coax.

The challenge, as you correctly formulated, is to be able to manage and provide the CNUs form the OLT. I completely agree with this statement and want to see this on the EPOC objectives.

 

As a side note, there’ve been discussions about “media converters” or “black magic box” between EPON (fiber) and EPOC (coax). Defining those boxes as PHY layer “media converter” is incorrect in the 802 jargon as it implies that every bit of information from one side is converted to the other side. To be more specific,  there is no packet filtering in the media converter as the PHY can’t analyze a data packet (that’s done in the MAC).

 

I propose that we move away from the self-imposed limitation of “media converter” and PHY only protocol and, have a solid discussion on a practical solution that is able to provide a manageable data service between the OLT and the ONU, taking advantage of EPON and the most efficient technologies available for Coax at this time.

We should not impose unnecessary technical and physical limitation on the coax just to have a protocol identical to EPON but we must ensure that whatever we define, can work with and be manageable from existent EPON OLT equipment.

We must also completely define those “black magic boxes”. There is no point in defining an architecture that relays on an element that is not standardized. I propose we use the well defined functionality of Ethernet switches/bridges for that element.

 

 

---

Valy Ossman

Principal System Architect

FTTH BU

www.PMC-Sierra.com

 

From: Salinger, Jorge [mailto:Jorge_Salinger@xxxxxxxxxxxxxxxxx]
Sent: Thursday, March 01, 2012 9:13 PM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: [802.3_EPOC] What is the problem with the EPoC converter, and what is the CLT?

 

Paul, David, Howard, and EPoC Study Group members,

 

I'm expanding a discussion that I had with Marek, Ed, and Mark to the entire team. I know this will get unruly, but I see this as a "white elephant in the room" for what seems like some sort of philosophical argument, so might as well get it out in the open. Also, I recognize that this was a subject of discussion during the meeting in Newport Beach, but I did not understand it then and thought it might not be important. I see now that it is a key problem that if not resolved will haunt us forever. So, let's see if we can discuss it via Email and see if we can resolve it before the meeting in Hawaii.

 

My initial statement of the problem to Ed, Mark and Marek, expanded for clarity, is: I struggle with what the CLT is, and what is the problem with the converter that we need to define. I see the EPON and EPoC systems containing these components:

 

EPON:

OLT <=== Fiber =====================================> ONUs

 

EPoC:

OLT <=== Fiber ====> converter <=== HFC network ====> CNUs

 

The bottom line is that I want to buy a standard OLT, and buy ONUs for customers I can connect via fiber. And, when I can't run fiber to customers, I want to buy a converter between the fiber and the HFC network so I can use the same standard OLT, and use CNUs (an RF version of the ONU) for those customers attached to the HFC network.

 

The FIRST KEY POINT here is that I want to use the same OLT.

 

The SECOND KEY POINT is that I want to buy a passthrough device that will be invisible to the OLT, which will take the optical EPON signals and convert them into RF signals. This passthrough device must be flexible in several ways, such as allowing me to use different portions of the RF spectrum, including more and less spectrum as available.

 

The THIRD KEY POINT is that I want the CNU to be functionally equivalent to the ONU so that the OLT does not know the difference.

 

I think that I want the RF PHY that the converter and the CNU will use to be defined at IEEE because that should make it easier for the vendors that will implement the converter and the CNU to develop it. 

 

But people tell me that this will be a problem because, from what I understand, the IEEE does not specify converters or some such rationale. Because of that we have to talk about a CLT instead of the OLT, to hide the converter inside the OLT (if I understood correctly).

 

I hope I was able to keep the definition of the problem simple and clean enough to have a straightforward discussion of why we can't do what I, and my esteemed MSO colleagues, need.

 

So, what is the problem with the converter, and why is there a need to instead define a CLT which is something I don't want to have? 

 

Thanks!

Jorge