RE: [EFM] OAM - Faye's seven points
Harry,
I do not like the idea of inserting frames into the customer traffic. I am
not sure how it would work such that, for security reasons, only the
intended physical interface on a P2MP deployment would receive the OAM
Ethernet frames. Call me paranoid.
Thank you,
Roy Bynum
At 11:33 AM 9/19/01 -0700, Harry Hvostov wrote:
>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
>-----Original Message-----
>From: Faye Ly [mailto:faye@xxxxxxxxxx]
>Sent: Tuesday, September 18, 2001 9:45 PM
>To: Roy Bynum
>Cc: stds-802-3-efm
>Subject: RE: [EFM] OAM - Faye's seven points
>
>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>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>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>mailto:owner-stds-802-3-efm@majordomo.ieee.org]On
>
> ><<mailto:owner-stds-802-3-efm@majordomo.ieee.org%5DOn>mailto:owner-stds-8
> 02-3-efm@xxxxxxxxxxxxxxxxxx%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
> > > >
> > >