|
I
stress to all that whatever approach is taken, it is a requirement that the
management traffic gets through an open access point of interconnection.
This in my book favours bridgeable layer 2 in-band management traffic, even
at the expense of waisting a little bit of bandwidth. Doing this
with SNMP on a private VLAN, on a private IP address space will not cut
it.
-=Francois=-
Faye,
I
would like to see a provision for Ethernet frame based OAM. I
believe Ethernet OAM message transport is quite viable for EFM and we should
be seeing some
presentations detailing this approach.
Harry
Roy,
Thank you for the clarification. Dedicated OAM
channel does have the merit of pre-defined and
set-aside bandwidth for mangement traffic. This
not only means some sort of assurance that
OAM will get to the CPE but also helps not
to step over to subscriber's bandwidth.
This is the mechanism I am most familiar with
anyway. I am very open to other mechanism
that makes sense for EFM.
-faye
-----Original Message-----
From: Roy Bynum
Sent: Tue 9/18/2001 7:30 PM
To: Faye Ly
Cc: stds-802-3-efm
Subject: RE: [EFM] OAM - Faye's
seven points
Faye,
Unless you get a bit error that "garbages" an
octet, once a message is
encoded and transmitted, it does not get
dropped while it is in the
link. Full duplex does not even have
to worry about collisions. If the
OAM messaging is in an
"out-of-band" channel there is not even the conflict
of competing with
the data stream for insertion. There is no need for
priority
queuing of the OAM messages in that type of PHY.
At 04:54 PM
9/18/01 -0700, Faye Ly wrote:
>Geoff,
>
>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.
>
>-faye
>
>
>
: 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
>
>
>
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
><mailto:owner-stds-802-3-efm@majordomo.ieee.org%5DOn>
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
>
>
>
>
>
|