tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 4837

Proposed STD
Pages: 91
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: HUBMIB

Managed Objects of Ethernet Passive Optical Networks (EPON)

Part 1 of 5, p. 1 to 17
None       Next RFC Part

 


Top       ToC       Page 1 
Network Working Group                                        L. Khermosh
Request for Comments: 4837                                    PMC-SIERRA
Category: Standards Track                                      July 2007


      Managed Objects of Ethernet Passive Optical Networks (EPON)

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 a portion of the Management Information Base
   (MIB) for use with network management protocols in TCP/IP based
   Internets.  In particular, it defines objects for managing interfaces
   that conform to the Ethernet Passive Optical Networks (EPON) standard
   as defined in the IEEE Std 802.3ah-2004, which are extended
   capabilities to the Ethernet like interfaces.

Top       Page 2 
Table of Contents

   1.  The Internet-Standard Management Framework . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Terminology and Abbreviations  . . . . . . . . . . . . . .  3
     2.2.  EPON Architecture Highlights . . . . . . . . . . . . . . .  5
       2.2.1.  Introduction . . . . . . . . . . . . . . . . . . . . .  5
       2.2.2.  Principles of Operation  . . . . . . . . . . . . . . .  6
       2.2.3.  The Physical Media . . . . . . . . . . . . . . . . . .  7
       2.2.4.  PMD Specifications . . . . . . . . . . . . . . . . . .  8
       2.2.5.  Point-to-Point Emulation . . . . . . . . . . . . . . .  8
       2.2.6.  Principles of the MPCP . . . . . . . . . . . . . . . . 10
       2.2.7.  Forward Error Correction (FEC) . . . . . . . . . . . . 12
     2.3.  Management Architecture  . . . . . . . . . . . . . . . . . 13
   3.  MIB Structure  . . . . . . . . . . . . . . . . . . . . . . . . 17
   4.  Relation to Other MIB Modules  . . . . . . . . . . . . . . . . 22
     4.1.  Relation to the Interfaces MIB and Ethernet-like
           Interfaces MIB . . . . . . . . . . . . . . . . . . . . . . 22
     4.2.  Relation to the IEEE 802.3 MAU MIBs  . . . . . . . . . . . 29
     4.3.  Relation to the EFM OAM MIB  . . . . . . . . . . . . . . . 29
     4.4.  Relation to the Bridge MIB . . . . . . . . . . . . . . . . 30
   5.  Mapping of IEEE 802.3ah Managed Objects  . . . . . . . . . . . 31
   6.  Definitions - The DOT3 EPON MIB Module . . . . . . . . . . . . 33
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 85
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 86
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 86
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 88
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 88
     10.2. Informative References . . . . . . . . . . . . . . . . . . 90

Top      ToC       Page 3 
1.  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).  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].

2.  Overview

   This document defines a portion of the Management Information Base
   (MIB) for use with network management protocols in TCP/IP based
   Internets.  In particular, it defines objects for managing interfaces
   that conform to the Ethernet Passive Optical Networks (EPON) standard
   as defined in [802.3ah], which are extended capabilities to the
   Ethernet like interfaces.  The document contains a list of management
   objects based on the attributes defined in the relevant parts of
   [802.3ah] Annex 30A, referring to EPON.

2.1.  Terminology and Abbreviations

   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 [RFC2119].

   ACK - Acknowledge

   BER - Bit Error Rate

   BW - Bandwidth

   CO - Central Office

   CPE - Customer Premises Equipment

   CRC - Cyclic Redundancy Check

   EFM - Ethernet First Mile

   EPON - Ethernet Passive Optical Network

   FCS - Frame Check Sequence

