Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 4878

Definitions and Managed Objects for Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces

Pages: 58
Proposed Standard
Part 1 of 3 – Pages 1 to 8
None   None   Next

Top   ToC   RFC4878 - Page 1
Network Working Group                                          M. Squire
Request for Comments: 4878                             Hatteras Networks
Category: Standards Track                                      June 2007


                  Definitions and Managed Objects for
    Operations, Administration, and Maintenance (OAM) Functions on
                        Ethernet-Like Interfaces

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

This document defines objects for managing Operations, Administration, and Maintenance (OAM) capabilities on Ethernet-like interfaces conformant to the Ethernet OAM functionality defined in the Ethernet in the First Mile (EFM) clauses of the Ethernet standards. The Ethernet OAM functionality is complementary to the Simple Network Management Protocol (SNMP) in that it is focused on a small set of link-specific functions for directly connected Ethernet interfaces. This document defines objects for controlling those link OAM functions and for providing results and status of the OAM functions to management entities.
Top   ToC   RFC4878 - Page 2

Table of Contents

1. Introduction ....................................................2 2. The Internet-Standard Management Framework ......................2 3. Overview ........................................................3 3.1. Remote Fault Indication ....................................4 3.2. Link Monitoring ............................................4 3.3. Remote Loopback ............................................5 3.4. Ethernet OAM Protocol Data Units ...........................5 4. Relation to the Other MIB Modules ...............................5 4.1. Relation to Other MIB Modules ..............................5 4.2. Relation to Other EFM MIB Modules ..........................6 4.3. Mapping of IEEE 802.3ah Managed Objects ....................6 5. MIB Structure ...................................................7 6. MIB Definition ..................................................8 7. Security Considerations ........................................47 8. IANA Considerations ............................................49 9. References .....................................................49 9.1. Normative References ......................................49 9.2. Informative References ....................................50 10. Acknowledgments ...............................................51

1. Introduction

The IEEE 802.3ah Ethernet in the First Mile (EFM) taskforce added new management capabilities to Ethernet-like interfaces. These management capabilities were introduced to provide some basic Ordered Aggregate (OA) function on Ethernet media. The defined functionality includes discovery, error signaling, loopback, and link monitoring. This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community to manage these new Ethernet interface capabilities. Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

2. The Internet-Standard Management Framework

For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP).
Top   ToC   RFC4878 - Page 3
   Objects in the MIB are defined using the mechanisms defined in the
   Structure of Management Information (SMI).  This memo specifies a MIB
   module that is compliant to the SMIv2, which is described in STD 58,
   RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
   [RFC2580].

3. Overview

Ethernet networks have evolved over the past 30 years from simple LANs to a variety of other applications, including wide-area networks. To address some of these emerging markets, the IEEE 802.3ah taskforce defined additional clauses in [802.3ah] for the IEEE 802.3 standard [802.3-2002] to better address Ethernet deployments in the public-access network. Although Ethernet-access deployments were the primary motivation for the taskforce activity, the results of the taskforce are not strictly limited to that application. Ethernet OAM can be implemented on Ethernet links that are not EFM. The Ethernet in the First Mile (EFM) taskforce was focused on four somewhat independent objectives to better address Ethernet access deployments: optics, copper, Ethernet passive optical networks (Ethernet PON, or EPON), and operations, administration, and maintenance (OAM). The optics sub-taskforce developed new optical physical layers that better served the long-reach outside plant networks typically found in the access network, including developing physical layers that operate up to 20 Km and supporting the environmental conditions of access deployments. The copper sub- taskforce developed two new physical layers that run Ethernet natively over existing twisted pair wires that have been supporting voice services for decades. The EPON sub-taskforce developed a new point-to-multipoint Ethernet physical layer, utilizing Ethernet framing natively over a time-division multiple-access (TDMA) infrastructure. The OAM sub-taskforce introduced some basic management functionality into an Ethernet link to better monitor and maintain Ethernet networks in geographically disparate networks. This document defines the management objects necessary to integrate Ethernet OAM functionality into the SNMP management framework. Ethernet OAM is composed of a core set of functions and a set of optional functional groups. The mandatory functions include discovery operations (determining if the other end of the link is OA capable and what OAM functions it supports), state machine implementation, and some critical event flows. The optional functional groups are for (a) link events, (b) remote loopback, and (c) variable retrieval and response. Each optional functional group is controlled by a separate MIB table(s).
Top   ToC   RFC4878 - Page 4
   Ethernet OAM is complementary with SNMP management in that it
   provides some basic management functions at layer two, rather than
   using layer three and above as required by SNMP over an IP
   infrastructure.  Ethernet OAM provides single-hop functionality in
   that it works only between two directly connected Ethernet stations.
   SNMP can be used to manage the Ethernet OAM interactions of one
   Ethernet station with another.

   Ethernet OAM has three functional objectives, which are detailed in
   the next three sections.  The definition of a basic Ethernet OA
   protocol data unit is given in Section 3.4.

