RE: [802.3ae] Query : 10G Ethernet RMON status !!!
I did not change the subject line, though IMO the question does not relate specifically to 10G Ethernet.
That is an interesting question. My interpretation is that 'lack of resources' in a probe includes all that stands between what is running on the wire, and what is being counted by the probe. As Geoff Thompson pointed the RMON authors had rather in mind the probe memory and processing resources. On the other hand, there is no mapping of the aFramesLostDueToIntMACRcvError object in any other counter in the etherStats MIB group. The reasonable interpretation would then be to add the value of this counter to the number of events that fall under etherStatsDropEvents.
However, I am not aware about implementations doing it actually.
Regards,
Dan
> -----Original Message-----
> From: David Law [mailto:David_Law@xxxxxxxxxxxx]
> Sent: Tuesday, April 23, 2002 1:37 PM
> To: Romascanu, Dan (Dan)
> Subject: Re: [802.3ae] Query : 10G Ethernet RMON status !!!
>
>
>
>
> Hi Dan,
>
> Do you want to look after this one, its a bit of a IEEE to
> IETF mapping issue
> however I would expect that they will be looking to
> ultimately implement the
> RMON functionality. I also guess you might want to CC the
> reply to the relevant
> IETF reflector as well.
>
> Best regards,
> David Law
>
>
>
>
>
>
> "Kamal Jain" <j.kamal@xxxxxxxxxxxxx>@majordomo.ieee.org on
> 23/04/2002 11:39:49
>
> Please respond to "Kamal Jain" <j.kamal@xxxxxxxxxxxxx>
>
> Sent by: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
>
>
> To: <stds-802-3-hssg@xxxxxxxx>
> cc:
> Subject: [802.3ae] Query : 10G Ethernet RMON status !!!
>
>
> Hi All,
>
> Can somebody clarify me on the following two definitions
> for Ethernet frames
>
> - "aFramesLostDueToIntMACRcvError", section 5.2.2.1.15 from
> IEEE-802.3-2000 Std,
>
> Definition : A count of frames that would otherwise be
> received by the station,
> but
> could not be accepted due to an internal MAC sublayer receive
> error. If this
> counter is incremented, then none of the other counters in
> this subclause are
> incremented.The exact meaning and mechanism for incrementing this
> counter is implementation dependent.
>
> - "etherStatsDropEvents", RFC 1757, Remote Network Monitoring
> Management
> Information Base (MIB)
>
> Definition : "The total number of events in which packets
> were dropped by the
> probe due to
> lack of resources. Note that this number is not necessarily
> the number of
> packets
> dropped; it is just the number of times this condition has
> been detected."
> ::= { etherStatsEntry 3 }
>
> Are both the definitions same from the
> implementation point of view.
> For example, if we define the Ingress (Rx) FIFO overflow
> error as a MAC internal
> error,
> then can it be taken as the "lack of resources" in
> "etherStatsDropEvents".
> Otherwise, can the "etherStatsDropEvents" be defied as the
> drop events for
> packets which
> has been dropped/discarded because of some filtering options,
> while receiving an
> Ethernet frame.
>
> Looking forward for an early response.
>
> Rgds
> Kamal Jain [SMTS]
> GDA Technologies Ltd.
>
>
>
>
>
>