Top      ToC       Page 4 
   FEC - Forward Error Correction

   GMII - Gigabit Media Independent Interface

   LAN - Local Area Network

   LLID - Logical Link Identifier

   MAC - Media Access Control

   Mbps - Megabit per second

   MDI - Medium Dependent Interface

   MDIO - Management Data Input/Output

   MPCP - Multi-Point Control Protocol

   MP2PE - Multi-Point to Point Emulation

   OAM - Operation Administration Maintenance

   OLT - Optical Line Terminal (Server unit of the EPON)

   OMP - Optical Multi-Point

   ONU - Optical Network Unit (Client unit of the EPON)

   P2MP - Point-to-Multipoint

   P2PE - Point-to-Point Emulation

   PCS - Physical Coding Sublayer

   PHY - Physical Layer

   PMA - Physical Medium Attachment

   PMD - Physical Medium Dependent

   PON - Passive Optical Network

   RS - Reconciliation Sublayer

   RTT - Round Trip Time

   SLA - Service Level Agreement

Top      ToC       Page 5 
   SLD - Start of LLID Delimiter

   TDM - Time Division Multiplexing

   TQ - Time Quanta

2.2.  EPON Architecture Highlights

2.2.1.  Introduction

   The EPON standard, as defined in [802.3ah], defines the physical
   media (Layer 1) and media access (Layer 2) of the EPON interface.
   The EPON is a variant of the Gigabit Ethernet protocol for the
   Optical Access.  The Optical Access topology is based on passive
   optical splitting topology.  The link of a Passive Optical Network
   (PON) is based on a single, shared optical fiber with passive optical
   splitters dividing the single fiber into separate subscribers.

   The Optical Line Terminal (OLT) is the server unit of the network,
   located at the Central Office (CO).

   The Optical Network Unit (ONU) is the client unit of the network,
   located at the Customer Premises Equipment (CPE).

   The following diagram describes the PON topology:

               Device with
               one or more P2MP
               interfaces such as OLT
               for EPON                       An EPON          IP host
               ------- OLT          ONU       "modem"          --------
    Other IEEE |     | interface |  interface ------ Other IEEE|      |
    interface  |     |-------\----------------|    | interface |      |
    ===========|     |        \               |    |===========|      |
               |     |         \              ------           --------
               |     |          \             ------           --------
               .     .           \------------|    |           |      |
               |     |------\                 |    |===========|      |
               |     |       \                ------           --------
               -------        \ etc

Top      ToC       Page 6 
   The IEEE layering architecture of an EPON interface is defined in the
   diagram of Figure 56.2 [802.3ah].  The following clauses in the
   [802.3ah] define the corresponding layers of an EPON interface:

   clause 30 - Management

   clause 60 - PMD for EPON media (Burst PMD)

   clause 64 - MPCP (Multi-Point Control Protocol) - defines the Multi-
   Point architecture, and control protocol for the media access of
   EPON.

   clause 65 -

   a) Virtual links definition for the EPON

   b) FEC

   c) PMA for the EPON.

2.2.2.  Principles of Operation

   The specification of the EPON interface is based on the specification
   of the gigabit Ethernet interface as described in [802.3], clauses 35
   and 36.  The Ethernet MAC is working in gigabit rate.  The media
   interface to the MAC is through the GMII interface, as described in
   clause 35, and the PCS layer is based on the gigabit Ethernet PCS as
   described in clause 36.  The special EPON layers are added to the
   Ethernet layering in the following places:

   The MPCP is placed in the MAC control layer, providing the EPON
   control protocol.  The Emulation layer, located at the RS
   (Reconciliation Sublayer), creates virtual private path to each ONU.
   The FEC layer is located between the PCS and PMA layers, enhancing
   reach and split performance of the optical link.

Top      ToC       Page 7 
   The following diagram describes the layering model of an EPON
   interface:

      +==========================================+
      |               Higher layers              |
      +==========================================+
      |               802.1D Bridge              |
      +==========================================+
      | MAC client|        ...        |MAC client|
      +==========================================+
      |           MAC Control - (MPCP)           |            *NEW*
      +==========================================+
      |    MAC    |        ...        |    MAC   |
      +==========================================+
      |           P2P Emulation (P2PE)           |            *NEW*
      +==========================================+
                      |            |
                      |    GMII    |
                      |            |
      +==========================================+
      |                    PCS                   |
      +==========================================+
      |                    FEC                   |            *NEW*
      +==========================================+
      |                    PMA                   |  *Enhanced parameters
      +==========================================+    for EPON*
      |                    PMD                   |  *Enhanced parameters
      +==========================================+    for EPON*
                      |            |
                      |    MDI     |
                      |            |
                    /===================/
                   /       Media       /
                  /===================/

