RE: [EFM] OAM - Faye's seven points
Bob-
At 11:25 AM 9/18/01 +0100, Bob Barrett wrote:
Faye,
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
delivery?
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.
Geoff
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 right).
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;
fkittred@xxxxxxx
> Cc: stds-802-3-efm@ieee.org
> 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
Mandatory
> 2. Link failure/status
Mandatory
> 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 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.
> 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: stds-802-3-efm@ieee.org
> 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 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
> >
>