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

RE: [EFM] OAM loop back / echo server function

Title: Message
I would advocate sticking to the spirit of Ethernet and would prefer not having any OOB OAM channel.  From my experience, there is just too much politics surrounding the control and the access to such mechanisms.  I would appreciate that those whom are promoting the use of OOB OAM provide a detailed argumentation as to why there is simply no way around providing this information in-band through new L2 mechanisms (if new mechanisms are required), and how those would traverse an EFM Point Of Interconnection (POI) to multiple service providers.
-----Original Message-----
From: [] On Behalf Of Itzik Hendel
Sent: September 5, 2001 5:54 AM
To: 'mattsquire@xxxxxxx'; Roy Bynum
Cc: Geoff Thompson;
Subject: RE: [EFM] OAM loop back / echo server function

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?

Itzik Hendel

-----Original Message-----
From: Matt Squire [mailto:mattsquire@xxxxxxx]
Sent: Wednesday, September 05, 2001 2:49 AM
To: Roy Bynum
Cc: Geoff Thompson;
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
physical level. 
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
probably above
the MAC level using appropriate queueing and prioritization.  Why do you
so strongly that it must be at the phy?

- Matt

Roy Bynum wrote:
> Geoff,
> 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
> WorldCom
> At 03:38 PM 9/4/01 -0700, Geoff Thompson wrote:
> >Roy-
> >
> >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.
> >
> >Geoff
> >
> >At 03:12 PM 9/4/01 -0500, Roy Bynum wrote:
> >>Geoff,
> >>
> >>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:
> >>
> >>>All-
> >>>
> >>>This reminds me how dumb I get sometimes in that I did not jump on this
> >>>earlier.
> >>>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"
> >>>
> >>>Geoff
> >>>
> >>>At 12:02 PM 8/30/01 -0700, Denton Gentry wrote:
> >>>