2.2.3.  The Physical Media

   The physical link is a fiber optical link.  The OLT and ONUs are
   connected through passive optical splitters.  Downlink denotes the
   transmission from the OLT to the ONUs.  Uplink denotes the
   transmission from the ONUs to the OLT.  Uplink and downlink are
   multiplexed using separated wavelengths on the same fiber.  The
   downlink is a broadcast medium where the OLT transmits the data to
   all ONUs.  The uplink is a shared transmission medium for all of the
   ONUs.  The uplink access is based on time division multiplexing (TDM)
   and the management of the TDM media access is defined by the Multi-

Top      ToC       Page 8 
   Point Control Protocol (MPCP).  The MPCP is a control protocol based
   on an inband packet messaging.  The OLT sends control messages (GATE
   messages) allowing ONUs to transmit, defining when the transmission
   occurs and what is its duration.  These messages define the
   transmission order and the amount of BW for each ONU.  A scheduling
   algorithm at the OLT, which is not defined in the [802.3ah], is
   responsible for allocating the BW and controlling the delay of each
   ONU according to its SLA.

2.2.4.  PMD Specifications

   PMD specifications select the same optical wavelength plan as the
   [ITU-T.G.983].  The transceivers are derivatives of existing Ethernet
   optical transceivers, with dual wavelength on a single fiber, and
   extended burst capabilities for the uplink.  The uplink burst
   capability is the burst transmission functionality for the ONUs and
   burst reception functionality for the OLT.  The [802.3ah] selected
   very relaxed burst parameters to reduce the device cost of EPON
   products.

2.2.5.  Point-to-Point Emulation

   The downstream is a broadcast link, which means that the OLT
   transmission is shared for all ONUs.  The sharing of the transmission
   of the OLT has some negative privacy aspects and should be limited to
   broadcast traffic in nature only.  The traffic dedicated to each ONU
   should not be shared.  The solution provided by [802.3ah] is to
   partition the EPON link, in a virtual manner, between the ONUs.  Each
   ONU has a dedicated virtual link to the OLT.  The [802.3ah] also
   defines an additional link for broadcast transmission.  The medium
   becomes an aggregation of point-to-point tunnels.  The OLT cannot
   preserve its EPON interface as a single interface connected to N
   devices (following the properties of the physical interface).  The
   EPON interface of the OLT is partitioned into separate virtual
   interfaces; an interface for each virtual link.  Hence, the OLT
   behaves like a device with N virtual ports (and an additional port
   for the broadcast transmission).  The additional single-copy-
   broadcast channel (tagged as all one LLID) is added to allow the
   broadcast transmission within a single copy to all ONUs, preserving
   the inherent advantage of BW efficiency of the PON shared media.  The
   ONUs filter the downlink traffic that is not intended for their
   reception, according to the virtual link marking.  An LLID tag is
   attached at the preamble of the Ethernet packet denoting the virtual
   link.  The LLID marks the destination port in the downstream and
   source port in the upstream.

Top      ToC       Page 9 
   The virtual links concept is also used to avoid a violation of the
   [802.1d] bridging rules for peer-to-peer traffic in the PON.  Peer-
   to-peer traffic is traffic between ONUs in the same PON.  The OLT
   cannot preserve the EPON interface as a single interface, connected
   to N devices, and allow traffic between these devices without
   violating the bridging rules.  The source address and destination
   address of the peer-to-peer traffic are behind the same port and
   therefore the traffic should be discarded.  The separation of the
   ONUs into virtual links solves this issue.  The OLT has N virtual
   ports for the single physical EPON port.  A bridge sees a single MAC
   Client for every link pair.

   The private paths concept solves the networking problems and provides
   subscriber isolation.

   As the tunneling is only a virtual tunneling, there is a single
   physical interface and a single physical layer for the device so that
   some attributes are shared.  For example, the interface has a single
   local MAC address.

   The virtual tunneling for an OLT with 3 ONUs is illustrated in the
   following diagram.

