Re: [802.3_EPOC] What is the problem with the EPoC converter, and what is the CLT?
Geoff,
I could not agree more. It seems the meeting in March will be very busy and
hopefully, very productive, especially if we do get over terminology
problems that we ran into at the first meeting and agree on the path forward
for the OCU/duplex repeater problem.
Regards
Marek
-----Original Message-----
From: Geoff Thompson [mailto:thompson@xxxxxxxx]
Sent: 03 March 2012 17:22
To: Marek Hajduczenia
Cc: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx; Geoff Thompson
Subject: Re: [802.3_EPOC] What is the problem with the EPoC converter, and
what is the CLT?
Marek-
Fair point.
I was only referring to what would be required in the data plane.
It would be perfectly reasonable and appropriate to (optionally) embed a
reasonably significant management capability in the device. I try to keep
the functionality of the data plane and the management plane separate. It is
a ground rule in 802.3 that management is optional and not needed for basic
functionality. Several other standards (e.g. FDDI) have gone down in flames
because they did not adopt this principle.
I have always had a personal bias towards repeaters vs. bridges. That is
largely because my first project in 802.3 was clause 9. Repeaters (known in
the market as hubs) were quite popular in the market at one time. You get
lower delay with a repeater. The significantly larger logic needed for a
bridge ceased to be a cost issue due to the march of Moore's law.
You certainly get more flexibility about what you put on the two sides and
more isolation with a bridge. In addition, it is usually the case that no
new standard is needed for a bridge. You just slap two MAC/PHY sets on a
"relay core" that has already been defined by 802.1.
Duplex repeaters have been discussed several times over the years but not
gained traction.
Whether or not a duplex repeater is appropriate to include in this project
as opposed to a bridge is an appropriate topic for the study group to
consider when formulating the project documentation.
This topic will be easier to discuss once we have a common terminology
hammered out. I think we are getting there.
Best regards,
Geoff
Geoffrey O. Thompson
GraCaSI S.A.
Mountain View, CA 94043
<thompson@xxxxxxxx>
On 33//12 1:52 AM, Marek Hajduczenia wrote:
> Geoff
>
> A fine name it is indeed :) I opted myself for Optical Coax Unit (OCU)
> to have some similarity to ONU and OLT and CNU names.
>
> I am also curious as to what extent this " small amount of logic
> required to couple PHYs back-to-back" could be extended to do some
> more intelligent things, including reporting coax plant conditions to
> the OLT to make sure that data rates towards CNUs are adapted
> accordingly. I'd really like this BOX to be a little bit smarter,
> something in between a pure repeater and MAC bridge ... hence I wonder
> whether this "duplex repeater" could be that missing link between
> repeaters and MAC bridges
>
> Marek
>
> -----Original Message-----
> From: Geoff Thompson [mailto:thompson@xxxxxxxx]
> Sent: 03 March 2012 08:33
> To: STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx
> Subject: Re: [802.3_EPOC] What is the problem with the EPoC converter,
> and what is the CLT?
>
> All-
>
> This reply is primarily to respond to Jorge's message time stamped
> Fri,
> 2 Mar 2012 05:12:46 +0000
> and Ed's message below.
>
> I hope I provide some guidance that will settle us on some common
> terminology.
> I believe that I have the history in 802 and 802.3 to provide the most
> authoritative guidance here.
>
> What Jorge was asking for in his message as a "converter" is not a
"bridge"
> by any definition of a "bridge" used in 802.
> A "bridge" is:
> - A device that operates at Layer 2 above the MAC
> - A device that couples multiple MACs together
> - Is something that relays packets
> - Is a packet store and forward device
> - Can accommodate differences in speeds between ports
> - Has two or more ports
> - Has a relay functionality between the ports that is standardized in
> 802.1 (and is thus outside the scope of 802.3) Crossing a "bridge"
> with an EPON/EPoC on either side would constitute 2 entirely separate
> TDMA domains that were isolated and separated by the bridge, not an
> extension of one domain across the device.
>
> There are a number of devices on the market that are called "media
> converters" (most often "converting" between fiber and twisted pair).
> These days (unlike days of yore) these are most often two port
> non-filtering bridges. 802.1 has done some work to support such devices.
> 802.1 calls the piece of such a device that is within their scope a "2
> Port MAC Relay (2PMR)"
>
> A "media converter" is a product that is historically unspecified in 802.
> The products sold under this name had a wide variety of performance
> features and ills. It has always been felt in 802.3 that because of
> this, it would be a bad idea to use that term for a standardized device.
>
> As Ed mentioned, there was a device once upon a time in the history of
> 802.3 that was much closer to Jorge's ask. That was the 802.3 10 Mb/s
> repeater (see clause 9 of the standard). In fact, in its earliest
> incarnation, it was used to do "media conversion" between coax and
> fiber. It doesn't match the functionality of what we want now because
> it was a half-duplex device that actually participated in the CSMA/CD
> contention resolution process.
>
> We need a full duplex device. Once upon a time there was such a device
> defined in the FDDI Standards work. It was:
> - Called PHY-REP (Physical Layer Repeater)
> - The small amount of logic required to couple PHYs back-to-back
> - Full duplex
> - A bit store and forward device
> - Provides bit level retiming
> - Was same bit and clock rate on each side We certainly could explore
> developing and standarizing such a device for use in a hybrid EPo
> environment. Whether we could come up with a reasonable box has a lot
> of issues. Some of these were set forth by Mr.
> Yao. Another might be a mismatch of clock rates and encoding on copper vs.
> fiber
>
> Whether such a device is feasible for us certainly a reasonable topic
> for discussion. I would propose calling such a device a "duplex repeater".
>
> Hopefully these messages will help us more forward with greater common
> understanding.
>
> Best regards to all,
>
> Geoff Thompson
>
> On 23//12 2:59 PM, Ed (Edward) Boyd wrote:
>
>> 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@xxxxxxxxxxx
>> E
>> E.ORG>
>> "
>> <STDS-802-3-EPOC@xxxxxxxxxxxxxxxxx<mailto:STDS-802-3-EPOC@xxxxxxxxxxx
>> E
>> E.ORG>
>>
>>
>>>
>>>
>> 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@xxxxxxxxxxxx
>> E
>> .ORG>
>> 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@xxxxxxxxxxxx
>> E
>> .ORG>
>> 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
>>
>>
>>
> ______________________________________________________________________
> __
>
> 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