|Thread Links||Date Links|
|Thread Prev||Thread Next||Thread Index||Date Prev||Date Next||Date Index|
I would like to support Roy opinion that we need some kind of OOB OAM channel within the PHY.
This will enable link quality test (like BER, delays, delay jitter etc.) to make sure the customer indeed gets the QoS he ordered. Especially when we will start services like VOIP & Video together with Data.
Where else we can achieve these goals beside the PHY?
From: Matt Squire [mailto:mattsquire@xxxxxxx]
Sent: Wednesday, September 05, 2001 2:49 AM
To: Roy Bynum
Cc: Geoff Thompson; email@example.com
Subject: Re: [EFM] OAM loop back / echo server function
I don't think I buy the argument that OAM has to be present at the
The wire will have some physical bit capacity based on whatever encoding
mechanisms it uses. Management will take some of that bandwidth away.
But management can certainly be done above the physical level, and
the MAC level using appropriate queueing and prioritization. Why do you
so strongly that it must be at the phy?
Roy Bynum wrote:
> There will need to be some physical layer command functionality in order
> to provide management functions that are not data traffic invasive. That
> is one of the requirements of the OAM. If it is not done within the EFM
> physical layer, then the service will only be "best effort" and not the
> high margin services that will be required to pay for the infrastructure
> deployment of EFM.
> Thank you,
> Roy Bynum
> At 03:38 PM 9/4/01 -0700, Geoff Thompson wrote:
> >I'm not sure that I understand what you mean.
> >You seem to be making some assumptions about what constitutes "OAM
> >overhead" that I do not.
> >What I meant was that tying the transmit data stream directly to the
> >receive data stream at the physical level is a bad idea when you are part
> >of a live network. Since we don't have the concept of turning circuits up
> >and down that means it is a bad idea all of the time.
> >That has nothing to do with any "Loopback Protocol" which might reflect a
> >payload back at a transmitting entity inside valid Ethernet packets.
> >At 03:12 PM 9/4/01 -0500, Roy Bynum wrote:
> >>What about a "loop back" within the OAM overhead? That would be able to
> >>function regardless of the Ethernet traffic and network. It may not be
> >>what some people are wanting, but it is better than nothing.
> >>Thank you,
> >>Roy Bynum
> >>At 02:11 PM 8/31/01 -0700, Geoff Thompson wrote:
> >>>This reminds me how dumb I get sometimes in that I did not jump on this
> >>>I believe that Bob is correct in his statement that looping back
> >>>Ethernet is a really bad idea.
> >>>I'll say it again more explicitly:
> >>> Raw physical loopback of Ethernet is a really bad idea.
> >>>It breaks/screws up networks that were not designed to tolerate it.
> >>>As I have said before, I do believe that we will need a demarcation
> >>>device that has the capability to host OA&M functions.
> >>>We have talked about "loop back" from this point in the network.
> >>>Let us forevermore make that "PING"
> >>>At 12:02 PM 8/30/01 -0700, Denton Gentry wrote: