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

RE: [EFM] OAM developing Geoff's observation.




Bob,

As a service provider, in order to support certain, most basic, types of 
services, the OAM is required to be "out of band" to the Ethernet frame 
traffic.  This is not an option.  The OAM "side channel" (I do not like 
that term.) can provide a comm function that SNMP messaging can ride on if 
the vendors want to do that.  I am discovering that JINI functionalty is 
getting a lot of attention as well.

Note, there is not an option between IP and PPP.  IP is a layer 3 protocol, 
PPP is a data link protocol for IP that we are replacing with Ethernet.

Thank you,
Roy Bynum
At 01:36 PM 9/15/01 +0100, Bob Barrett wrote:

>I'm late in on this thread, so there may be a similar comment further up my
>in-box from somebody else.
>
>Geoff's observation is pretty fundamental:
>
> > My expectation is that the demarcation device will probably end
> > up with an IP address in order to support:
> >          SNMP for OA&M
> >          Firewall services for the subscriber
> >
> > (That issue is, of course, beyond our scope)
>
>The logical conclusion of this observation is that EFM should make the OAM
>at layer two as simplistic as possible fulfilling only the basic
>requirements i.e. limited number of managed objects and limited echo (L2
>ping) test. Vendors can then leverage ietf standards (note: the users tends
>to like these) to implement ietf style 'standard' management functions.
>Isn't that what we all have in mind anyway :-).
>
>The open question then is will the service provider market accept in-band
>management i.e. management IP frames mixed with user traffic, or is there a
>real requirement for a side-band channel. If EFM does need to include a side
>band channel then all that it needs to be is a communications channel (bit
>stream), probably squeezed in the preamble or the IPG (we can debate that
>choice for a while). Vendors can then implement either a standards based
>method of comms over that channel or do there own thing. Personally I would
>expect vendors to choose something like IP over PPP for this.
>
>I can wrap this all up in a presentation for the next meeting if required.
>
>(Just seen Geoff's comment on this in response to Roy's thread; as a vendor
>we will probably want to support both in-band and side-band, standardised or
>not, but we would prefer a standard for side band as part of EFM).
>
>Bob Barrett
>
> > -----Original Message-----
> > From: owner-stds-802-3-efm@majordomo.ieee.org
> > [mailto:owner-stds-802-3-efm@majordomo.ieee.org]On Behalf Of Geoff
> > Thompson
> > Sent: 04 September 2001 23:03
> > To: fkittred@xxxxxxx
> > Cc: stds-802-3-efm@ieee.org
> > Subject: Re: [EFM] OAM loop back / echo server function
> >
> >
> >
> > Fletcher-
> >
> > I don't think this is a stupid question.
> > I don't think we need an IP level PING
> > A L2 ping would do, perhaps even better, the demarc would look for PING
> > type and then just swap SA & DA.
> > My expectation is that the demarcation device will need a MAC address
> > My expectation is that the demarcation device will probably end
> > up with an
> > IP address in order to support:
> >          SNMP for OA&M
> >          Firewall services for the subscriber
> >
> > (That issue is, of course, beyond our scope)
> >
> > Geoff
> >
> > At 03:47 PM 9/4/01 -0400, Fletcher E Kittredge wrote:
> > >On Fri, 31 Aug 2001 14:11:54 -0700  "Geoff Thompson" wrote:
> > > > 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;
> > >
> > >         Apologies if this is a stupid question, but does PING in this
> > >context mean the utility that sends an IP ICMP ECHO REQUEST packet and
> > >listens for an ECHO REPLY packet?  If so, am I correct in thinking this
> > >means the demarcation device would require an IP address?
> > >
> > >thanks!
> > >fletcher
> >