3.1. Remote Fault Indication

Remote fault indication provides a mechanism for one end of an Ethernet link to signal the other end that the receive path is non- operational. Some Ethernet physical layers offer mechanisms to signal this condition at the physical layer. Ethernet OAM added a mechanism so that some Ethernet physical layers can operate in unidirectional mode, allowing frames to be transmitted in one direction even when the other direction is non-operational. Traditionally, Ethernet PHYs do not allow frame transmission in one direction if the other direction is not operational. Using this mode, Ethernet OAM allows frame-based signaling of remote fault conditions while still not allowing higher-layer applications to be aware of the unidirectional capability. This document includes mechanisms for capturing that fault information and reflecting such information in objects and notifications within the SNMP management framework.

3.2. Link Monitoring

Ethernet OAM includes event signaling capability so that one end of an Ethernet link can indicate the occurrence of certain important events to the other end of the link. This happens via layer two protocols. This document defines methods for incorporating the occurrence of these layer two events, both at the local end and far end of the link, into the SNMP management framework. Ethernet OAM also includes mechanisms for one Ethernet station to query another directly connected Ethernet station about the status of its Ethernet interface variables and status. This document does not include mechanisms for controlling how one Ethernet endpoint may use this functionality to query the status or statistics of a peer Ethernet entity.
Top   ToC   RFC4878 - Page 5

3.3. Remote Loopback

Remote loopback is a link state where the peer Ethernet entity echoes every received packet (without modifications) back onto the link. Remote loopback is intrusive in that the other end of the link is not forwarding traffic from higher layers out over the link. This document defines objects controlling loopback operation and reading the status of the loopback state.

3.4. Ethernet OAM Protocol Data Units

An Ethernet OAM protocol data unit is a valid Ethernet frame with a destination Media Access Control (MAC) address equal to the reserved MAC address for Slow Protocols (See 43B of [802.3ah]), a lengthOrType field equal to the reserved type for Slow Protocols, and a Slow Protocols subtype equal to that of the subtype reserved for Ethernet OAM. OAMPDU is used throughout this document as an abbreviation for Ethernet OAM protocol data unit. OAMPDUs are the mechanism by which two directly connected Ethernet interfaces exchange OA information.

4. Relation to the Other MIB Modules

The definitions presented here are based on Clauses 30 and 57 of [802.3ah]. Note that these clauses describe many of these variables and their effects on the MAC layer. In some cases, there is a one- to-one relationship between an object in this document and an object in the Clause 30 MIB of [802.3ah]. In other cases, the objects of this document reflect a more complex entity and are reflected by more than one object in the Clause 30 MIB of [802.3ah].

4.1. Relation to Other MIB Modules

The objects defined in this document manage OAM functionality introduced in [802.3ah] These objects do not overlap with the interfaces MIB [RFC2863], the Ethernet-like interfaces MIB [RFC3635], or any other MIB currently used to manage various aspects of an Ethernet interface. The objects defined here are defined for Ethernet-like interfaces only and use the same ifIndex as the associated Ethernet interface. Ethernet OAM can be implemented on any Ethernet-like interface.
Top   ToC   RFC4878 - Page 6

4.2. Relation to Other EFM MIB Modules

The Ethernet OAM functionality and MIB Module is independent of the other functionality and MIB Modules derived from [802.3ah] for copper [802.3ah-copper] and EPON [802.3ah-epon]. Ethernet OAM may be implemented (or not) on the new EFM interface types, just as it can on any other Ethernet interface.

4.3. Mapping of IEEE 802.3ah Managed Objects

