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

RE: [EFM] OAM - Faye's seven points

Some OAM traffic is more critical than others.  For example -
OAM command like 'reset' (in our case, reset CPE) should not be
retried.  Certainly don't want to reset the CPE a couple of times 
just because network is slow.  Giving up means sending a technician
to the field to actually toggle the power button on the CPE.  This
is very expensive.  The whole reason of requesting for a dedicated
OAM channel/IPG/whatever is to gurantee that no acutal human
needs to be sent to the field.   Maybe this is not do-able but we
ought to try our best.
On a side note -
Can you please clarify the statement "P2P PHYs do not drop packets"?
This is good.  I don't need to keep all those dropped packets/bytes
error counters then.  Thanks.

	: Geoff Thompson 
	Sent: Tue 9/18/2001 2:38 PM 
	To: bob.barrett 
	Cc: Faye Ly; Geoff Thompson; fkittred; stds-802-3-efm 
	Subject: RE: [EFM] OAM - Faye's seven points
	At 11:25 AM 9/18/01 +0100, Bob Barrett wrote:

		I think your re-stating these seven points is very
timely. If we were at a
		meeting I would suggest that we had a straw poll on each
of them. I would
		add an eighth i.e.
		8. What kind of OAM&P traffic requires guaranteed

	1) We don't do "P". We have already agreed that provisioning is
declared to be outside our scope
	2) There is no such thing as guaranteed delivery
	3) P2P PHYs do not drop packets
	4) Properly designed CSMA/CD LANs do not lose packets. At worst
they try to send for awhile and if they don't get through they give up.

		Short answer: All of it.
		Slight need for clarification: Bob Barrett (me) is an
equipment designer,
		not a service provider. I just happen to have been
designing and selling
		access equipment for the past ten years, rather than
enterprise equipment. I
		learnt about the OAM needs of my customers the hard way,
by building-in what
		I thought were reasonable OAM systems and then being
advised that I had not
		got it quite right (and they don't buy what is not quite
		Nevertheless, I will answer the seven points as I see
them, see below,
		Bob Barrett
		> -----Original Message-----
		> From: Faye Ly [mailto:faye@xxxxxxxxxx]
		> Sent: 17 September 2001 18:32
		> To: bob.barrett@xxxxxxxxxxxxxxx; Geoff Thompson;
		> Cc:
		> Subject: RE: [EFM] OAM developing Geoff's observation.
		> Bob,
		> This largely depends on the requirements.  What kind
of OAM&P traffic
		> requires
		> guaranteed delivery?  And also what kind of
intelligence we require from
		> the
		> CPE and still maintain the low cost.  If you can tell
me what is the
		> requirements
		> for each of the OAM&P traffic listed below:  (This is
the minimum list
		> of
		> OAM&P traffic I can think of)
		> 1. Reset command
		> 2. Link failure/status
		> 3. CPE registration or inventory (The former is the
action and the later
		> is
		> the results).
		Some form of registration, even if it is operator driven
is mandatory.
		Auto registration is desirable.
		> 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
		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.
		> 5. Subscriber activation and deactivation (or
generally referred to as
		> provisioning)
		Mandatory - at the level of EFM this is probably no more
then turning a
		subscriber port on and off, and may be changing an
interface from 10M to
		100M to 1GE. Anything else is above the scope of EFM I
would think.
		> 6. CPE maintanence (upgrade, backup ...)
		Desirable - possibly an area where EFM defines a cooms
channel but not the
		protocol or methodology that vendors implement over it
		> 7. Accounting information on the subscriber line -
optional since some
		> of
		> the accounting data is actually collected at the
aggregated box.
		I agree that this function is not required within the
CPE. However, RMON
		type stats might be useful within the CPE as history for
diagnostics, but
		not required as a source of relable data for billing
information. I think
		this will be a vendor specific thing. The existing
standards define what can
		be done. The vendors will choose what they implement.
The customers will
		choose equipment that has the right balance of features
and commercial terms
		for them.
		> This will be really helpful for the vendors that are
building these
		> equipements
		> to justify for the need or the size of a dedicated
OAM&P channel.
		Sometimes as vendors we have to make inspired guesses
		On Sanjeev Mahalawat's point in an email to/from Faye -
I think it is highly
		desirable that some form of head-end proxy server is
used to translate the
		rather complex management requirements of the NOC NMS
systems into simpler
		commands for the EFM systems. And also take simple alarm
and status messages
		from EFM CPE and create SNMP traps and browser pages for
the human
		interface. Consolidating the 'presentation intelligence
and processing' in a
		head end proxy server shares the cost of the engine
across multiple CPE
		nodes. The CPE needs only a micro-controller (or less),
rather than an
		engine with a full IP stack. Low cost embedded JAVA
processors are coming,
		but they are taking their time :-).
		The EFM technical point is:
		'keep EFM OAM simple; vendors can implement the cleaver
stuff; economically
		this will probably at the head end; there is an
opportunity for silicon to
		do this at the CPE end, but that may take a while'.
		Bob Barrett
		> -faye
		> -----Original Message-----
		> From: Bob Barrett [mailto:bob.barrett@xxxxxxxxxxxxxxx]
		> Sent: Saturday, September 15, 2001 5:36 AM
		> To: Geoff Thompson; fkittred@xxxxxxx
		> Cc:
		> Subject: RE: [EFM] OAM developing Geoff's observation.
		> 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
		> standardised or
		> not, but we would prefer a standard for side band as
part of EFM).
		> Bob Barrett
		> > -----Original Message-----
		> > From:
		> > []On
<>  Behalf Of Geoff
		> > Thompson
		> > Sent: 04 September 2001 23:03
		> > To: fkittred@xxxxxxx
		> > Cc:
		> > Subject: Re: [EFM] OAM loop back / echo server
		> >
		> >
		> >
		> > 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
		> > >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
		> > >
		> > >thanks!
		> > >fletcher
		> >