Re: [802.3_EPOC] What is the problem with the EPoC converter, and what is the CLT?
Hi Jorge and all,
The IEEE 802.3 can define the EPOC PHY with the Ethernet MAC above it. The IEEE has the definition for the bridge in 802.1. The definition of a bridge between EPON and EPOC should be handled by these standards. I agree that it isn't really a CLT since we think of the CLT has a shelf with many blades. It is a 2 port bridge. I think that we could modify our drawings to show a 2 port bridge between EPON and EPOC. We should come up with a nice acronym for it. Maybe ECB "EPON Coax Bridge". I don't think that a bridge is what Jorge had in mind.
Media converters are not normally defined in 802.3 but they have been standardized. 802.3 defined Ethernet Repeaters long ago when we had half duplex. Repeaters were connections between Ethernet PHYs which is essentially what you are asking for today. The repeater disappeared with full duplex. Media Converters have standards in Japan and other places. They have not been defined by 802.3 to my knowledge. I agree that we should show the media converter or repeater application in our system drawings since it has great value to the operators. As Mark suggested, we should keep the media converter (repeater) in mind when we define the PHY. I'm not sure if we can define it here in 802.3 with the EPOC PHY. Maybe Glen or Howard can comment where in IEEE, where it would get defined. Do we ask for a repeater project in 802.3 or a media converter in SIEPON or somewhere else?
For reference, I will mention that an Ethernet media converter is simple to build and it can handle different rate PHYs. You can find them for sale on-line. Some people use higher data gigabit optics as the transport but they are connecting to 100BT Ethernet devices. The media converter has buffering for a single packet. It will get the packet off of the GMII and put it on the XGMII. If there is 100BT on both sides of the media converter, there is no packet drop. If the MAC isn't controlled to 100BT rate, packets will be dropped.
In the case of EPOC, we will have a similar issue. In the Ethernet in the first mile, the MAC was required to delay the transmission of packets to the PHY to meet the data rate of the PHY. I'm sure Howard can shine more light on this approach. If we connect the EPOC PHY to the EPON MAC, the EPOC MAC must regulate the frames to the PHY's auto-negotiated data rate. In the case of the media converter, the EPON MAC in the OLT would need to regulate the transmission of data as if it was directly connected to the EPOC PHY.
I hope this was helpful,
Ed....
-----Original Message-----
From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx]
Sent: Friday, March 02, 2012 8:35 AM
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] What is the problem with the EPoC converter, and what is the CLT?
Bill,
That is one of the reasons why I agree with Jorge: there is need for it, and
we need to look at providing this specific feature so there is no doubt and
finger-pointing later on.
Marek
-----Original Message-----
From: Trubey, Bill [mailto:bill.trubey@xxxxxxxxxxx]
Sent: 02 March 2012 16:31
To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
Subject: Re: [802.3_EPOC] What is the problem with the EPoC converter, and
what is the CLT?
Let's make sure the "bridging" IWF performs and is defined with no
ambiguities- as we saw long ago between two dissimilar media, FDDI and
Ethernet. We as consumers had to deal with several (large) vendors pointing
fingers at each other on who interpreted the IEEE standards "correctly" .
_____________________________
Bill Trubey, Time Warner Cable
bill.trubey@xxxxxxxxxxx, (720) 279-2819
From: "Mudugere, Satish"
<satish.mudugere@xxxxxxxxx<mailto:satish.mudugere@xxxxxxxxx>>
Reply-To: "Mudugere, Satish"
<satish.mudugere@xxxxxxxxx<mailto:satish.mudugere@xxxxxxxxx>>
Date: Fri, 2 Mar 2012 11:12:58 -0500
To:
"STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
"
<STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx>
>
Subject: Re: [802.3_EPOC] What is the problem with the EPoC converter, and
what is the CLT?
I agree with Vally. We have to define the content of the converter box in
detail. I would suggest to use the word 'EPoC bridge' than 'converter'. The
EPoC bridge needs to be clarified with input and output interfaces along
with the exact funcationality expected from the device. There is no packet
loss frame loss associated with bridge. The EPoC bridge acts a mediator for
OLT to treat ONU and CNU in same way.
Thx,
Satish
Intel Corporation
From: Valentin Ossman [mailto:Valentin_Ossman@xxxxxxxxxxxxxx]
Sent: Thursday, March 01, 2012 11:33 PM
To:
STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto: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<mailto: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
________________________________
________________________________
<="" p="">
________________________________
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1
________________________________________________________________________
To unsubscribe from the STDS-802-3-EPOC list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EPOC&A=1