[EFM] OAM Tools vs. Requirements
All,
I have posted this on the OAM list but I fear the list has been dormant for
a while now, so I am posting it here in the hope of generating some
discussion on the matter
Nadav
Passave
-----Original Message-----
From: owner-stds-802-3-efm-oam@majordomo.ieee.org
[mailto:owner-stds-802-3-efm-oam@majordomo.ieee.org]On Behalf Of Nadav
Aharony
Sent: Tuesday, November 27, 2001 11:14 AM
To: stds-802-3-efm-oam@ieee.org; mattsquire@acm.org
Subject: RE: [EFM-OAM] Proposed initial OAM Requirements
Hi to all,
I would like to continue the OAM discussion and try to drill a bit down in
the details.
The list seems to be a mix of OAM "tools" (such as the dying gasp or the
ping) and general requirements (such as the RFI).
Is there a complete analysis of the OAM needs? (I have not seen one so far)
The so called tools are there to help us meet the OAM requirements. For
example, if the OAM includes fault detection and isolation, I think we need
a list of all possible faults in the EFM system. After we have the complete
list, we can start thinking of how 802.3's scope can aid in discerning them
from one another, isolating them, localizing them etc.
A very big problem is that many faults have the same symptoms. For this, we
need new "tools" to use, or extend the use of our current tools. Another
very important output is a list of what 802.3 is incapable of solving, so
that we know our limitations.
This applies to all aspects of the OAM - service monitoring, security, etc.
If there is such a list please direct me to it.. if not - I think its a good
idea to get started on one.
(-) Nadav Aharony
Passave Networks
> -----Original Message-----
> From: owner-stds-802-3-efm-oam@majordomo.ieee.org
> [mailto:owner-stds-802-3-efm-oam@majordomo.ieee.org]On Behalf Of Matt
> Squire
> Sent: Friday, November 09, 2001 5:42 AM
> To: stds-802-3-efm-oam@ieee.org
> Subject: [EFM-OAM] Proposed initial OAM Requirements
>
>
>
>
> Hi to all EFM OAMers -
>
> In order to make progress in this shortened meeting schedule, we've been
> having some offline discussions trying to document the requirements and
> scope for any OAM solution produced by this group. At the upcoming
> meeting, I will be making a presentation on behalf of (hopefully) many
> contributors on the results of these discussions. I wanted to throw
> these out there early so you can comment and/or ask questions.
>
> The following requirements seemed to have consensus from the offline
> discussions. The wording still requires some work, but I think you can
> get the intent. Functions not covered by these requirements are out of
> scope for this group.
>
> 1) Symmetric EFM PHYs should support a PHY level loopback.
>
> 2) EFM must support a "ping" test, where a frame is sent to a
> destination and the destination echoes the packet contents back to the
> source.
>
> 3) Loopback functions must be controllable both locally and remotely.
>
> 4) EFM must include safeguards to prevent a station from staying in a
> loopback indefinitely (timers, reliable reset, etc.)
>
> 5) EFM OAM must support read access to an arbitrary set of variables
> defined by 802.3.
>
> 6) The method must be extensible to variables defined outside of 802.3
> as well.
>
> 7) Setting/writing variables is NOT a requirement (no link management).
>
> 8) EFM OAM must support generic event notification procedures with an
> extensible event set.
>
> 9) One of the initially defined events must be a diagnostic last gasp.
> An initial set of diagnostic capabilities for this event must be
> defined.
>
> 10) EFM PHYs should support PHY level RFI for the local link with
> diagnostics.
>
> 11) Signaling failure of remote links is not a requirement of EFM OAM
> ("remote links" are links on the far end of device on the other end of
> the local link - on the customer side of the CPE, for example).
>
> 12) EFM OAM must provide a general control communications mechanism for
> EFM OAM purposes, and that can be made available to higher layer
> management entities.
>
> 13) Other organizations/vendors may use this communications mechanism to
> add additional OAM functionality.
>
> 14) EFM OAM must support both peer-to-peer and master-slave models.
>
> 15) Everything in EFM OAM must fall under the 802.3 umbrella (ie a
> single link).
>
>
> There was also one subject on which consensus could not be reached.
> That is, what kind of affect can the addition of OAM to a link have on
> user traffic? Given the current proposals under consideration, you can
> probably understand how this might be controversial. There are, I
> think, two camps:
>
> A) OAM can have zero affects on the performance and characteristics of
> the link.
> B) OAM can have very limited effects on the performance and
> characteristics of the link.
>
> So thats where we stand on OAM requirements. Fire away.
>
> - Matt