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).
AbstractThis 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.
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
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]. 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. 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
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
SLD - Start of LLID Delimiter TDM - Time Division Multiplexing TQ - Time Quanta 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
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. 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.
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 / /===================/
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. 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. 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.
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.
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
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.
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.
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. 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.
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.
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 | | ---------
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.
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.