EPON MIBs

1
EPON MIBs

• Lior Khermosh Passave Technologies
• lior.khermosh_at_passave.com

2
Agenda

• Changes from last draft

3
EFM EPON MIBs

• http//www.ietf.org/internet-drafts/draft-ietf-hub
  mib-efm-epon-mib-01.txt
• Includes
• DOT3-EFM-EPON-MIB
• EPON-DEVICE-MIB

4
DOT3-EFM-EPON-MIB

• MIBs update according to the final IEEE802.3ah
  draft 3.3
• Aligning all parameter to the spec.
• Handle comments from last session
• Editorial
• Technical
• MIB compiling still editorial issues
• Adding a section defining the relationship
  between the objects in this MIB and the
  management objects defined in IEEE802.3ah

5
EPON-DEVICE-MIB

• Add relation to current device MIBs
• EFM EPON MIB
• optical device MIB
• Bridge MIB
• Adding device attributes referenced from DOCSIS
  device MIBs
• MIBs update according to the final IEEE802.3ah
  draft 3.3
• Aligning all parameter to the spec.
• Partitioning the MIBs into the following groups
• Control
• Statistics
• LLID MAC address table
• Events
• Event Logs

6
EPON-DEVICE-MIB

• Handle comments from last session
• Editorial
• Technical
• MIB compiling still editorial issues.
• Aligning all parameter to the spec
• Handle alarms and events according to the event
  MIB adding event state, event enable and event
  logs,
• Remove overlap from EFM MIBs document in OAM
  parameters
• Handling specific comments (in backup slides for
  details if needed)

7
Comments - Raj Subramanian - backup

• 1. Currently, as far as I know, the standard
  802.3ah does not suggest a de-asserting
  mechanism.
• While standard specify a way to report the
  Critical link event, link fault and Dying Gasp
  events in the form of Flags field in the OAMPDU,
  it does not talk about resetting them.
• Similar is the case for all the Errored Events
  though an assertion and de-assertion is possible
  in this case without deviating from the standard,
  I think.
• However all the Global Events, Temperature and
  Voltage specific events and the Vendor
  SpecificAlarm Events, are not defined in the
  standard. Can they be optional then?
• Editors reply Isn't a deasserting mechanism
  also useful? For instance if the link is bad the
  alarm might be received a lot of times. A
  deassertion option will allow to remove such
  alarm.
• Group Looking on more generic alarm/event MIBs
  and adopt the mechanisms. Turning the specific
  solution to a more generic throttling mechanism.
  Take it to the WG list discussion

8
Comments - Raj Subramanian - backup

• 2. One thing I missed to point out in my previous
  mail Attribute eponDeviceObjectOrganizationSpeci
  ficEventState seems to be identical to the
  eponDeviceObjectVendorSpecificEventState
  attribute. Or are they different? Please
  clarify.
• Editors reply Agreed we can add a mechanism to
  insert OUI to identify a vendor - in the event

9
Comments - Raj Subramanian - backup

• eponDeviceObjectOnuLoopback
• In what way is this attribute different from the
  one defined in the EFM MIB, dot3OamLoopbackCommand
  . In an implementation should both of these be
  supported?
• Editors reply eponDeviceObjectOnuLoopback As
  defined now it is redundant and should be removed.

10
Comments - Raj Subramanian - backup

• From eponDeviceObjectDyingGaspAlarmState (Entry
  8) to eponDeviceObjectOrganizationSpecificEventSta
  te(Entry 27)
• The SYNTAX in the MIB attribute says its a
  TruthValue and the description says that this
  bit should be asserted when we receive the
  corresponding event. My question is The bit
  will be set when we receive an event but when
  will we reset it ? It cannot be always 1
  whenever the user reads this attribute, right?
• Editors reply Agreed. De-assertion will be
  added to the text

11
Comments - Raj Subramanian - backup

• eponDeviceObjectTemperatureEventIndicationState,
  eponDeviceObjectPowerVoltageEventIndicationState
  , eponDeviceObjectGlobalEvent0State.
  eponDeviceObjectGlobalEvent7State
• The description says this event defines the
  state of the respective event of the OAM Alarm
  Indications as specified in the 802.3ah clause
  57.
• But I could not locate these attributes in the
  Draft2.0 version of the standard. Can you give me
  pointers as to where I should be looking into?
• Editors reply The alarms are not defined at the
  802.3ah draft. I will remove this reference.
  However I still think that as alarms and event
  for device in access system they are needed so I
  suggest to keep them. I will add a description.

12
Comments - Raj Subramanian - backup

• eponDeviceObjectVendorSpecificAlarmState,
  eponDeviceObjectVendorSpecificEventState
• The description for these two attributes are
  Identical.  I could not a VendorAlarm and a
  VendorEvent, separately in the clause 57. Can you
  give some info please?
•  Editors reply The alarms are not defined at
  the 802.3ah draft. I will remove this reference.
  However I still think that as alarms and event
  for device in access system they are needed. I
  will add a description.
•  
• The difference in my opinion is
• Event is more referring to a system condition
  while alarm indicates a bad thing happening in
  the system.

13
Comments - Raj Subramanian - backup

• eponDeviceObjectPowerDown
• Is setting the PowerDown a valid scenario for the
  EPON?
• Editors reply I think it is. An ONU might have
  a battery back up and when the device is starting
  to get down it indicates Power down. In my
  opinion it is a very important indication for the
  carrier.

14
Comments Jayaprakash Kulkarni - backup

• Is there any specific reason that you have
  included eponDeviceObjectOnuRegisterStatus when
  dot3MpcpRegistrationState is available for
  obtaining the MPCP Registration State?
• Editors reply I will replace that in a more
  clear device attribute - maybe something like
  device ready or ready to transmit/receive data or
  something like that.

15
Comments Jayaprakash Kulkarni - backup

• eponDeviceObjectModes is defined as read-write,
  should it be a read-only value instead? 
•  eponDeviceObjectOamMode is also defined as
  read-write.
• Will eponDeviceObjectModes suffice to identify if
  the device is a oamServer or oamClient? For
  enabling/disabling the oam we could have a truth
  value.
• Editors reply agree that the device modes can
  not be configure through the MIB so it is indeed
  a read-only attribute.
• I think that as for OAM mode is required to
  receive from a device a state mode of its OAM
  where 3 equal options exist - Server client and
  NoOAM. We can add the OAM disabling/enabling in
  addition to that.

16
Authors information

• Lior Khermosh
•  Passave Technologies,
• Ackerstein Towers, Tower A, 6th floor,
• 9 Hamenofim St.
• Hertzliya Pituach 46725,
• ISRAEL
• P.O.Box 2089 Hertzliya Pituach 46120 Israel
• Tel [phone] Ext 7181
• Fax [phone]
• Mob 972-55-224054
• lior.khermosh_at_passave.com