RE: [EFM] OAM - Faye's seven points
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
> > > > > >
> > > > >
>
>