RE: [EFM] OAM - Faye's seven points - pings
Bob,
End-to-end "pings" through the service provider "cloud" would probably work
the way that do today. A customer that wants to do end -to-end loop
testing generally uses an upper layer application, such as an IP
"ping". The CSU/DSU technology today allows a test pattern to be generated
in place of the normal data stream, in this case, the Ethernet data
stream. This will test the link regardless of whether the OAM traffic
fully spans the service provider "cloud". This will work regardless of
whether the EFM OAM is frame based or a side channel.
Thank you,
Roy Bynum
At 09:03 PM 9/19/01 +0100, Bob Barrett wrote:
>Faye
>
>I think somebody already made the point that a service provider would not
>want the 'customer/subscriber' being able to send pings into the service
>providers infrastructure. If the service is end to end VPN then the
>subscriber can be enabled to ping through the service providers 'cloud' to
>the subscribers equipment at the far end.
>
>There may be a case for including a ping test within the EFM CPE that is
>only accessible to the service providers engineer for use at installation
>time. However, I think the target is to make the CPE plug and play and do
>all the set-up / initialisation / config. from a central NOC or at worst
>from the POP. You don't necessarily need that much intelligence on the
>service provider side of the demarc (in the CPE) to do this.
>
>On the other OAM thread: the MEF is probably a 'better place' to discuss the
>broader, higher layer issues of management between NOC NMS, proxies and CPEs
>in the context of Ethernet Subscriber Access (ESA). The ietf is probably
>where the 'standards' will be written up as rfcs. There is an MEF technical
>group starting work on this I understand.
>
>Best regards
>
>Bob Barrett
>
> > -----Original Message-----
> > From: Faye Ly [mailto:faye@xxxxxxxxxx]
> > Sent: 18 September 2001 19:06
> > To: bob.barrett@xxxxxxxxxxxxxxx; Geoff Thompson; fkittred@xxxxxxx
> > Cc: stds-802-3-efm@ieee.org
> > Subject: RE: [EFM] OAM - Faye's seven points
> >
> >
> > Bob,
> >
> > Thank you for the response. Please see my comments
> > embedded in <FL> below:
> >
> > >> 4. Connectivity diagnose (ping etc) - This is divided into link
> > >> connectivity which
> > >> can be covered by 2 and subscriber line connectivity.
> >
> > >Mandatory for the link, up to a point as close to the subscriber
> > interface
> > >as possible e.g. copper loop back on the connector side of the IC, in
> > the
> > >last output stage of the IC (most PHY ICs support this already).
> >
> > >Tests to the subscriber equipment are outside of the scope of EFM, but
> > in
> > >real terms the service provider will probably PING something on the
> > >subscriber network, given access rights.
> >
> > <FL> Very good point. I always thought what they need is
> > ping-ing from subscriber side to the upstream router to
> > test the connectivity. Not the other way around.
> > So when subscriber calls and complains about a problem
> > with his/her connectivity, I guess you need to:
> >
> > 1. First find out from your network map to see if you
> > have gotten a report somewhere stating a box fault or
> > line card fault. Either one is in the way of this
> > subscriber. You also validate this by ping-ing the
> > CPE from the head-end?
> >
> > 2. If 1 is not true, you ping the subscriber's PC or
> > CPE port from the router? Note that the requirements
> > on the OAM is quite different from having to be able
> > to ping from the CPE port to the router. The later
> > requires the CPE to accept such a 'ping' request
> > from the NOC.
> >
> > Your thoughts?
> >
> > -faye
> >