Top      ToC       Page 10 
                         Trunk Line
                             |
                             |
                             |
                            \|/
      +===============================================+
      |                 802.1D Bridge                 |
      +===============================================+
      | MAC client1|          ...         |MAC client3|
      +===============================================+
      |                     MP2PE                     |
      +===============================================+
      |                      PHY                      |
      =================================================
             |                 |                 |
             |                 |                 |
            \|/               \|/               \|/
      +============+    +============+    +============+
      |    PHY     |    |     PHY    |    |     PHY    |
      +============+    +============+    +============+
      |   MP2PE    |    |    MP2PE   |    |    MP2PE   |
      +============+    +============+    +============+
      | MAC client |    | MAC client |    | MAC client |
      +============+    +============+    +============+
      |    PHY     |    |     PHY    |    |     PHY    |
      +============+    +============+    +============+
            /|\               /|\               /|\
             |                 |                 |
             |                 |                 |
             |                 |                 |
        Subscriber1       Subscriber2       Subscriber3

2.2.6.  Principles of the MPCP

   The EPON standard defines a media access control of an optical Access
   network.  The Access network has some substantial differences from
   the legacy LAN for which the Ethernet was designed.  The differences
   lie mainly in the provisioning of the network.  An Access network is
   an administrated environment, with an operator providing the service
   and subscribers consuming it.  The operator is controlling the
   network and managing its traffic.  For instance, BW is controlled and
   subscribers are billed for services.  The MPCP protocol divides the
   Ethernet interfaces into two unequal types of network units.  The
   first interface is an OLT interface, which is a server unit,
   controlling the network.  The second interface is an ONU interface,
   which is a client unit, participating in the network.

Top      ToC       Page 11 
   The OLT, which is the server unit, manages the network.  The MPCP
   controls the TDM transmission of the uplink.  The MPCP is implemented
   at the MAC control layer and the MPCP messages are MAC control
   messages using the 0x8808 Ethertype.  These messages are not
   forwarded out of the MAC.

   A concept of time must exist in the protocol in order to schedule the
   uplink transmission.  A timestamp, which is set by the OLT and
   synchronized between the network units, is passed through the MPCP
   messages.  The timestamp is also used to measure the RTT of each ONU.
   RTT is compensated by the OLT in the generation of the grants for the
   uplink transmission.  The difference of incoming timestamp to local
   time allows the OLT to calculate the RTT.  RTT compensation is needed
   as the RTT in an Access network can have a significant value.  The
   standard allows the network to reach a 20 km distance, which is
   equivalent to a 200 usec RTT (25 Kbytes of data).

   The TDM control is done using GATE messages.  These messages define,
   for each ONU, the time for transmission and the length of
   transmission.  The RTT is reduced from the transmission time in the
   GATE message to shift the transmission time of the ONU in the
   opposite direction.

   A scheduling algorithm at the OLT, which is not defined in the
   [802.3ah], is responsible for dividing the BW and controlling the
   transmission delay of each ONU according to its SLA.  The MPCP
   defines a closed loop operation in order for this algorithm to be
   efficient.  The MPCP allows the ONUs to report on the amount of BW
   they require for transmission using a special REPORT message.  This
   allows allocating BW to an ONU only when requested, relying on the
   statistical burst property of the traffic, and allowing different
   peak BW for different ONUs at different times; hence, allowing
   oversubscription of the BW.  The REPORT message reports the amount of
   data waiting in the ONU queues.

   In addition, the MPCP defines a protocol of auto-discovery and
   registration of ONUs.

