RE: [EFM] OAM - Faye's seven points
Faye,
Most service providers collect accumulated performance information every
15minutes on each network element in the infrastructure. Given the size of
some of the service provider infrastructures, you can imagine how much data
that is. The key to this is that within the operational overhead the
information is accumulated slowly within management gateway processors so
as to not impact the revenue bearing traffic. The management gateway
processors are referred to by different names, depending on the hardware
vendor. They provide a link between the L1 management "side channel" that
interconnects the network elements and upper layer application processes.
At 05:10 PM 9/20/01 -0700, Faye Ly wrote:
>Roy,
>
>Yes, some emails ago I did state that having a side band
>not only ensure OAM traffic will go through but also
>makes sure it doesn't step over to the user data traffic.
>You know sometimes we get carried away with that
>monitoring traffic every 15 minutes :)-
>
>-faye
>
> -----Original Message-----
> From: Roy Bynum
> Sent: Thu 9/20/2001 3:10 PM
> To: Harry Hvostov; Faye Ly; Harry Hvostov; Roy Bynum
> Cc: stds-802-3-efm
> Subject: RE: [EFM] OAM - Faye's seven points
>
>
>
> Harry,
>
> I think that Faye is correct. If the OAM is "frame" based, then
>it will
> share the same bandwidth with the customer traffic. Only if the
>OAM is
> "side band" will it not share the same bandwidth as the customer
>traffic.
>
> Thank you,
> Roy Bynum
>
> At 02:31 PM 9/20/01 -0700, Harry Hvostov wrote:
>
> >Faye,
> >
> >What I meant was that the OAM control frames would not be
>forwarded outside
> >the ePON network.
> >
> >Harry
> >
> >-----Original Message-----
> >From: Faye Ly [mailto:faye@xxxxxxxxxx]
> >Sent: Thursday, September 20, 2001 2:19 PM
> >To: Harry Hvostov; Roy Bynum
> >Cc: stds-802-3-efm
> >Subject: RE: [EFM] OAM - Faye's seven points
> >
> >
> >Harry,
> >
> >I hope I am interpreting your message wrong but
> >
> >OAM traffic usually terminates at the CPU of the
> >network equipment. In our case, there will be one
> >control entity terminated at the CPU of the OLT and
> >one at ONU. Some OAM traffic proxied from OLT to ONU
> >will tranverse the PON link with user data destined
> >for either control end points.
> >
> >-faye
> >
> >-----Original Message-----
> >From: Harry Hvostov [mailto:HHvostov@xxxxxxxxxxxx]
> >Sent: Thursday, September 20, 2001 11:08 AM
> >To: 'Roy Bynum'; Harry Hvostov; Faye Ly
> >Cc: stds-802-3-efm
> >Subject: RE: [EFM] OAM - Faye's seven points
> >
> >
> >
> >Roy,
> >
> >The intent is to terminate OAM control traffic on the ePON
>network
> >(OLT/ONU
> >MAC service interfaces). Since the customer does not have
>access to
> >either
> >the OLT or ONU ports, customer traffic and ePON management
>traffic are
> >effectively separated. We do need to ensure that the
>appropriate
> >forwarding/filtering interfaces and mechanisms are in place to
>enforce
> >this.
> >
> >Harry
> >
> >-----Original Message-----
> >From: Roy Bynum [mailto:roy.bynum@xxxxxxxx]
> >Sent: Thursday, September 20, 2001 8:15 AM
> >To: Harry Hvostov; 'Faye Ly'
> >Cc: stds-802-3-efm
> >Subject: 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
> > > > > >
> > > > >
>
>