Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

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
>         > > >                 > >
>         > > >                 >
>
>