Top      ToC       Page 12 
   The registration process is defined in the diagram below:

      OLT                                          ONU
       |                                            |
       |          Discovery Gate message           \|
       |--------------------------------------------|
       |                                           /|
       |                                            |
       |/         Register Request message          |
       |--------------------------------------------|
       |\                                           |
       |                                            |
       |          Register message                  |
       |           (assigning LLID)                \|
       |--------------------------------------------|
       |                                           /|
       |                                            |
       |               Gate message                \|
       |--------------------------------------------|
       |                                           /|
       |                                            |
       |/         Register ACK message              |
       |--------------------------------------------|
       |\                                           |
       |                                            |
       |                                            |

   A new ONU requests to register (sends a REG_REQUEST message) in a
   special discovery grant, allocated for that by the OLT.  During that
   time, more than one ONU might try to register.  A collision in
   transmission might occur, as the RTT of the new ONUs is not yet
   known.  A random backoff mechanism of the transmission is used to
   schedule the following registration requests to avoid these
   collisions.  When the OLT receives a REG_REQUEST message of an ONU
   and approves this ONU, then it sends a REGISTER message to this ONU
   defining its LLID.  From that point, the ONU transmission is
   scheduled by its LLID, knowing the RTT, and no collision can occur.
   The ONU replies with a REGISTER_ACK message and the registration
   process of the MPCP ends.  Higher layer protocols may be needed to
   authenticate the ONU and allow it to participate in the network.

2.2.7.  Forward Error Correction (FEC)

   The FEC is defined to enhance the link budget of the PON.  As each
   splitter attenuates the optical signal, the number of the splits and
   the distance are limited by the link budget.  Hence an FEC that

Top      ToC       Page 13 
   improves the link budget has a benefit.  The FEC code used is the
   RS(239,255,8), similar to the FEC code in [ITU-T.G.975], improving
   the BER from 1E-4 to 1E-12.

   The FEC parity encapsulation is based on the framing of the Ethernet
   packet.  The Ethernet packets are spaced by MAC rate adaptation, and
   the parity bytes are inserted after the packet in the provided space.

   As the start and end of packet codewords also define the FEC
   boundaries, and they are outside the FEC protection, they are
   replaced by a series of symbols to reduce their vulnerability to
   errors.

   The following diagram presents an FEC-protected frame:

   +-------------------------------------------------------------------+
   |       |              |           |     |       |          |       |
   | S_FEC | Preamble/SFD |   Frame   | FCS | T_FEC |  Parity  | T_FEC |
   |       |              |           |     |       |          |       |
   +-------------------------------------------------------------------+

   The FEC is added in a separate layer between the PCS and PMA layers
   of the [802.3].

   The FEC layer introduces a fixed delay in receive path and transmit
   path.

   The FEC layer is optional.

2.3.  Management Architecture

   Each one of the EPON layers is accompanied by a management interface
   that is controlled through clause 30 of the [802.3ah].  As the
   [802.3ah] specification may be used for different applications, and
   some of the clauses may be used separately, the IEEE management
   clause allocates for each one of them a separate package.  The MIB
   document follows this partition.

Top      ToC       Page 14 
   The following diagram presents the relation of the MIB groups to the
   [802.3ah] layers:

   +===========================+
   |       Higher layers       |
   +===========================+
   |       802.1D Bridge       |
   +===========================+
   |MAC client| ... |MAC client|
   +===========================+    \ +=============================+
   |   MAC Control - (MPCP)    |----- |MpcpObjects| ... |MpcpObjects|
   +===========================+    / +=============================+
   |   MAC    | ... |   MAC    |
   +===========================+    \ +=============================+
   |    P2P Emulation (P2PE)   |----- |OmpEmulat  |     |OmpEmulat  |
   +===========================+    / |ionObjects | ... |ionObjects |
             |        |               +=============================+
             |  GMII  |
             |        |
   +===========================+
   |            PCS            |
   +===========================+    \ +=============================+
   |            FEC            |----- |FecObjects | ... |FecObjects |
   +===========================+    / +=============================+
   |            PMA            |
   +===========================+
   |            PMD            |
   +===========================+
             |        |
             |  MDI   |
             |        |
         /===============/
        /     Media     /
       /===============/

   The association is straightforward for the ONU interface.  There is
   one logical and one physical interface, and a single copy exists for
   each layer that can be remotely queried by the OLT.

   At the OLT there is a single physical interface and N virtual
   interfaces for the virtual links of the ONUs (and another virtual
   interface for the broadcast virtual link).  As can be seen from the
   layering diagram above, the MAC layer is virtually duplicated.
   Therefore, in this document it was selected that the management of a
   virtual interface is like a physical interface, an interface index is
   allocated for each one of the virtual links, and an additional
   interface index is allocated for the OLT.