This section contains the mapping between managed objects defined in [802.3ah] Clause 30, and managed objects defined in this document. IEEE 802.3 Managed Object Corresponding SNMP object oOA .aOAMID IF-MIB ifIndex .aOAMAdminState dot3OamAdminState .aOAMMode dot3OamMode .aOAMDiscoveryState dot3OamOperStatus .aOAMRemoteMACAddress dot3OamPeerMacAddress .aOAMLocalConfiguration dot3OamFunctionsSupported .aOAMRemoteConfiguration dot3OamPeerFunctionsSupported, dot3OamPeerMode .aOAMLocalPDUConfiguration dot3OamMaxOamPduSize .aOAMRemotePDUConfiguration dot3OamPeerMaxOamPduSize .aOAMLocalFlagsField dot3OamOperStatus, dot3OamEventLogEntry .aOAMRemoteFlagsField dot3OamOperStatus, dot3OamEventLogEntry .aOAMLocalRevision dot3OamConfigRevision .aOAMRemoteRevision dot3OamPeerConfigRevision .aOAMLocalState dot3OamLoopbackStatus .aOAMRemoteState dot3OamLoopbackStatus .aOAMRemoteVendorOUI dot3OamPeerVendorOui .aOAMRemoteVendorSpecificInfo dot3OamPeerVendorInfo .aOAMUnsupportedCodesTx dot3OamUnsupportedCodesTx .aOAMUnsupportedCodesRx dot3OamUnsupportedCodesRx .aOAMInformationTx dot3OamInformationTx .aOAMInformationRx dot3OamInformationRx .aOAMUniqueEventNotificationTx dot3OamUniqueEventNotificationTx .aOAMUniqueEventNotificationRx dot3OamUniqueEventNotificationRx .aOAMDuplicateEventNotificationTx dot3OamDuplicateEventNotificationTx .aOAMDuplicateEventNotificationRx dot3OamDuplicateEventNotificationRx .aOAMLoopbackControlTx dot3OamLoopbackControlTx
Top   ToC   RFC4878 - Page 7
    .aOAMLoopbackControlRx          dot3OamLoopbackControlRx
    .aOAMVariableRequestTx          dot3OamVariableRequestTx
    .aOAMVariableRequestRx          dot3OamVariableRequestRx
    .aOAMVariableResponseTx         dot3OamVariableResponseTx
    .aOAMVariableResponseRx         dot3OamVariableResponseRx
    .aOAMOrganizationSpecificTx     dot3OamOrgSpecificTx
    .aOAMOrganizationSpecificRx     dot3OamOrgSpecificTx

    .aOAMLocalErrSymPeriodConfig    dot3OamErrSymPeriodWindow,
                                    dot3OamErrSymPeriodThreshold
    .aOAMLocalErrSymPeriodEvent     dot3OamEventLogEntry
    .aOAMLocalErrFrameConfig        dot3OamErrFrameWindow,
                                    dot3OamErrFrameThreshold
    .aOAMLocalErrFrameEvent         dot3OamEventLogEntry
    .aOAMLocalErrFramePeriodConfig  dot3OamErrFramePeriodWindow,
                                    dot3OamErrFramePeriodThreshold
    .aOAMLocalErrFramePeriodEvent   dot3OamEventLogEntry
    .aOAMLocalErrFrameSecsSummaryConfig
                                    dot3OamErrFrameSecsSummaryWindow,
                                    dot3OamErrFrameSecssummaryThreshold
    .aOAMLocalErrFrameSecsSummaryEvent
                                    dot3OamEventLogEntry
    .aOAMRemoteErrSymPeriodEvent    dot3OamEventLogEntry
    .aOAMRemoteErrFrameEvent        dot3OamEventLogEntry
    .aOAMRemoteErrFramePeriodEvent  dot3OamEventLogEntry
    .aOAMRemoteErrFrameSecsSummaryEvent
                                    dot3OamEventLogEntry
    .aFramesLostDueToOAmError       dot3OamFramesLostDueToOam
    .acOAMAdminControl              dot3OamAdminState

   There are no IEEE 802.3ah managed objects that are not reflected in
   this MIB Module in some manner.

5. MIB Structure

The Ethernet OAM MIB objects of this memo focus on the OA capabilities introduced in [802.3ah]. The MIB objects are partitioned into six different MIB groups. The dot3OamTable group manages the primary OAM objects of the Ethernet interface. This group controls the state and status of OA as well as the mode in which it operates. The dot3OamPeerTable maintains the current information on the status and configuration of the peer OAM entity on the Ethernet interface. Managed information includes the capabilities and function available on the peer OAM entity.
Top   ToC   RFC4878 - Page 8
   The dot3OamLoopbackTable manages the loopback function introduced in
   [802.3ah].  This table controls enabling and disabling loopback, as
   well as indicating the loopback status of Ethernet OAM on this
   interface.

   The dot3OamStatsTable maintains statistics on the number and type of
   Ethernet OAM frames being transmitted and received on the Ethernet
   interface.

   The dot3OamEventConfigTable defines the objects for managing the
   event notification capability available in Ethernet OAM.  With
   Ethernet OAM, one device may send notifications to its peer devices
   whenever an important event happens on the local device.  This table
   provides management of which events result in notifications via
   Ethernet OAM notifications and/or via SNMP notifications.

   The dot3OamEventLogTable manages the current status of local and
   remote events detected via Ethernet OAM.  This table is updated
   whenever local events are detected by Ethernet OAM or whenever
   Ethernet OAM Event Notifications are received from the peer OA
   entity.

   There are two notifications defined to report Ethernet OAM events
   (one for threshold crossing events, one for non-threshold crossing
   events).  Both notifications are contained within the same
   conformance group.



(page 8 continued on part 2)

Next Section