Top      ToC       Page 15 
   To illustrate the interface modeling consider two devices; the first
   device has two physical interfaces, is typically located at a
   consumer's site, and is called an "ONU modem".

   An "ONU modem" is shown in the figure below:

                            --------
             ONU interface | ONU   | 10 megabit interface
             --------------| modem |--------------------
                           ---------

   This device would have 3 entries in the IF table, and one IF stack
   entry; for example:

   ifIndex=1 - interface for 10 megabit interface

   ifIndex=2 - interface for the optical interface

   ifIndex=200 - interface for the ONU interface

   And then in the IF stack table:

   ifStackHigherLayer=200, ifStackLowerLayer=2 - map between the
   physical and the ONU

   The second device has three physical interfaces, is typically located
   at the provider's site, and may be called a "headend".

   A "headend" is shown in the figure below:

                               ---------
             1st OLT interface | Head  | gigE interface
             ------------------| end   |--------------------
                               |       |
             ------------------|       |
             2nd OLT interface |       |
                               ---------

Top      ToC       Page 16 
   This device would have 5 entries (when there are no attached ONUs) in
   the IF table, for example:

   ifIndex=1 - interface for gigE interface

   ifIndex=2 - interface for 1st optical interface

   ifIndex=3 - interface for 2nd optical interface

   ifIndex=265535 - interface for the 1st OLT broadcast interface

   ifIndex=365535 - interface for the 2nd OLT broadcast interface

   And then in the IF stack table:

   ifStackHigherLayer=265535, ifStackLowerLayer=2 - map between the 1st
   physical and its broadcast interface

   ifStackHigherLayer=365535, ifStackLowerLayer=3 - map between the 2nd
   physical and its broadcast interface

   If two ONUs connected to the first OLT interface, then for example,
   the following entries would be added to the IF table:

   ifIndex=200001 - interface for the 1st ONU of 1st OLT

   ifIndex=200002 - interface for the 2nd ONU of 1st OLT

   And in the IF stack table:

   ifStackHigherLayer=200001, ifStackLowerLayer=2 - map between the 1st
   physical and 1st ONU

   ifStackHigherLayer=200002, ifStackLowerLayer=2 - map between the 1st
   physical and 2nd ONU

   For each physical interface, there would be an entry (ifIndex) in the
   tables of the interface MIB module [RFC2863], MAU MIB module
   [RFC4836], and Etherlike MIB module [RFC3635].  Additionally, there
   would be entries (ifIndexes) for the virtual interfaces of the OLT
   interface.  The justification for the additional allocation of
   indexes is that the virtual interfaces are quite well distinguished,
   as they connect different physical ONUs from the OLT side.  For
   instance, there is a meaning for separate bad frames counter or bad
   octets counter for each virtual link, as the ONUs can be differently
   distanced.  This is quite similar to a case of separate physical
   interfaces.

Top      ToC       Page 17 
   The same partition concept exists for the MIB module of this
   document.  Each row in the tables are indexed according to the
   ifIndex; specifically, there is a row for each virtual link.  There
   are some control objects that are shared and are the same for the
   virtual interfaces (and they should have the same value for each
   ifIndex), but most of the objects have different values for N+1
   logical interfaces at the OLT.  This is done for each MIB group.  It
   is a bit different from the [802.3ah] layering diagram, which
   presents the P2MP layer as a single layer, while duplicating the MAC
   and MAC client layers (please see the diagram above).  However, from
   a management perspective, it is more convenient and neat to partition
   the management of the layers for the virtual links, as the atomic
   managed entity is the virtual link.  It is also convenient to use the
   interface index of the virtual link for that purpose, as it is
   already used to index the rows of the virtual links at the Interface,
   MAU, and etherLike interfaces MIBs.



(page 17 continued on part 2)

Next RFC Part