advertisement
ISSUED
Cable Data Services
DOCSIS® Provisioning of EPON Specifications
DPoE™ OAM Extensions Specification
DPoE-SP-OAMv2.0-I03-130808
Notice
This DPoE specification is the result of a cooperative effort undertaken by certain member companies of Cable Television Laboratories, Inc. for the benefit of the cable industry and its customers. This document may contain references to other documents not owned or controlled by
CableLabs®. Use and understanding of this document may require access to such other documents. Designing, manufacturing, distributing, using, selling, or servicing products, or providing services, based on this document may require intellectual property licenses from third parties for technology referenced in this document.
Neither CableLabs nor any member company is responsible to any party for any liability of any nature whatsoever resulting from or arising out of use or reliance upon this document, or any document referenced herein. This document is furnished on an "AS IS" basis and neither
CableLabs nor its members provides any representation or warranty, express or implied, regarding the accuracy, completeness, noninfringement, or fitness for a particular purpose of this document, or any document referenced herein
Cable Television Laboratories, Inc., 2011-2013
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
DISCLAIMER
This document is published by Cable Television Laboratories, Inc. ("CableLabs®").
CableLabs reserves the right to revise this document for any reason including, but not limited to, changes in laws, regulations, or standards promulgated by various agencies; technological advances; or changes in equipment design, manufacturing techniques, or operating procedures described, or referred to, herein. CableLabs makes no representation or warranty, express or implied, with respect to the completeness, accuracy, or utility of the document or any information or opinion contained in the report. Any use or reliance on the information or opinion is at the risk of the user, and CableLabs shall not be liable for any damage or injury incurred by any person arising out of the completeness, accuracy, or utility of any information or opinion contained in the document.
This document is not to be construed to suggest that any affiliated company modify or change any of its products or procedures, nor does this document represent a commitment by CableLabs or any cable member to purchase any product whether or not it meets the described characteristics. Nothing contained herein shall be construed to confer any license or right to any intellectual property, whether or not the use of any information herein necessarily utilizes such intellectual property. This document is not to be construed as an endorsement of any product or company or as the adoption or promulgation of any guidelines, standards, or recommendations. ii
CableLabs
08/08/13
DPoE™ OAM Extensions Specification
Document Status Sheet
DPoE-SP-OAMv2.0-I03-130808
Document Control Number: DPoE-SP-OAMv2.0-I03-130808
Document Title: DPoE™ OAM Extensions Specification
Revision History: I01 - Released 10/04/12
I02 - Released 03/28/13
I03 - Released 08/08/13
Date: August 8, 2013
Status:
Work in
Progress
Distribution Restrictions:
Author
Only
Draft
Issued
CL/Member CL/ Member/
Vendor
Closed
Public
Key to Document Status Codes
Work in Progress An incomplete document, designed to guide discussion and generate feedback that may include several alternative requirements for consideration.
Draft
Issued
Closed
A document in specification format considered largely complete, but lacking review by Members and vendors. Drafts are susceptible to substantial change during the review process.
A stable document, which has undergone rigorous member and vendor review and is suitable for product design and development, cross-vendor interoperability, and for certification testing.
A static document, reviewed, tested, validated, and closed to further engineering change requests to the specification through CableLabs.
Trademarks
CableLabs® is a registered trademark of Cable Television Laboratories, Inc. Other CableLabs marks are listed at http://www.cablelabs.com/certqual/trademarks . All other marks are the property of their respective owners.
08/08/13
CableLabs
iii
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Contents
iv
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
08/08/13
CableLabs
v
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
vi
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
08/08/13
CableLabs
vii
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
viii
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
Figures
Figure 17 - Set Loopback for D-ONU S
08/08/13
CableLabs
ix
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Tables
x
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
08/08/13
CableLabs
xi
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
xii
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
08/08/13
CableLabs
xiii
DPoE-SP-OAMv2.0-I03-130808
This page intentionally left blank
Cable Data Services xiv
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
1 INTRODUCTION
DOCSIS Provisioning of EPON (DPoE) version 2.0 specifications are a joint effort of Cable Television Laboratories
(CableLabs), cable operators, vendors, and suppliers to support EPON technology using existing DOCSIS-based back-office systems and processes. DPoE v2.0 specifications augment the DPoE v1.0 specifications to provide requirements for additional service capabilities and corresponding provisioning and network management capabilities.
multi-access optical network. A multi-access optical network is an optical fiber based network technology that permits more than two network elements to transmit and receive on the same fiber.
DPoE specifications are focused on DOCSIS-based provisioning and operations of Internet Protocol (IP) using
DOCSIS Internet service (which is typically referred to as High Speed Data (HSD)), or IP(HSD) for short, and
Metro Ethernet services as described by Metro Ethernet Forum (MEF) standards. DPoE Networks offer IP(HSD) services functionally equivalent to DOCSIS networks, where the DPoE System acts like a DOCSIS CMTS and the
DPoE System and DPoE Optical Network Unit (ONU) together act like a DOCSIS CM.
1.1 DPoE Technology Introduction
DPoE technology was established with the following common requirements already developed by operators. Each of the participant operators had previously selected 1G-EPON and 10G-EPON as the appropriate technology for one or more applications. EPON is a widely-deployed technology with a sufficient and large supply of vendors offering a variety of products for each component of the access network. 10G-EPON technology is now becoming available and is backwards compatible with 1G-EPON. A 1G-EPON network can be incrementally upgraded to 10G-EPON,
The EPON protocol [802.3ah] and the amendment for 10G-EPON [802.3av] support a point-to-multipoint
architecture with a centralized controller called an Optical Line Terminal (OLT) and distributed low cost Layer 2
ONUs. The basic service mapping architecture in EPON is to map Ethernet (or IP) frame header information (e.g., addresses, IP DiffServ Code Points, Ethernet Q tag, S-VLAN/C-VLAN ID, ISID, bridge address, etc.) to a logical
networks in many ways because it is based on a centralized scheduler and uses an LLID which functions like an
SID, supports both unicast and broadcast, and has other similarities.
testing, field trials, and deployments has shown operators that 1G-EPON OLT and ONU systems typically only
interface) but does not specify any of the other system interfaces. For example, an OLT from vendor A will register an ONU from vendor B, but it is not possible to construct a VLAN from the DPoE MN interface to an S interface.
OAMP to forward traffic between Network to Network Interface (NNI) ports (I-NNI for MEF or NSI for L2VPN or
IP(HSD)) and the PON, or UNI ports and the PON. This is not different from other Ethernet standards. For example, if two Ethernet switches from two different vendors are connected, each switch must typically be configured independently. The challenge for EPON is that the remote device (the ONU) cannot be reached, and therefore cannot be configured. A solution to this problem must then be based on developing a common (standard) method of reaching the controller for the ONU, identifying the ONU capabilities, and providing that information to the OLT so that it can configure the ONU to forward traffic.
Even if EPON had solved that provisioning challenge, there are no standard management interfaces for the ongoing operations and maintenance of the network, including fault management, performance management, security, etc.
Operators already have fully working and scaled-out systems that solve these challenges for DOCSIS networks. One of the primary goals for DPoE specifications is to use the existing DOCSIS back-office infrastructure to scale up
EPON-based business services.
08/08/13
CableLabs
1
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
1.2 Scope
Since the vCM operates on the DPoE System (instead of the D-ONU), a means of communication from the vCM to
for messaging between the vCM on the DPoE System and the D-ONU. The OAM Extensions specified here provide
specifications allow vendor-specific OAM extensions. This document describes the usage of this extension feature to provide for a common set of OAM extensions to support interoperability between all vendors that choose to develop products in accordance with the DPoE specifications.
This document defines the interface used for conveying management information between a DPoE System and D-
ONU. This specification defines message format and contents for the following types of configuration or information collection:
• General management and device capabilities
• Forwarding provisioning
• Statistics collection
• Alarm status
• Security key exchange
• Frame processing and classification
• Quality of Service provisioning
• Time Synchronization (ToD, Frequency, and Phase)
Implementations that conform to this specification are required to implement all the features defined in this specification.
that conform to this specification must fully interoperate with other DPoE implementations that conform to this specification regardless of the presence or absence of other OAM extensions.
1.3 DPoE OAM Specification Goals
The goals of the DPoE OAM Specification are to:
• Provide a common method of managing D-ONUs from different vendors to ensure interoperability;
• Define packet formats and data encodings to support DPoE features;
• Provide a "toolkit" of features from which these DPoE features can be constructed (rather than just assign monolithic blocks of parameters for each feature individually);
• Establish specifications for OAM parameters, behavior, and extended features where such are needed;
• Limit complexity and cost of D-ONU devices by adapting L2 management protocols previously used in EPON.
2
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
1.4 Requirements
Throughout this document, the words that are used to define the significance of particular requirements are capitalized. These words are:
"MUST"
"MUST NOT"
"SHOULD"
This word means that the item is an absolute requirement of this specification.
This phrase means that the item is an absolute prohibition of this specification.
This word means that there may exist valid reasons in particular circumstances to ignore this item, but the full implications should be understood and the case carefully weighed before choosing a different course.
"SHOULD NOT" This phrase means that there may exist valid reasons in particular circumstances when the listed behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label.
"MAY" This word means that this item is truly optional.
One vendor may choose to include the item because a particular marketplace requires it or because it enhances the product, for example; another vendor may omit the same item.
1.5 DPoE Version 2.0 Specifications
refer to http://www.cablelabs.com/dpoe/specifications.
Table 1 - DPoE 2.0 Series of Specifications
Designation
DPoE-SP-ARCHv2.0
DPoE-SP-DEMARCv2.0
DPoE-SP-OAMv2.0
DPoE-SP-PHYv2.0
DPoE-SP-SECv2.0
DPoE-SP-IPNEv2.0
DPoE-SP-MULPIv2.0
DPoE-SP-MEFv2.0
DPoE-SP-OSSIv2.0
DPoE-SP-SOAMv2.0
Title
DPoE Architecture Specification
DPoE Demarcation Device Specification
DPoE OAM Extensions Specification
DPoE Physical Layer Specification
DPoE Security and Certificate Specification
DPoE IP Network Element Requirements
DPoE MAC and Upper Layer Protocols Interface Specification
DPoE Metro Ethernet Forum Specification
DPoE Operations and Support System Interface Specification
DPoE Service-OAM Specifications
08/08/13
CableLabs
3
4
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
1.6 Reference Architecture
The DPoE reference architecture identifies the elements that a DPoE Network minimally requires to illustrate and communicate the physical hardware and logical software interfaces between the functional subsystems of the DPoE architecture. The principal elements in the architecture are the DPoE System that resides in the operator network, and the DPoE ONU (D-ONU) which may be an off- the-shelf EPON ONU, EPON SFP-ONU, or an EPON ONU with additional subsystems. The remaining elements in the architecture are existing servers and systems in the operator’s network. All the server elements have connectivity through an IP (TCP/IP) network. Transport of bearer traffic, and (in some cases) Layer 2 OAM Protocol Data Units (PDUs) are available through either IP or Layer 2
Ethernet-based Network Interfaces. sSAFE SNMP eSAFE SNMP
IP(HSD)
DPoE-SP-IPNEv2
SSH2
Telnet
TACACS+
RADIUS
HTTP
NTP
FTP/SFTP
TFTP
SNMP
DPoE-SP-OSSIv2
TFTP
DHCP
SNMP
DPoE-SP-IPNEv2
Routing
ARP
NDP
IS-IS
OSPF
MP-BGP
MPLS
VPLS
LDP vCM
OSS
R
P
IP Network
R
PE
R/X
VSI n
R
PE
(VE)
VSI
2
VSI
1
X
IEEE
802.1
Switch
PBB
I-BEB
OLT eSAFE EVCs
DPoE-SP-OAMv2
EPON OAM + EPON OAM Extensions
DPoE-SP-PHY
ODN
LLID
LLID
LLID
LLID
LLID
LLID
SF
SF
SF
SF
SF
SF
LLID
LLID
LLID
LLID
LLID
LLID
ASF
ASF
ASF
ASF
ASF
ASF
SF
7.1+7.2
SF
8.1+8.2
SF
9
SF
10.1+11
SF
10.2
SF
12
SF
1
SF
2
SF
3
SF
4
SF
5
SF
6
S-ONU
X
IEEE
802.1
Switch
SF
1
SF
S1.2
SF
3
SF
4
SF
5
SF
6
SF
7.1
SF
7.2
SF
8.1
SF
8.2
SF
9
SF
10.1
SF
10.2
SF
11
SF
12
WiFi eDVA eRouter sSAFE
EVCs
MESP
MESP
MESP
MESP
MESP
MESP
MESP
MESP
MESP
LLID ASF SF
1
MESP
CPE
WiFi sDVA
CPE
CPE
DEMARC
DEMARC
DEMARC
CE
CE
CE
CE
CE
CE
CE
DPoE System
LLID ASF
SF
2
MESP
B-ONU
X
IEEE
802.1
Switch
CE
CE
IEEE 802.3 (EPON)
IEEE 1904.1 (SIEPON)
DEMARC
D
LCI
CPE
CMCI
DPoE-SP-SOAM
DPoE-SP-MEFv2
MEF EVCs
KEY
Converged IP Interface
Logical CPE Interface
Customer Premise Equipment (CMCI only)
Cable Modem CPE Interface
MN
MI
MU
CE
MEF NNI or INNI (and L2VPN NSI)
MEF INNI
MEF UNI
Customer Equipment (MU only)
SF
ASF
MESP
Service Flow
Aggregate Service Flow
Metro Ethernet Service Profile
(OPTIONALLY CONFIGURED
Figure 1 - DPoEv2.0 Reference Architecture
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
1.7 DPoE Interfaces and Reference Points
The DPoE interfaces and reference points provide a basis for the description and enumeration of DPoE specifications for the DPoE architecture. Each interface or reference point indicates a point between separate subsystems. The reference points have protocols that run across them, or have a common format of bearer traffic
(with no signaling protocol). All the interfaces are bi-directional interfaces that support two-way communications.
CableLabs specifications. The C reference points are uni-directional for upstream (C
O
) or downstream (C
S
) classification, respectively. sSAFE SNMP eSAFE SNMP
DPoE-SP-IPNEv2
SSH2
Telnet
TACACS+
RADIUS
HTTP
NTP
FTP/SFTP
TFTP
SNMP
DPoE-SP-OSSIv2
TFTP
DHCP
SNMP
D
DPoE-SP-IPNEv2
Routing
ARP
NDP
IS-IS
OSPF
MP-BGP
MPLS
VPLS
LDP
C
S
IP(HSD) eSAFE EVCs
C
O
S
1
LCI CMCI MU
vCM
OSS
IP Network
R
P
R
PE
R/X
VSI n
R
PE
(VE)
VSI
2
VSI
1
X
IEEE
802.1
Switch
MN
I
PBB
I-BEB
DPoE System
MN
E
OLT
Reference
Interface
(GREEN)
Reference
Point
(GREEN)
Interface
(RED)
EPON OAM + EPON OAM Extensions
TU
DPoE-SP-OAMv2
TUL
DPoE-SP-PHY
ODN
LLID
LLID
LLID
LLID
LLID
LLID
SF
SF
SF
SF
SF
SF
LLID
LLID
LLID
LLID
LLID
LLID
ASF
ASF
ASF
ASF
ASF
ASF
SF
7.1+7.2
SF
8.1+8.2
SF
9
SF
10.1+11
SF
10.2
SF
12
SF
1
SF
2
SF
3
SF
4
SF
5
SF
6
LLID ASF SF
1
MESP
S-ONU
X
IEEE
802.1
Switch
SF
1
SF
S1.2
2
SF
3
3
SF
4
4
SF
5
SF
6
SF
7.1
SF
7.2
SF
8.1
SF
8.2
SF
9
SF
10.1
SF
10.2
SF
11
SF
12 sSAFE
EVCs
MESP
MESP
MESP
MESP
MESP
MESP
MESP
MESP
MESP
CMIM 1
WiFi eDVA eRouter
CPE
9
CPE
5
WiFi
CPE
6
7
8
MI
sDVA
DEMARC
DEMARC
10
DEMARC
11
12
CMIM
1
IEEE 802.3 (EPON)
IEEE 1904.1 (SIEPON)
Virtual
Interface
(RED)
D
LCI
CPE
CMCI
DPoE-SP-SOAM
DPoE-SP-MEFv2
MEF EVCs
KEY
Converged IP Interface
Logical CPE Interface
Customer Premise Equipment (CMCI only)
Cable Modem CPE Interface
MN
MI
MU
CE
LLID ASF
2
SF
2
MESP
B-ONU
MI
X
IEEE
802.1
Switch
S
2
DEMARC
MU Tags
802.1d MAC
802.1q VLAN
802.1ad
MI Tags
802.1d MAC
802.1q VLAN
802.1ad
802.1ah ISID
MEF NNI or INNI (and L2VPN NSI)
MEF INNI
MEF UNI
Customer Equipment (MU only)
SF
ASF
MESP
Service Flow
Aggregate Service Flow
Metro Ethernet Service Profile
(OPTIONALLY CONFIGURED
CE
CE
CE
CE
CE
CE
CE
CE
CE
Figure 2 - DPoEv2.0 Interfaces and Reference Points
CableLabs
08/08/13 5
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Table 2 - DPoEv2.0 Interface and Reference Point Descriptions
Interface or
Reference Point
MN
D
TU
TUL
C
MN
MN
C
O
E
I
Interface or Reference Point Description
MN is a logical concept used for the specification of requirements for MEF INNI that apply to both MN
E
and MN
I
. MN logically provides the equivalent function of a MEF INNI or
L2VPN NSI. It is an NNI for Metro Ethernet services only.
The MN
E
(MEF INNI External) interface is a substitute for the MN reference interface from
DPoE version 1.0 specifications. The MN interface is an [802.3] interface for Ethernet (or
MEF or L2VPN emulated) services only. It serves the role of a MEF INNI or L2VPN NSI. It is an NNI for Metro Ethernet services only.
The MN
I
reference interface is used to describe the virtual interface between an OLT and a
VPLS Virtual Switch Instance (VSI). In particular, it is used to describe the requirements for
stitching VSIs to DPoE System and OLT [802.1] components such as [802.1d] bridge groups,
[802.1ad] S-VLAN or C-VLAN (S-component or C-component), or [802.1ad] I-BEB (I-
component) or B-BEB (B-component) backbone edge bridges. The DPoE System stitches
VPLS and VPWS transport and forwarding for Metro Ethernet Services between the D interface and the MN
I
reference interface
.
The D interface is the DOCSIS IP NNI interface. It is an operator network-facing interface, sometimes called a Network Systems Interface (NSI) in DOCSIS specifications. The D interface allows a DPoE System to communicate with an IP network. The D interface carries all IP management traffic including OSSI and IP NE traffic. The D interface carries all
DOCSIS IP service traffic, IP/MPLS/VPLS traffic, and IP/MPLS/VPWS traffic.
The TU interface is the interface between the DPoE System and the D-ONU.
The TUL interface is a virtual interface representing a logical EPON on an ODN. Each ODN has at least one TUL, and each TUL represents a MAC domain.
The C reference point is used for explanation of traffic ingress to a DPoE classifier.
The C
O
reference point is used for explanation of traffic ingress to a D-ONU upstream classifier.
C
S
S
S
S
1
2
The C
S
reference point is used for explanation of traffic ingress to a DPoE System downstream classifier.
The S interface is an IEEE 802 interface. The S interface may be an internal interface, such as
[802.3] across a SERDES (GMII or XGMII) interface in a BP-ONU (such as an SFP-ONU,
SFP+ONU or XFP-ONU), or it may be an external Ethernet interface in a BB-ONU or S-
ONU.
S
1
is an interface for an S-ONU. S
2
is a reference point used for explanation of services with the B-ONU.
The S
1
interfaces are the general case of all interfaces on an S-ONU. S
1
interfaces may be
CMCI, LCI, MI, or MU interfaces.
The S
2
reference point is used for explanation of traffic ingress to and egress from interfaces on a DEMARC device in a DPoE System. Although there are no specifications or requirements for the S
2
reference point, informative text refers to the S
2
reference point to provide the full context for the use of a B-ONU with a DEMARC device providing Metro
Ethernet services.
1
MN
I
is required for IP-based forwarding and transport of Metro Ethernet services with DPoE in order to provide MEF E-LAN and E-TREE services described in DPoE version 2.0. While these services can be constructed with MN
E
, these specifications do not describe the process to do so.
6
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
Interface or
Reference Point
LCI
CMCI
MI
MU
Interface or Reference Point Description
The Logical CPE Interface (LCI) interface is an eDOCSIS interface as defined in
[eDOCSIS]. eSAFEs are connected to LCI interfaces.
CMCI is the DPoE interface equivalent of the DOCSIS Cable Modem CPE Interface as
defined in [CMCIv3.0]. This is the service interface for DOCSIS-based IP services. Customer
Premise Equipment (CPE) is connected to CMCI interfaces.
MI is an S interface that operates as a MEF INNI with additional requirements as specified in
[DPoE-MEFv2.0]. The MI interface is an [802.3] interface (or reference point) between a D-
ONU and a DEMARC device.
A D-ONU that provides a MEF INNI has an MI interface.
A D-ONU can have MU as an interface and an MI reference point on different S interfaces in a single D-ONU.
DEMARC devices are connected to MI interfaces.
MU is an S interface (or S reference interface) that operates as a MEF UNI. The MU
reference interface is an [802.3] interface (or reference point) between a D-ONU or a
DEMARC device and a customer's equipment.
A D-ONU that directly provides a MEF UNI (MU) interface has MU as an interface.
A D-ONU can have MU as an interface and an MI reference point on different S interfaces in a single D-ONU.
Customer Edge (CE) devices are connected to MU interfaces.
08/08/13
CableLabs
7
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
2 REFERENCES
2.1 Normative References
In order to claim compliance with this specification, it is necessary to conform to the following standards and other works as indicated, in addition to the other requirements of this specification. Notwithstanding, intellectual property rights may be required to use or implement such normative references. At the time of publication, the editions indicated were valid. All references are subject to revision, and users of this document are encouraged to investigate the possibility of applying the most recent editions of the documents listed below. References are either specific
(identified by date of publication, edition number, version number, etc.) or non-specific. For a non-specific reference, the latest version applies.
compliance to IEEE Std. 802.1Q-2011. Unless otherwise stated, claiming compliance to 802.1Q-2005 requires a specific date reference.
[802.1]
[802.1d]
[802.1Q]
[802.3]
[802.3av]
Refers to entire suite of IEEE 802.1 standards unless otherwise specified.
IEEE Std. 802.1d™-2004, IEEE Standard for Local and Metropolitan Area Networks: Media
Access Control (MAC) Bridges.
IEEE Std. 802.1Q-2011, IEEE Standard for Local and Metropolitan Area Networks - Media
Access Control (MAC) Bridges and Virtual Bridge Local Area Networks, August 2011.
IEEE Std. 802.3-2008, IEEE Standard for Carrier Sense Multiple Access with Collision
Detection (CSMA/CD) access method and Physical Layer specifications, January 2008.
IEEE 802.3AV-2009, IEEE Standard for Information technology-Telecommunications and information systems-Local and metropolitan area networks-Specific requirements, Part 3:
Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and
Physical Layer Specifications Amendment 1: Physical Layer Specifications and Management
Parameters for 10Gb/s Passive Optical Networks.
[DPoE-
ARCHv2.0]
[DPoE-
DEMARCv.2.0]
DOCSIS Provisioning of EPON, DPoE Architecture Specification, DPoE-SP-ARCHv2.0,
Cable Television Laboratories, Inc.
DOCSIS Provisioning of EPON, DPoE Demarcation Device Specification, DPoE-SP-
DEMARCv2.0, Cable Television Laboratories, Inc.
[DPoE-IPNEv2.0] DOCSIS Provisioning of EPON, IP Network Element Requirements, DPoE-SP-IPNEv2.0,
Cable Television Laboratories, Inc.
[DPoE-MEFv2.0] DOCSIS Provisioning of EPON, Metro Ethernet Forum Specification, DPoE-SP-MEFv2.0,
Cable Television Laboratories, Inc.
[DPoE-
MULPIv2.0]
DOCSIS Provisioning of EPON, MAC and Upper Layer Protocols Interface Specification,
DPoE-SP-MULPIv2.0, Cable Television Laboratories, Inc.
[DPoE-OSSIv2.0] DOCSIS Provisioning of EPON, Operations and Support System Interface Specification,
DPoE-SP-OSSIv2.0, Cable Television Laboratories, Inc.
[DPoE-PHYv2.0] DOCSIS Provisioning of EPON, Physical Layer Specification, DPoE-SP-PHYv2.0, Cable
Television Laboratories, Inc.
[DPoE-SECv2.0] DOCSIS Provisioning of EPON, Security and Certificate Specification, DPoE-SP-SECv2.0,
Cable Television Laboratories, Inc.
[DPoE-
SOAMv2.0]
DOCSIS Provisioning of EPON, DPoE Service-OAM Specification, DPoE-SP-SOAMv2.0,
Cable Television Laboratories, Inc.
8
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
2.2 Informative References
This specification uses the following informative references.
[1588v2]
[802.1ad]
[802.1ag]
IEEE Std. 1588 2008, IEEE Standard for a Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems, July 2008.
IEEE Std. 802.1ad™-2005, IEEE Standard for Local and Metropolitan Area Networks – Virtual
Bridged Local Area Networks Amendment 4: Provider Bridges, May 2006. Former amendment to
802.1Q, now part of 802.1Q-2011.
IEEE Std. 802.1ag-2007, IEEE Standard for Local and Metropolitan Area Networks – Virtual
Bridged Local Area Networks Amendment 5: Connectivity Fault Management, December 2007.
[802.1ah]
[802.1p]
IEEE Std. 802.1ah-2008, IEEE Standard for Local and Metropolitan Area Networks – Virtual
Bridged Local Area Networks – Amendment 6: Provider Backbone Bridges, January 2008.
Former amendment to 802.1Q, now part of 802.1Q-2011.
IEEE 802.1p-2004, LAN Layer 2 QoS/CoS Protocol For Traffic Prioritization.
[802.3ah] IEEE 802.3ah™-2004, Amendment to IEEE 802.3™-2005: Media Access Control Parameters,
Physical Layers, and Management Parameters for Subscriber Access Networks, now part of
[CMCIv3.0] Data-Over-Cable Service Interface Specifications, Cable Modem to Customer Premise Equipment
Interface Specification, CM-SP-CMCIv3.0, Cable Television Laboratories, Inc.
[DOCSIS] Refers to entire suite of DOCSIS 3.0 specifications unless otherwise specified.
[eDOCSIS] Data-Over-Cable Service Interface Specifications, eDOCSIS Specification, CM-SP-eDOCSIS,
Cable Television Laboratories, Inc.
[MULPIv3.0] Data-Over-Cable Service Interface Specifications, MAC and Upper Layer Protocols Interface
Specification, CM-SP-MULPIv3.0, Cable Television Laboratories, Inc.
[OSSIv3.0] Data-Over-Cable Service Interface Specifications, Operations Support System Interface
Specification, CM-SP-OSSIv3.0, Cable Television Laboratories, Inc.
[PHYv3.0] Data-Over-Cable Service Interface Specifications, Physical Layer Specification, CM-SP-
PHYv3.0, Cable Television Laboratories, Inc.
[RFC 5462] IETF RFC 5462, Multiprotocol Label Switching (MPLS) Label Stack Entry: "EXP" Field
Renamed to "Traffic Class" Field, L. Andersson, R. Asati, February 2009.
[SCTE 174] ANSI/SCTE 174 2010, Radio Frequency over Glass Fiber-to-the-Home Specification.
[SECv3.0] Data-Over-Cable Service Interface Specifications, Security Specification, CM-SP-SECv3.0, Cable
Television Laboratories, Inc.
[SFF-8077i] SFF-8077i 10 Gigabit Small Form Factor Pluggable Module, Revision 4.5, released April 13,
2004.
[SFF-8472] SFF-8472 Specification for Diagnostic Monitoring Interface for Optical Transceivers, Revision
10.4, released January 2009.
[SFP MSA] INF 8074i Rev 1.0, Small Form-factor Pluggable Multi-Source Agreement, released May 2001.
08/08/13
CableLabs
9
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
2.3 Reference Acquisition
• Cable Television Laboratories, Inc., 858 Coal Creek Circle, Louisville, CO 80027;
Phone +1-303-661-9100; Fax +1-303-661-9199; http://www.cablelabs.com
• Internet Engineering Task Force (IETF) Secretariat, 48377 Fremont Blvd., Suite 117, Fremont, California
94538, USA, Phone: +1-510-492-4080, Fax: +1-510-492-4001, http://www.ietf.org
• Institute of Electrical and Electronics Engineers (IEEE), +1 800 422 4633 (USA and Canada); http://www.ieee.org
• SCTE, Society of Cable Telecommunications Engineers Inc., 140 Philips Road, Exton, PA 19341
Phone: +1-800-542-5040, Fax: +1-610-363-5898, Internet: http://www.scte.org/
• Small Form Factor Committee (SFF), http://www.sffcommittee.com
10
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
3 TERMS AND DEFINITIONS
3.1 DPoE Network Elements
DPoE Network
DPoE System
DPoE ONU (D-ONU)
This term means all the elements of a DPoE implementation, including at least one
DPoE System, one or more D-ONUs connected to that DPoE System, and possibly one or more DEMARCs
This term refers to the set of subsystems within the hub site that provides the functions necessary to meet DPoE specification requirements.
DPoE Standalone ONU
(S-ONU)
This term means a DPoE-capable ONU that complies with all the DPoE specifications. There are two logical types of D-ONUs. These are the DPoE
Standalone ONU (S-ONU) and the DPoE Bridge ONU (B-ONU). Requirements specified for a D-ONU must be met by all ONUs.
This term means a D-ONU that provides all the functions of a B-ONU and also provides at least one CMCI port. An S-ONU can optionally have one or more eSAFEs.
the encapsulation functions required to be an S-ONU. The B-ONU is a logical definition used by the specification for requirements that apply to all types of B-
ONUs. The two types of B-ONUs are the BP-ONU and the BB-ONU.
DPoE Bridge Pluggable
ONU (BP-ONU)
This term means a D-ONU that is a B-ONU which is pluggable. Pluggable BP-
ONUs include devices such as an SFP-ONU (1G-EPON), SFP+ONU (10G-EPON), or XFP-ONU (10G-EPON).
DPoE Bridge Baseband
ONU (BB-ONU)
This term means a D-ONU that is a B-ONU which has a baseband IEEE Ethernet
interface. BB-ONUs include those with one or more [802.3] baseband PMDs. (See
[DPoE-ARCHv2.0], section 7.2.6.2 for examples.)
DEMARC Short form of "Demarcation Device." This term means the device, owned and operated by the operator that provides the demarcation (sometimes called the UNI interface) to the customer. Some architectures describe this device as the CPE (as in
DOCSIS) or the NID (as in the MEF model).
08/08/13
CableLabs
11
12
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Logical Used for DPoE Specifications
(Normative Requirements)
D-ONU
Logical
+ Product
Used for DPoE Specifications
(Normative Requirements) or for informative text.
Product
May be used for DPoE informative, but not for normative specifications.
Product
Options
Likely products. MUST not be used for DPoE normative
(specifications). Should not be used for DPoE informative.
BP-ONU
B-ONU
BB-ONU
Logical DPoE Elements
D-ONU
B-ONU
BP-ONU
BB-ONU
S-ONU
DPoE ONU
Bridge ONU
Bridge Pluggable ONU
Bridge Baseband ONU
Standalone ONU
Real ONUs
S-ONU
BB-ONU
BP-ONU
SFP-ONU
SFP+ONU
XFP-ONU
Standalone ONU
Bridge Baseband ONU
Bridge Pluggable ONUs
SFP ONU (1G-EPON)
SFP+ ONU (10G-EPON)
XFP-ONU (10G-EPON)
SFP-ONU SFP+ONU XFP-ONU
BB-ONU
+.1ah
Figure 3 - D-ONU Types
S-ONU
S-ONU
+eSAFEs
S-ONU
+.1ah
S-ONU
+eSAFE
+.1ah
EPON
CHIP
R
OLT
DPoE System
DPoE Network
ONU
EPON
CHIP
ONU
BB-ONU
IEEE
802.1
Switch
WiFi eDVA eRouter
X
CE
DEMARC
DEMARC
CE
CE
B-ONU
S-ONU
BP-ONU
CE
DEMARC
DEMARC
CE
CE
EPON
CHIP
ONU
DEMARC
CE
D-ONU
Figure 4 - DPoE Network Elements
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
3.2 Other Terms
1G-EPON
10G-EPON
Cable Modem CPE Interface
Customer Premise Equipment (CPE)
Multi-Layer Switching (MLS)
Ethernet Passive Optical Network
(EPON)
EPON Operations and Maintenance
Messaging (OAM)
Logical CPE Interface
Network Interface Device (NID)
EPON as defined in [802.3ah] and amended in [802.3av]
CMCI as defined in [MULPIv3.0]
Customer Premise Equipment as defined in [DOCSIS]
A switch that can switch based on Layer 2, Layer 3, Layer 4, etc.
Refers to both 1G-EPON and 10G-EPON collectively
EPON OAM messaging as defined in [802.3ah] and this document;
Ethernet OAM is not the same as EPON OAM; Ethernet OAM is
A DEMARC device in DPoE specifications
08/08/13
CableLabs
13
DPoE-SP-OAMv2.0-I03-130808
4 ABBREVIATIONS AND ACRONYMS
eDVA
ENNI
EPL
EPON
EP-VLAN eSAFE
ESP
EVC
E-VPL
EVP-LAN
FEC
GBd
Gbps
HSD
IGMP
INNI
IP
CRC
D-ONU
DHCP
DIA
DoS
DPoE
DR
DSx eCM
ACL
ARP
BCD
CDR
CFI
CMCI
CoS
CPE
This specification uses the following abbreviations:
Access Control List
Address Resolution Protocol
Binary Coded Decimal
Clock and Data Recovery
Canonical Format Indicator (in IEEE 802.1Q tag)
Cable Modem CPE Interface
Class of Service
Customer Premise Equipment
Cyclic Redundancy Check
DPoE ONU
Dynamic Host Configuration Protocol
Dedicated Internet Access
Denial of Service
DOCSIS Provisioning of EPON
Default Router
Digital Signal (DS1 or DS3) embedded Cable Modem embedded Digital Voice Adapter
External Network to Network Interface
Ethernet Private Line
Ethernet Passive Optical Network
Ethernet Private Virtual Local Area Network embedded Service/Application Functional Entity
Ethernet Service Path
Ethernet Virtual Connection
Ethernet Virtual Private Line
Ethernet Virtual Private LAN
Forward error correction
Gigabaud
Gigabits per second (as used in the industry)
High Speed Data
Internet Group Management Protocol
Internal Network to Network Interface
Internet Protocol
14
CableLabs
Cable Data Services
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
IP(HSD)
IPMC
I-SID
LCI
LLID
LSE
LOS
MAC
MPCPDU
MEF
MI
MN
MPCP
MTU
MU
NID
NNI
NVS
OAM
ODN
OLT
ONU
OSC
OUI
PDU
PHY
PON
R
RARP
RTT
S-OAM
SA
SFP
SFP+
TLV
TPID
TU
High Speed Data (Broadband Internet Access using DOCSIS)
IP MultiCast
[802.1ah] I-Component Service IDentifier
Logical CPE Interface
Logical Link IDentifier
Label Stacking Entry
Loss Of Signal
Media Access Control
Multi-Point Control Protocol Data Unit
Metro Ethernet Forum
MEF INNI Interface at a customer premise
MEF INNI Interface to operators MEN
Multi-Point Control Protocol
Maximum Transmission Unit
MEF UNI Interface
Network Interface Device
Network to Network Interface
Non-volatile Storage
EPON Operations Administration and Maintenance
Optical Distribution Network
Optical Line Termination
Optical Network Unit
Optical Splitter Combiner
Organizationally Unique Identifier
Protocol Data Unit
Physical Layer
Passive Optical Network
IP Router
Reverse ARP
Round Trip Time
Ethernet Service OAM
Source Address
Small Form-factor Pluggable
Small Form-factor Pluggable Plus (+)
Type-Length-Value
Tag Protocol Identifier
Interface between DPoE System and D-ONU, roughly "the PON fiber"
08/08/13
CableLabs
15
DPoE-SP-OAMv2.0-I03-130808
UNI vCM
VID
VLAN
WSC
X
XFP
User Network Interface
Virtual Cable Modem
VLAN Identifier
Virtual Local Area Network
Wireless Switching Center
IEEE Ethernet Switch (Generic)
X Form-factor Pluggable
Cable Data Services
16
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
5 BACKGROUND
5.1 IEEE 802 Link OAM for EPON
Traditional network management architecture requires the ONU to support the appropriate network management protocol or protocols. The protocol is usually SNMP, and hence would require IP layer connectivity. This requirement can result in extensive network maintenance to support every ONU on the management network at layer 3. An IP address would be assigned on the service provider's management network to each connected ONU, and ARP/RARP/DHCP issues must be addressed, as well as L3 security over the management channel. L3 management also places a larger burden on the ONU software stack, resulting in greater cost in the high-volume components of the network. The DPoE management architecture terminates network-side management protocols at
Clause 57 OAM packet format in DPoE specifications, the DPoE ONU (D-ONU) does not need to support additional protocol families for every possible management protocol, simplifying implementation and limiting interoperability problems.
to the lower half of the data link layer. This is problematic for managing a full network, as a practical EPON ONU will likely serve as an Ethernet bridge and will have remote ports used to connect a customer LAN to EPON.
Service providers running EPON need to remotely manage the entire ONU, and not just the EPON MAC. This exactly matches the requirements of the DPoE Network.
DPoE Link OAM should not be confused with Ethernet Service OAM (S-OAM). In DPoE specifications, Link
OAM Protocol Data Units (PDUs), as defined in this specification, exist only on the PON. Furthermore, DPoE Link
OAM PDUs are defined only for communication between a DPoE System and D-ONU. S-OAM, on the other hand, typically comprises both Performance Management and Fault Management functionality, and S-OAM PDUs can be forwarded to neighboring Ethernet networks toward a destination on a different network.
define specific extensions. One PDU opcode (0xFE) is reserved for such extensions. Also, organization-specific
Type-Length-Value (TLVs
) encodings can be added to some standard [802.3] Clause 57 PDUs. The organization
defining the extension is identified by an IEEE OUI following the PDU extension opcode or TLV type. The remainder of the PDU format is then defined by the organization identified by the OUI for the frame. This document defines the format used for extensions under the DPoE OUI 0x001000.
extensions, an ONU functioning at L3 as a typical SNMP-managed device would extend the service provider's management network to the customer LAN. This creates potential security problems, especially with the open
management network on the network side of the ONU and insulated from the subscriber interfaces. They also isolate the L3 user data network from the management network at a L2 protocol level, providing increased security over the management channel.
5.2 [802.3] Clause 57 OAM PDUs
header format, with EtherType 0x8809, Subtype 0x03, a Flags field that carries information about OAM state, and an opcode that defines the type of PDU. The body of each PDU depends on the opcode.
2
TLVs are used to encode information in many data communications protocols. TLVs in this document are specific to DPoE
OAM and should not be confused with other uses of TLVs in other DPoE specifications.
08/08/13
CableLabs
17
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Width (Octets)
6
6
2
1
2
1
Varies
4
Field
Ethernet DA (Destination Address)
FCS
Table 3 - IEEE Link OAM Messages Format
Ethernet SA (Source Address)
EtherType
Subtype
Flags
PDU Type
Data/Pad
Value (hex)
0x01:80:C2:00:00:02
([802.3] OAM multicast address)
As per sending MAC
0x8809 (Ethernet Slow Protocol)
As defined for the Opcode.
Pad in OAM frames must be zero per [802.3].
Standard FCS generated by the [802.3] MAC
Table 4 - [802.3] Clause 57 PDU Types
IEEE Info TLV Type
Information
Event Notification
Variable Request
Variable Response
Loopback Control
Reserved
Organization Specific
Reserved
Value (hex)
0x00
0x01
0x02
0x03
0x04
0x05..0xFD
0xFE
0xFF
5.2.1 Info PDU
link is established, in which the OAM peers discover each other's existence and negotiate the maximum OAM frame length. Info PDUs are also periodically transmitted (once per second) as a keep-alive heartbeat for the OAM layer.
"Remote" information TLVs are always present in an Info PDU, and convey basic information about the OAM
to denote the particular organization which defines the contents of that TLV. DPoE OAM defines an Info TLV type.
Width (Octets)
1
1
Varies
Field
TLV Type
Length
Depends on TLV Type
Value (hex)
Includes Type and Length fields, plus data to follow
Depends on TLV Type
18
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
Table 6 - [802.3] Info TLV Types
End of TLV marker
Local Information
Remote Information
Reserved
Organization-Specific
Reserved
Value (hex)
0x00
0x01
0x02
0x03..0xFD
0xFE
0xFF
5.2.2 Event Notification PDU
peer at the other end. Typically this is "alarm" information sent from the D-ONU to the DPoE System. Event notification PDUs are not intended to function as an OSS system but to provide the ability for a D-ONU to give notice of specific events to a DPoE System. The use and distribution of this information is managed and forwarded
four are variations on the theme of reporting link fault counts (where a link fault is any of several errors that can occur in an Ethernet, such as CRC errors or frame length errors). The fifth type is reserved for organization-specific
TLVs. The DPoE specification defines an extended alarm TLV type used in this PDU to convey more detailed alarm information.
Recall that all OAM frames carry three bits in the standard OAM header which indicate "link fault", "critical event",
contains these bits, but also contains TLVs that provide more detailed information about the conditions that are present.
Table 7 - [802.3] Event Notification TLV
Width (Octets)
1
1
Varies
Field
TLV Type
Length
Depends on TLV Type
Value (hex)
Includes Type and Length fields, plus data to follow
Depends on TLV Type
Table 8 - [802.3] Link Event TLV Types
End of TLV Marker
Errored Symbol Period Event
Errored Frame Event
Errored Frame Period Event
Errored Frame Seconds Summary
Reserved
Organization-Specific
Reserved
Value (hex)
0x00
0x01
0x02
0x03
0x04
0x05..0xFD
0xFE
0xFF
08/08/13
CableLabs
19
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
5.2.3 Variable Request/Response PDUs
30, which are typically frame counters and error counters, along with basic control state of the MAC layer, such as link status or auto-negotiation results. The Variable Response PDU contains data in response to these requests. Note that in the standard protocol, all attributes are read-only. That is, the Variable Request message can retrieve values, but cannot set them.
The Variable Request PDU consists of a series of "Variable Descriptors" that identify the particular attribute to be retrieved. A Variable Descriptor is composed of "branch" and "leaf" codes that uniquely identify the attribute, at least within the IEEE-controlled numbering space. The Variable Descriptor is essentially a compound, three-byte attribute type code.
The Variable Response PDU consists of a number of Variable Containers. A Variable Container begins with a
Variable Descriptor, which is followed by a Length field and then data that indicates the value of the attribute. Thus, the Variable Container is a kind of Type-Length-Value (TLV) format, where the Type is a three-byte code, and reserved values in the Length field serve as error codes.
For compatibility with standard PDUs and attribute numbering, DPoE OAM reuses these structures in its Get and
Set PDU types. The contents of these standard PDUs are legal contents for the body of DPoE Get and Get Response
PDUs, although they are a subset of the possible legal responses. In this document, Variable Descriptors and
Variable Containers will often be referred to simply as "TLVs".
DPoE OAM implementations must not generate such requests with the optional "package" format, as opposed to individual attributes. DPoE OAM implementations need not support the package format requests and responses.
5.2.4 Loopback Control PDU
purposes. The Info PDU is also used as a response when establishing or tearing down a loopback, as it carries state information that is useful during the transitions.
5.2.5 Organization-specific PDU
of an Organization-specific PDU are defined by the organization indicated by the OUI in this PDU. DPoE OAM makes use of this feature to add many extended features to the basic IEEE logical link management. This document contains the definition for the format of data in organization-specific PDUs and TLVs marked by the DPoE OUI
0x001000.
In general, an EPON ONU may support many organization-specific OAM message sets. Behavior and requirements of other OAM extension sets are outside the scope of this document.
D-ONUs MAY support OAM extensions in addition to DPoE OAM. DPoE Systems MUST NOT require support for non-DPoE extensions. Similarly, D-ONUs MUST NOT require support for non-DPoE extensions. D-ONUs that support message sets other than DPoE extensions MUST NOT be deregistered simply for that reason. Similarly, D-
ONUs MUST NOT fail to register with a DPoE System that supports DPoE OAM, even if that DPoE System lacks support for some other OAM message set that the D-ONU would like to use.
A DPoE System MUST NOT allow ONUs that do not support DPoE OAM to register as D-ONUs.
20
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
5.3 D-ONU Model
For management purposes, a D-ONU is considered to have the logical structure depicted below.
D-ONU M0
LLID L0
LLID L1
LLID L2
...
EPON Port 0
Link 0
MAC M0 (M0 + 0)
Link 1
MAC M1 (M0 + 1)
Link 2
MAC M2 (M0 + 2)
...
Link 0 Queue 0
Link 0 Queue 1
...
Link 0 Queue N
Link 1 Queue 0
Link 1 Queue 1
...
Link 1 Queue N
Link 2 Queue 0
Link 2 Queue 1
...
Link 2 Queue N
Port 1 Queue 0
Port 1 Queue 1
...
Port 1 Queue N
Port N Queue 0
Port N Queue 1
...
Port N Queue N
UNI 1
...
UNI N
Figure 5 - D-ONU Model
A D-ONU is a device that has one or more MAC interfaces per TU interface (logical links, or just links for short), and one or more MAC interfaces on the user side (DPoE S interfaces or reference points). A switch connects the ports to transfer frames between individual MACs.
The TU interface is a single physical port shared by several MACs, each with an associated Logical Link, whereas the S interfaces (or reference points) usually have one MAC per physical port. Each of these MACs is fed by one or more priority queues. These ports, links, and queues each have OAM attributes that allow remote management.
In addition to the bidirectional (transmit/receive) links shown, D-ONUs support one or more receive-only links.
bridging or true Ethernet multicast.
5.4 Frame Processing
which the relative priority of a frame is determined, usually by inspecting fields within the frame, filtering frames
(discarding frames with undesirable characteristics), access control (forwarding frames with desirable characteristics), or frame modification, such as adding, removing, or modifying Ethernet tags (including, for example, Tag Protocol Identifiers (TPIDs), VLAN identifiers, priority values) in a frame.
For the purpose of describing this behavior, the DPoE OAM specification (this document) adopts an abstract model of D-ONU behavior. The DPoE OAM messages define frame processing in terms of rules that match fields in a frame, and if the fields match the given values, apply a particular result to the frame. The rule results can forward or discard a frame, set a destination queue, or change the frame by adding or deleting fields. D-ONU software parses these rules and programs the D-ONU implementation-specific hardware to achieve the specified effect.
08/08/13
CableLabs
21
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Using these rules as primitives, it is possible to construct many features. For example, an Access Control List (ACL) is a list of rules that matches MAC or IP source addresses and forward-matching frames. Traffic classification is a matter of matching frames and forwarding the frame into an appropriate priority queue based on the frame contents.
Adding an Ethernet tag might be unconditional, as in the case of a VLAN tag for a port, or the tag value might be based on other attributes of the frame to tag frames according to protocol type. Rather than specify distinct OAM messages for all these features, a primitive-oriented approach is used to permit construction of additional features in the future with no additional DPoE OAM message definitions required.
It is not expected that D-ONU hardware processes these rules in software or exactly in the format presented. To be compliant with this specification, any hardware or software implementation may be used, but the DPoE System
MUST implement the DPoE eOAM rule set defined in this specification. Similarly, D-ONU MUST also implement the DPoE eOAM rule set defined in this specification. .
Conceptually, these packet processing rules are applied to frames as they enter ports, whether the TU interface port in the downstream or a User Network Interface (UNI) port in the upstream. For consistency, the field values as used in the rule conditions are always the values in the frame as it enters the port. Any changes to the frame from rule results are considered not to take effect until frame processing has been completed. Thus, the effect of a rule set does not depend on the order of the rules in that set.
All the rules in a port ingress rule table are applied to each frame that enters the port. The results of all rules that match are applied to the frame.
To resolve ambiguity when more than one rule or contradictory rules match the same frame, each rule is associated with a precedence value. The result is that only the highest precedence rule that matches a frame and has a particular result will be applied. Thus, for example, by using two precedence levels, it is possible to establish a single rule that provides a classification for a frame and then override that classification by matching specific control fields with a higher precedence rule (as with DOCSIS classifiers that select traffic into Secondary Service Flows). The precedence of one type of rule result (say, modifying an output field) does not conflict with the precedence of other types of result (say, forwarding the frame, or setting an output queue).
3
Revised per OAMv2.0-N-13.0077-1 on 6/17/13 by JB.
22
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
6 OAM OPERATION
6.1 OAM Discovery
OAM is mandatory for all D-ONUs conforming to this standard. A D-ONU that does not actually complete OAM
Discovery in a stable state, as per this standard, MUST be deregistered by the DPoE System after 5 seconds of attempting OAM discovery, measured from the initial OAM Info PDU sent by the OLT.
During OAM discovery, support for DPoE extensions is declared by adding an Info TLV to the Info PDUs
declaration of willingness to adhere to the requirements of the DPoE OAM extension set, including the rules on critical OAM and D-ONU behavior in this section. Lack of this TLV means that the ONU is not capable of supporting DPoE extensions, and subsequently will not be allowed to register as a D-ONU.
A D-ONU MUST include the DPoE OAM Support Info TLV in all OAM Info frames exchanged during the OAM
Discovery phase. The D-ONU SHOULD NOT insert this TLV into keep-alive Info frames after OAM Discovery has completed.
6.2 OAM Timeout
To relieve the protocol of complexity in handling out-of-order requests and overall pacing for different D-ONUs, a
DPoE System may have only one outstanding OAM request per logical link at any given time. The D-ONU must reply, or the OAM timer expire, before the DPoE System can send another OAM PDU to the D-ONU.
Unless otherwise specified, a D-ONU MUST respond to an OAM request from a DPoE System within one second.
If a D-ONU cannot respond before the OAM timeout, it MUST raise the D-ONU busy alarm. Failure to respond to
OAM results in an error at the DPoE System; handling of this error is implementation-specific, but MUST NOT include deregistering the D-ONU. The exception to this rule is "critical" OAM. Failure to respond to critical OAM is a reason to deregister a D-ONU.
6.3 Critical OAM
Of the hundreds of messages and attributes in the DPoE OAM extension set, a few are deemed "critical" OAM. A successful response to these OAM messages is necessary for the network to work properly. An ONU that does not acknowledge these critical OAM commands is not operating correctly (by definition) and will be deregistered by the
DPoE System. These critical OAM commands are required as part of the claim of support for DPoE extensions. An
ONU that claims support for DPoE extensions is also promising to respond to these OAM commands in particular, as well as others in this document.
Critical OAM messages are sent immediately after link registration, and may also occur at other times during the D-
ONU operation.
Table 9 - Critical OAM Attributes
Attribute Description
ONUID
Set OAM Rate
Unique physical ONU identification number
Max Number Of Logical Links Maximum number of logical links (bidirectional LLIDs) supported on the ONU
ONU Report Thresholds Controls format of MPCP REPORT PDU
Changes maximum allowed OAM PDU rate
The critical OAM messages are described in detail below.
Value (hex)
0xD7/0x0002
0xD7/0x0007
0xD7/0x000B
0xD7/0x000D
08/08/13
CableLabs
23
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
6.3.1 D-ONU Capabilities
Most of the information in the Extended Info PDU is primarily of interest to the network management system.
However, a few of these attributes are snooped by DPoE System firmware, and are necessary for the DPoE System to manage D-ONUs.
The D-ONU base MAC address is considered to be the ONU ID that ties multiple logical links on the same D-ONU physical device. Similarly, the number of links is necessary for a DPoE System to correctly manage D-ONUs of different configurations.
If a D-ONU does not positively acknowledge these attributes, it cannot be tracked and managed by the DPoE
System, and so is deregistered to deny its entry into the DPoE Network.
6.3.2 Set D-ONU Report Threshold
The report threshold limits the size of the frame boundary that is reported to the DPoE System. A DPoE System scheduler generally has some maximum size it is willing to grant (the DBA token size) in order to maintain service guarantees on the PON. If the D-ONU report threshold exceeds this maximum size, then the D-ONU will report a frame boundary larger than the DPoE System can grant. In the best case, EPON efficiency is lost due to loss of frame alignment with the D-ONU, as the DPoE System limits the grant to the maximum size. The next worst effect is that SLAs cannot be correctly enforced, if the DPoE System attempts to grant to the reported frame boundary despite the fact that it is too large given the current demands on the network.
When increasing bandwidth limits, the DPoE System must first increase the OLT token size, and only then increase the D-ONU threshold. Conversely, to decrease the bandwidth limits, the D-ONU report threshold must be lowered before the OLT token size can be decreased. A positive acknowledgement from the D-ONU is necessary to be sure this report threshold has been adjusted before the OLT can be updated. If a D-ONU does not respond to this command, the OLT cannot be certain of the report threshold at the D-ONU. Rather than risk correct network behavior for all other ONUs registered on the PON, the D-ONU that fails to acknowledge this command is deregistered.
6.3.3 Set OAM Rate
extensions allow this limit to be increased or waived entirely. However, both the DPoE System and D-ONU must agree on the actual OAM frame rate to be used. If the D-ONU and DPoE System use different OAM frame rates, the useful PDU rate would be limited by the lower of the two, as the ONU would either fail to acknowledge OAM commands (when the DPoE System rate was higher than the D-ONU) or be unable to use the increased limit (as the
DPoE System would not send commands as often as the D-ONU might be willing to accept).
6.4 OAM Keep-alive Failure
heartbeat failure, but says nothing specifically about the Multi-Point Control Protocol (MPCP) layer in this case. It is conceivable that the OAM layer fails because of some fault in the underlying Ethernet layer controlled by MPCP. If this layer cannot transport frames, it cannot transport OAM frames, and thus resetting only the OAM layer is not likely to recover the D-ONU if the problem lies with MPCP or the Ethernet layer.
DPoE Systems MUST deregister D-ONUs at the MPCP layer if an OAM layer failure is detected. D-ONUs MUST deregister and re-register at the MPCP layer if an OAM layer failure is detected.
6.5 OAM and Logical Links
The DPoE System MAY use any logical link that terminates at the appropriate D-ONU to send OAM commands.
The D-ONU MUST respond to commands on the same logical link on which the command was received.
24
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
7 [802.3] OAM PDU
TLVs, which allow for extensions. The Info OAM PDU and the Event Notification OAM PDU are each composed of a series of TLVs. Each type of PDU allows an organization-specific TLV with contents as defined by that organization.
OAM extension TLVs use TLV type of 0xFE and the DPoE OUI 0x001000.
7.1 Info PDU
All DPoE Info TLVs have as their first type an additional TLV type that allows for multiple different types of DPoE
Info TLVs. Format of additional data in the TLV depends on this DPoE TLV type.
Table 10 - DPoE Info TLV Format
1
1
3
1
Width (Octets) Field
TLV Type
Length
OUI
DPoE Info TLV Type
Value (hex)
0xFE (Info TLV extension)
Includes Type and Length fields, plus data to follow
0x001000
The DPoE Info TLV types are shown in Table 11.
Table 11 - DPoE Info TLV Types
DPoE TLV Type
DPoE OAM Support 0x00
Value (hex)
7.1.1 Info TLV: DPoE OAM Support (0x00)
Presence of this TLV in the Info frames during OAM discovery indicates the DPoE System or D-ONU supports
DPoE OAM. Support for the OAM PDUs also implies support for the feature set required for the DPoE System.
The ‘DPoE OAM Version’ field indicates the version of the eOAM supported by the given device. This field represents a major/minor version number, with the major number in bits [7:4] and the minor number in bits [3:0].
For example, the value of 0b00100000 (0x20) stored in the ‘DPoE OAM Version’ field represents a major version 2, minor version 0 of the DPoE OAM.
The DPoE System MUST deregister a D-ONU which reports an unsupported version of DPoE OAM.
08/08/13
CableLabs
25
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
1
1
3
1
Width (Octets)
1
Table 12 - DPoE OAM Support TLV Format
Field
TLV Type
Length
OUI
DPoE Info TLV Type
DPoE OAM Version
Value (hex)
0xFE (Info TLV extension) varies
0x001000
0x00
Bits [7:4] represent the major version number
Bits [3:0] represent the minor version number
The following values are defined:
0x01 – reserved for backward compatibility reasons, same as
0x10
0x02 – pre-DPoE OAM, without Certificate Authority support
0x03 – pre-DPoE OAM, with Certificate Authority support
0x10 – OAM compliant with DPoE-SP-OAMv1.0-I04 and previous versions
0x11 – OAM compliant with DPoE-SP-OAMv1.0-I05 and subsequent versions of DPoE-SP-OAMv1.0
0x20 – OAM compliant with DPoE-SP-OAMv2.0-I01 and subsequent versions
Other values are reserved and treated as unsupported.
7.2 Event Notification PDU
All DPoE alarms have a common format. The current condition of the alarm is indicated as "raised" when the condition is detected, and "clear" when the condition is no longer present. The object affected by the condition is included as object type and instance number, which matches the DPoE object context leaf codes and instance
Table 13 - DPoE Link Event TLV Format
Width (Octets)
1
1
3
1
1
2
2 or 4
Field
TLV Type
Length
OUI
Event Code
Raised
Object Type
Object Instance
Value (hex)
0xFE (Event Notification TLV extension) varies
0x001000
Boolean; TRUE if the condition currently exists;
FALSE if it has been cleared
Affected object (leaf code for object context, branch D6)
Affected instance of this type of object. Queue object type requires four (4) bytes, other object types require two (2) bytes.
Events, and Dying Gasp alarm types, with code values numbered accordingly.
4
Revised per OAMv2.0-N-12.0056-1on 3/12/13 by JB.
5
Revised text and tables per OAMv2.0-N-12.0059-2 on 3/13/13 by JB.
26
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
In addition to this standard header, individual alarm types may contain further alarm-type-specific information in the
TLV.
Table 14 - DPoE Event Codes
DPoE Event
Code
Value
(hex)
Description Relevant Object
Context(s)
Link Fault Alarms
LOS 0x11 Loss of received optical power by the transceiver (ONU EPON port)
Link down on Ethernet PHY (ONU UNI port)
D-ONU
Network PON Port
User Port
Logical Link (LLID)
Key Exchange
Failure
Reserved
Critical Event Alarms
Port Disabled
0x12
0x13..0x1F Reserved
0x21
D-ONU did not observe a switch to a new key after key exchange
Ethernet port is disabled by management action Network PON Port
User Port
Reserved
Dying Gasp Alarms
Power Failure
Reserved
Other Alarms
0x41 Loss of power at the D-ONU (Dying Gasp)
0x42..0x7F Reserved
Statistics Alarm
D-ONU Busy
MAC Table
Overflow
Reserved
0x22..0x3F Reserved
D-ONU
0x81 Statistic has crossed defined alarm thresholds Network PON Port
Logical Link (LLID)
User Port
Queue
D-ONU 0x82
0x83
D-ONU is busy and unable to acknowledge or process further
OAM until alarm clears
D-ONU MAC Table has seen more addresses than it can hold D-ONU
Network PON Port
User Port
0x84..0xFF Reserved
7.2.1 LOS (0x11)
For the TU interface port, a Loss Of Signal (LOS) condition is detected by lack of incoming optical power or loss of
Clock and Data Recovery (CDR) lock to the downstream bit clock. On an S interface (or reference point), the LOS condition corresponds to the Link Down condition detected by the S interface (or reference point) PHY.
7.2.2 Key Exchange Failure (0x12)
The Key Exchange Failure alarm indicates that a scheduled key exchange has failed to successfully complete.
Encryption continues with the previous key for another key exchange interval. Another key exchange will be
of failure conditions.
7.2.3 Port Disable (0x21)
The Port Disabled event indicates that a D-ONU port has been disabled by management action. If the TU interface port is disabled, then OAM cannot be transmitted, and this alarm will be visible only locally on the D-ONU.
08/08/13
CableLabs
27
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
7.2.4 Power Failure (0x41)
A Power Failure alarm indicates that the D-ONU has lost power and will imminently depart the DPoE Network. A
D-ONU will exercise its best effort to send an Event Notification PDU with this TLV when it detects loss of power.
A D-ONU might not be able to actually send the message if the required transmission grants are not allocated by the
DPoE System before the D-ONU has exhausted its endurance.
7.2.5 Statistics Alarm (0x81)
The Statistics Alarm indicates a crossing of predefined thresholds on some statistic (indicated in the alarm TLV).
Typically, these thresholds would be set for counters for error conditions such as CRC errors. The Statistics Alarm
TLV carries the following fields after the standard DPoE alarm TLV fields.
Table 15 - Statistics Alarms Additional Fields
1
2
Width (Octets) Field
Branch
Leaf
Value (hex)
Branch of statistic that crossed threshold
Leaf of statistic that crossed threshold
7.2.6 D-ONU Busy (0x82)
The D-ONU Busy alarm may be raised by a D-ONU to inform the DPoE System that it has become busy for an extended period and may not respond to further OAM requests in the usual timely fashion.
The DPoE System MUST ignore any OAM or eOAM timeout alarms as long as the "ONU Busy" alarm is active
(raised), but not longer than 300 seconds from the last reception of the "ONU Busy" alarm. The DPoE System
MUST NOT ignore any OAM or eOAM timeout alarms longer than 300 seconds from the last reception of the
"ONU Busy" alarm.
7.2.7 MAC Table Overflow (0x83)
The MAC Table Overflow alarm is raised by a D-ONU to inform the DPoE System that an ingress MAC address has not been learned because the total number of MAC addresses has been exceeded. For example, if the D-ONU has been provisioned to allow four MAC addresses on a particular UNI port, then the first four addresses seen would be learned; the fifth address would cause this alarm to be raised.
28
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
8 DPOE OAM PDUS
DPoE OUI 0x001000. See Section 5.2 for more details on [802.3] Clause 57 OAM PDU formats.
Table 16 - DPoE Extended OAM PDU Format
6
Width (Octets)
2
1
3
1
6
2
1
Field
Ethernet DA
Ethernet SA
EtherType
Subtype
Flags
Opcode
OUI
DPoE Opcode
Value (hex)
0x0180C2-000002
([802.3] OAM multicast address)
As per sending MAC
0x8809 (Ethernet Slow Protocol)
FE
0x001000
Each DPoE OAM message type is identified by a one-byte opcode immediately following the DPoE OUI. Data per
Table 17 - DPoE Opcodes
DPoE Opcode
Reserved
Get Request
Get Response
Set Request
Set Response
IP Multicast Control
Multicast Register
Multicast Register Response
Key Exchange
File Transfer
IP Multicast Ctrl Response
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
0x08
0x09
0x0A
Value (hex)
Most management functions in DPoE Systems are carried out by reading and writing individual attributes of objects in the D-ONU with the Get and Set PDUs. Setting an S interface port speed, for example, would be performed by setting the port speed attribute of the proper port object. These PDUs are essentially lists of TLVs, where each TLV represents an attribute. Since more than one instance of an object could exist in the D-ONU, the packet also contains
TLVs that identify the object to which later attributes in the PDU will apply. That is, some TLVs set the current object context to which later attributes apply. Since the PDU is a list format, it is possible to conduct a number of
Descriptors and Variable Containers as found in the Get and Set PDUs.
Other OAM PDU types exist for specialized purposes that do not fit the object as well, such as file transfer.
08/08/13
CableLabs
29
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
8.1 Get Request
Request messages.
8.2 Get Response
This Get Response OAM PDU is a response to a Get Request. The data field of the PDU contains a null-terminated
Containers are the value of the queried attributes, or possibly an error response code.
8.3 Set Request
Variable Request message. The DPoE OAM supports the setting of variables.
The format of the Set OAM PDU is similar to the Variable Response PDU. A null-terminated list of Variable
Containers specifies which variables to set. The values in the Variable Containers provide new values to be set for the attribute.
The Set Request OAM PDU may contain Actions (branch 0x09 or 0xD9) as well as attributes. Actions instruct the receiving device to execute a procedure, such as clearing a table or resetting. The management actions specified in
management actions and extended actions to be requested. Actions that have parameters (as defined for each action) have those parameters as the body of the Variable Container for the action. Actions that do not have parameters are represented as a Variable Container of zero length (length code 0x80).
Actions are distinct from setting variables, though they can have similar affects. An SNMP MIB contains "trigger attributes" that create the same effect as an action. For example, in SNMP, setting a Boolean "Reset" attribute to
30 can be used to change system settings. For example, setting the AdminState of a PHY can turn the device on or off.
8.4 Set Response
A Set Response OAM PDU contains a null-terminated series of Variable Containers. The response codes correspond to individual Set requests or Actions in the Set Request PDU. The container typically consists of the Branch/Leaf identifier and the Width field. The Width field contains an error code.
8.5 IP Multicast Control
The IP Multicast Control OAM PDU is used by the DPoE System to control forwarding of IP multicast groups on a
D-ONU. Multicast control protocols (like IGMP) are processed by the DPoE System; the D-ONU starts and stops forwarding multicast frames to its UNI ports only by command from the DPoE System.
8.6 Multicast LLID Registration
The Multicast Registration OAM PDU assigns a multicast LLID to a D-ONU. The PDU associates a multicast LLID with a unicast LLID assigned by the standard MPCP registration process for purposes of management and forwarding traffic other than IP MultiCast (IPMC). The default multicast LLID for a unicast link on 1G-EPON is
30
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
8.7 Multicast LLID Response
The Multicast Response OAM PDU is returned by the D-ONU to acknowledge receipt of the Multicast Registration
PDU.
8.8 Key Exchange
The Key Exchange PDU is used by encryption firmware to exchange keys and synchronize key switchover. See
[DPoE-SECv2.0] for details on the key exchange protocols used by the DPoE Network.
8.9 File Transfer
details on file transfer PDUs and protocol specifications.
8.10 Attribute List
The DPoE OAM Get Request and Set Request PDUs and corresponding Get Response and Set Response OAM
contents of the standard Variable Request and Variable Response PDUs.
A Variable Descriptor is a 3-byte value composed of a one-byte "branch" code and a two-byte "leaf" code, which uniquely identifies a particular attribute.
Table 18 - Variable Descriptor
1
Width (Octets) Field
Branch Code
2 Leaf Code
Value (hex)
0x0: (end of list)
0x01 … 0xFF
0x00 00..0xFF FF
Variable Containers consist of a branch/leaf pair, followed by a one-byte field that represents the length of data in the container, followed by the actual data that is the value for that attribute. Thus, a Variable Container has a typical
Type-Length-Value (TLV) structure, with a compound Type field. A Variable Descriptor is just the Type portion of this TLV.
Table 19 - Variable Container
1
2
1
Width (Octets)
varies
Field Value (hex)
Branch Code
Leaf Code
Length
Value
0x00: length of data to follow is 128 bytes
0x01..7F: length of data to follow in bytes
0x80..FF: Response/error code (implies zero length of data follows)
Present only when length is greater than zero; format as defined for the branch/leaf code
For brevity, the acronym "TLV" is used to refer to either Variable Descriptors or Variable Containers, even though
Variable Descriptors do not actually have a length or value field.
The series of TLVs in a PDU is terminated by a Variable Container or Variable Descriptor with branch, leaf, and length values of 0.
08/08/13
CableLabs
31
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
length of data in the container. Zero represents a length of 128 bytes. Values 128 (0x80) and higher represent a response code to the request, indicating the result of the attempted action. All response codes imply a length of zero for the data length.
Table 20 - DPoE Variable Response Codes
DPoE Variable
Response Codes
No Error
Meaning Value (hex)
Too Long
Bad Parameters
No Resources
System Busy
Undetermined Error
Unsupported
May Be Corrupted
Hardware Failure
Overflow
The operation was successfully completed. This value is also used to represent zero length in Variable Containers with no data, such as in the Set PDU for actions with no parameters.
Length of result exceeded OAM PDU data field available
0x80
0x81
Parameters for the requested action fail error checking 0x86
The device does not currently have the resources (table entries, memory, etc.) to perform the requested action
0x87
The device is not currently in the proper state to perform the requested action
Unknown or unlisted Attribute error
The Attribute requested is not supported on this device
The value of an Attribute counter may be invalid due to reset
An Attribute hardware error prevented the operation from completing
Requested Attribute experienced overflow error
0x88
0xA0
0xA1
0xA2
0xA3
0xA4
8.11 Data Formats
Variable Containers contain data of several common types. This section describes the format of these data types.
8.11.1 Integers
Integers are represented in two's-complement form, most significant byte first. Note that Containers are variable length; as a result, attributes that are integers do not have a fixed width. The transmitter may suppress leading zero bytes of integers. The receiving D-ONU or DPoE System must handle an integer in a Variable Container of any legal width (1..128 bytes).
If a Variable Container is smaller than the receiving device representation, the value is extended as necessary. If the Variable Container is larger than the receiving device representation, the result is implementation-defined.
8.11.2 Enumerated Values
Enumerated values take one of a number of bit patterns with predefined meanings. Enumerated values are always represented in a Container with a width equal to that necessary for the largest possible such value in that particular enumerated value, with leading zeros as necessary when the actual value is shorter than the maximum possible.
8.11.3 Sequences
A "sequence" is a series of values, usually enumerated values. Every element in a sequence must have the same width. The number of elements in the sequence can thus be determined from the width of the Variable Container.
8.11.4 Structured Data Types
Many attributes consist of structured data with a number of sub-fields. The format of such structured data depends on the attribute, and is shown in a table in the definition of individual attributes below.
32
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
8.12 Storage Classes
OAM attribute description provides a “storage class” for each attribute, which defines the behavior of the attribute in memory.
The lack of any notation at the OAM attribute indicates that the attribute is Read-Write (RW). The vCM may write into this attribute with a Set PDU and read from this attribute with a Get PDU.
“R” denotes a Read-Only attribute. The vCM may read from this attribute with a Get PDU, but cannot Set the value stored in this attribute.
“NVS” denotes an attribute kept in Non-Volatile Storage. NVS attributes, unlike normal attributes, retain their values when an ONU resets, including power-on resets. An NVS attribute retains its value after a reset as last set with a Set PDU. Non-NVS attributes return to a default value as listed in the spec after a reset.
8.13 Large Values
The maximum length of data that can fit into a single Variable Container is 128 bytes. Some attribute values may be larger. Values larger than 128 bytes long are represented by a contiguous series of Variable Containers with a repeated branch/leaf code for the attribute in question. This series of TLVs is terminated by a TLV with the same branch/leaf code, and a length of zero, to indicate the end of the large value.
The attribute value is segmented into the several TLVs as described for particular attributes. For ease of segmentation and reassembly, the value for tables of items is not necessarily broken at 128 byte boundaries, but rather the closest boundary that contains an integral number of table items. For example, a MAC address table consisting of a large number of entries, each 6 bytes long, can hold at most 21 whole MAC addresses in whole TLV
(21 x 6 = 126 bytes). Rather than break the 22nd MAC address across two TLVs, the first TLV would contain 126 bytes and the next the remainder of the value.
Example
A Get PDU contains a single Var Container to request the MAC address table from a D-ONU:D7 01 03.
Assume further that the polled D-ONU currently has 23 learned MAC addresses, and returns the response using three Variable Containers in the PDU, 21 addresses in the first TLV and 2 in the second, followed by the large value terminator:
0xD7 01 03 7E 11 12 13 14 15 16. .
0xD7 01 03 0C 21 22 23 24 25 26 31 32 33 34 35 36
0xD7 01 03 80
8.14 Multiple Part OAM Responses
Certain responses from the D-ONU to a single PDU from the DPoE System may not fit within a single OAM frame.
(Variable Containers are larger than Variable Descriptors, and some values can be much larger than a single frame.
Such attributes include D-ONU rule tables and learning tables.) In this case, the D-ONU must split its response across multiple OAM PDUs. The D-ONU MUST then inform the DPoE System that the complete response was not sent in one frame. In addition, the DPoE System MUST be able to detect missing OAM PDUs from a series needed to form the complete response.
To indicate that further response messages are forthcoming, the D-ONU adds a particular TLV known as a Sequence
Number TLV to its response PDU.
A D-ONU SHOULD NOT insert a Sequence Number TLV into a single part response frames.
6
Revised per OAMv2.0-N-12.0056-1on 3/12/13 by JB.
7
Revised per OAMv2.0-N-12.0056-1on 3/12/13 by JB.
08/08/13
CableLabs
33
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
The Sequence Number TLV has the following format:
Table 21 - Sequence Number TLV
Field
Branch
Leaf
Length
Sequence #
Description
Branch Attribute
Multi-Part Response Sequence Number
One 16-bit unsigned integer
Bit 15, when set, indicates that this is the last message of its sequence.
Bits 0-14 are a 15 bit sequence number.
To send a multiple part response requiring N PDUs, the D-ONU does the following:
For the first PDU in the sequence:
Set Sequence# = 0
For the last PDU of the sequence:
Set bit 15 of Sequence#
For all PDUs in the sequence:
Add a sequence TLV with the value {0xD7, 0x0001, Sequence#}
Send the OAM PDU
Increment Sequence#
Value (hex)
0xD7
0x00 01
0x02
(variable)
Figure 6 presents a sample message exchange:
Single part message
OLT Request
ONU Response
OLT Request
ONU Response
Sequence
#
= 0x8000
Single part message with optional TLV (inefficient)
Two part message
OLT Request
Sequence
Sequence
Figure 6 - Sample Message Exchange
N part message
OLT Request
ONU Response
Sequence
#
= 0x0000
Sequence
...
ONU Response
Sequence
#
+ N-2
ONU Response
Sequence
#
+ N-1
34
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
8.15 Object Context (Branch 0xD6)
DPoE OAM extensions can manage objects other than the immediate EPON MAC instance. Also, since a D-ONU typically supports multiple ports, any attribute such as "Bytes Received" may have many instances, one for each port on the D-ONU. Therefore, the particular instance of an object must be identified to provide context for the attributes or actions.
An object context tuple in an OAM PDU sets the object to which all subsequent Variable Descriptors or Containers apply. This remains unchanged until the next object context in the PDU is processed, or the message ends. If no object context is supplied, the default context is the logical link (LLID) on which the OAM PDU was received.
A DPoE ONU is assumed to have 1 or more Ethernet interfaces in addition to the TU interface. TU Interfaces and
Ethernet interfaces are identified by an 8-bit ID number that ranges from 0..N-1, using two separate numbering spaces for TU interfaces and Ethernet interfaces. The relationship of interface numbers to actual physical interfaces is defined by the DPoE ONU, but the relationship is always the same for any given DPoE ONU.
It is not necessary for the DPoE System to know the MAC addresses of the user ports to manage them via DPoE
OAM.
Table 22 - Object Context
Leaf (HEX)
0x00 00
0x00 01
0x00 02
0x00 03
0x00 04
Attribute
D-ONU Object
Network PON Port
Logical Link Object
User Port Object
Queue Object
Description
D-ONU
A PON port on the network side of the device
OAM logical link context
User-side Ethernet port
A single queue
8.15.1 D-ONU Object (0xD6/0x0000)
The D-ONU object identifies the D-ONU as a whole. In most cases, this object is obvious because the D-ONU is the one processing the DPoE OAM message. In some cases, a DPoE OAM PDU may want to make the current context less specific for a particular attribute. The D-ONU Object is also necessary for some other uses, such as in an alarm
TLV.
The instance number for the D-ONU object is always 0.
Table 23 - D-ONU Object
Width (Octets)
1
Field
D-ONU instance
Value (hex)
0
8.15.2 Network Port Object (0xD6/0x0001)
The Network Port object identifies one of the network-side PON ports (TU interface) on the device. Network Ports are numbered sequentially starting from 0. This object cannot identify S
1
interfaces.
Table 24 - Network Port Object
1
Width (Octets) Field
PON Number
Value (hex)
0..N-1
8
Revised per OAMv2.0-N-12.0059-2 on 3/13/13 by JB.
08/08/13
CableLabs
35
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
8.15.3 LLID Object (0xD6/0x0002)
The link object identifies one of the logical links supported by the D-ONU, numbered starting from 0 up to L-1, where L is the number of logical links supported by the D-ONU. The default link is the link on which the OAM
PDU was received.
Table 25 - Link Object
1
Width (Octets) Field
LLID Index
Value (hex)
0..L-1
8.15.4 User Port Object (0xD6/0x0003)
The User Port object identifies one of the S interfaces or references points on the device (if any). S
1
interfaces are numbered sequentially starting from 0.
Table 26 - User Port Object
1
Width (Octets) Field
UNI Number
Value (hex)
0..N-1
8.15.5 Queue Object (0xD6/0x0004)
Queues are numbered relative to their egress port. Queue numbers start with the value 0, which is the highest priority queue, up to the value N-1, where N is the number of queues that terminate on a port. The value 0xFFFF is a special value that means "all queues for this port". This context is primarily useful for bulk statistics queries from all queues at once, as it saves setting a queue context for each queue.
Table 27 - Queue Object
2
1
1
Width (Octets) Field Value (hex)
Object Type
See Section 8.15. (Only User Ports and LLID have queues.)
Object Instance 0..N-1
Queue Number 0..Q-1
36
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
9 OAM ATTRIBUTES BY FUNCTION
This section further details each DPoE OAM attribute. Each attribute name is listed by its Branch/Leaf designation.
For example, "Get Firmware Version (D7/80)," where the first number (D7) is the branch and the second number
(80) is the leaf. These branch/leaf values are in hexadecimal. Where applicable, units for measurement and allowed ranges are specified.
Some attributes, particularly capabilities, are read-only. These attributes are denoted by an "R" after their value.
Some writeable attributes are non-volatile, which is to say they persist after the D-ONU has been reset. These attributes are marked with an "NV".
9.1 D-ONU Management
9.1.1 D-ONU ID (0xD7/0x0002) R
Objects: D-ONU
The ONU ID is a non-volatile number that uniquely identifies a physical D-ONU. By definition, the D-ONU ID is the lowest (numerically smallest) MAC address among all MAC addresses associated with the TU interface port of a
D-ONU. All logical links on a D-ONU report the same D-ONU ID, despite having different link MAC addresses
9.1.2 Firmware Info (0xD7/0x0003) R
Objects: D-ONU
This attribute represents the D-ONU firmware version. The version number uniquely identifies a particular version of the D-ONU firmware. Format is defined by the D-ONU vendor. DPoE Systems can compare this value for equality with a provisioned value for the currently correct firmware version. "Newer than" or "compatible with" comparisons depend on version number format and should not be performed with a simple comparison. The Boot
Version can be used to populate the BOOTR field in the sysDescr MIB object. The Application Version can be used
0xFFFF are reserved, and indicate loads that are not installed or are not available.
Table 28 - Firmware Info
Size
2
4
2
4
Name
Boot Version
Boot CRC-32
Firmware Version
Firmware CRC-32
Description
Version of bootstrap loader (if any)
CRC-32 of boot loader serves as additional unique identifier and verification
Version of main firmware running on the D-ONU
CRC-32 of firmware serves as unique ID and verification
9
Revised per OAMv2.0-N-12.0056-1on 3/12/13 by JB.
10
Revised per OAMv2.0-N-13.0066-2 on 3/13/13 by JB.
08/08/13
CableLabs
37
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
9.1.3 EPON Chip Info (0xD7/0x0004) R
Objects: D-ONU
This attribute represents the type of EPON chip used on the D-ONU.
Table 29 - EPON Chip Info
2
4
4
Size Name Description
JEDEC ID
Chip Model
16-bit chip manufacturer ID code as assigned by JEDEC
Identifies the particular kind of EPN chip. Format defined by chipset vendor
Chip Version Identifies the version or stepping of the chip model. Format defined by chipset vendor
9.1.4 Date of Manufacture (0xD7/0x0005) R
Objects: D-ONU
The date the D-ONU was manufactured, encoded in Binary Coded Decimal (BCD) digits as YYYYMMDD. For example, June 24, 2010, would be represented as 20 10 06 24.
Table 30 - Date of Manufacture
Size
2
1
1
Year
Month
Day
Name Description
BCD
BCD
BCD
9.1.5 Manufacturer Info (0xD7/0x0006) R
Objects: D-ONU
This attribute holds manufacturer-specific information that identifies this individual D-ONU. This attribute typically contains a serial number, and possibly other manufacturing information, such as lot numbers or component revisions. Format is defined by the D-ONU vendor.
9.1.6 Max Logical Links (0xD7/0x0007) R
Objects: D-ONU
The maximum number of logical links the D-ONU supports on the EPON.
Table 31 - Max Logical Links
Size
2
2
Name
Bidirectional
Downstream-only
Description
Maximum number of links which can both transmit and receive
In addition to the bidirectional links, the maximum number of LLIDs which can receive data, but not transmit (unidirectional, downstream only)
9.1.7 Number of Network Ports (0xD7/0x0008) R
Objects: D-ONU
This attribute provides the total number of TU interface ports on the D-ONU.
38
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
9.1.8 Number of S
1
interfaces (0xD7/0x0009) R
Objects: D-ONU
This attribute provides the number of S
1
interfaces on the D-ONU.
9.1.9 D-ONU Packet Buffer (0xD7/0x000A) R
Objects: D-ONU
This message provides a means for the D-ONU to convey information about packet buffer capabilities to the DPoE
System.
Table 32 - D-ONU Packet Buffer
2
2
2
Size
1
1
1
1
1
1
Name Description
Upstream Queues
Up Queues Max Per
Link
Total number of queues available to be assigned to logical links in the upstream direction
Maximum number of queues which can be assigned to a single logical link in the upstream direction
Up Queue Increment
The smallest allocatable increment of packet buffer memory in the upstream direction, in kilobytes
Downstream Queues Total number of queues available to be assigned to logical links in the downstream direction
Dn Queues Max Per
Port
Maximum number of queues which can be assigned to a single UNI port in the downstream direction
Dn Queue Increment The smallest allocatable increment of packet buffer memory in the downstream direction, in kilobytes
Total Packet Buffer Total packet buffer memory on the D-ONU (KB)
Up Packet Buffer
Dn Packet Buffer
Maximum amount of packet buffer memory which can be allocated to upstream queues
Maximum amount of packet buffer memory which can be allocated to downstream queues
9.1.10 Report Thresholds (0xD7/0x000B)
Objects: Logical Link
This attribute represents the threshold levels used to generate REPORT MPCPDUs. The format corresponds closely to the format of the REPORT MPCPDU, except that the bitmaps for report values present are omitted. The message specifies the number of queue sets and the number of report values in each queue set to be used on the link. A DPoE
System MUST insure the number of report values in each queue set is the same. For each queue set and report value, a threshold is specified.
A DPoE System MUST ensure the report thresholds for successive queue sets are increasing. A DPoE System
MUST ensure the report thresholds for successive queue sets are cumulative. For example, Report Threshold 0 for
Queue Set 1 must be equal to or greater than Report Threshold 0 in Queue Set 0. A higher numbered queue set includes all the data reported in earlier queue sets, plus possibly some additional data.
Table 33 - Report Thresholds
Size
2
2
1
1
2
Description
Number of Queue Sets
Report Values Per Queue Set
Report Threshold 0 for Queue Set 0
…
Report Threshold n-1 for Queue Set 0
…
Report Threshold 0 for Queue Set n-1
…
Units
EPON TQ
EPON TQ
EPON TQ
Default
-
-
4
1
2048
0
0
1
1
0
Min Max
4
8
0xFFFF
0xFFFF
0xFFFF
08/08/13
CableLabs
39
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Size
2
Description
Report Threshold n-1 for Queue Set n-1
Units
EPON TQ -
Default
0
Min Max
0xFFFF
9.1.11 LLID Forwarding State (0xD7/0x000C) R
Objects: Logical Link
This attribute represents the current traffic state for an LLID. User data traffic may be enabled (normal operation) or disabled (discarded by the D-ONU). Only OAM and MPCP remain enabled regardless of the LLID forwarding state.
Table 34 - Link State
1
Size Description
Link State (0=Disable, 1=Enable)
Units
Boolean 0
Default
0
Min
1
Max
9.1.12 OAM Frame Rate (0xD7/0x000D)
Objects: Logical Link
This attribute represents the maximum rate at which OAM PDUs are transmitted on a link.
Setting the Maximum OAM Frame Rate to 0 disables rate control.
The Minimum OAM Frame Rate is the heartbeat rate. This is the rate at which OAM PDUs are sent between the D-
heartbeat rate is specified as one heartbeat PDU per specified time interval. The time interval is specified as the value provisioned in the message x 100ms. Therefore, setting the Minimum OAM Frame Rate to 10 specifies a rate of 1 PDU per 10 x 100ms. This equals 1 PDU per 1 second.
The D-ONU implementation maintains one instance of the OAM rate. This rate applies to all links on the D-ONU.
Table 35 - OAM Frame Rate
1
1
Size Description
Maximum OAM rate
Minimum OAM rate
Units
PDUs/100ms
Number of 100ms
Default
1
10
Min
0 (Unlimited rate)
0 (no OAM) heartbeat)
25
10
Max
9.1.13 ONU Manufacturer Organization Name (0xD7/0x000E)
Objects: D-ONU
This attribute represents the organization which manufactured the D-ONU. The attribute is an ASCII string, with no null terminator. It is used to validate the manufacturer CVC during secure software download. The value must
details.
Table 36 - ONU Manufacturer Organization Name
Size Description
varies Organization name string
Units
-
Default
-
Min
-
Max
40
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
9.1.14 Firmware Mfg Time Varying Controls (0xD7/0x000F) NVS
Objects: D-ONU
This attribute represents the firmware CVC and CVS validity times as programmed into the D-ONU The TVC
affects the validity of firmware updates. See [DPoE-SECv2.0] for details.
Time values are ASCII strings representing the time in UTC in the format YYMMDDhhmmssZ. Per [DPoE-
SECv2.0], dates range from the year 1950 to 2050; the upper two digits of the year are implied.
Table 37 - Firmware Mfg Time Varying Controls
Size
13
13
Description
Code Access Start
CVC Access Start
Units
Seconds
Seconds
Default
-
-
Min
500101000000Z
500101000000Z
Max
491231235959Z
491231235959Z
9.1.15 D-ONU Port Type (0xD7/0x0010)
Objects: D-ONU
This message provides a means for the D-ONU to convey information about the type of individual ports and devices connected to them (if present), including embedded (eSAFE) and other known CPE type devices. There are in total
N ports available on the D-ONU, including physically exposed ports (MI/MU/CMCI) as well as embedded ports
(LCI) connecting to eSAFE devices.
This attribute contains N entries, one for each port on the D-ONU, where each entry corresponds to the D-ONU port type and indicates the device type that is connected to this port (if any). Each port on the D-ONU can be associated with one and only one device type.
Table 38 - D-ONU Port Type
Size
1
1
1
Name
Port 0 type
Port 1 type
Port N-1 type
Description
This field describes type of device connected to port 0 on D-ONU.
This field carries one of the values defined in Table X2.
This field describes type of device connected to port 1 on D-ONU.
This field carries one of the values defined in Table X2.
This field describes type of device connected to port N-1 on D-ONU.
This field carries one of the values defined in Table X2.
Individual port types are enumerated in Table 39.
Table 39 - Port type enumeration
Port type value
0x00
0x01
0x02
0x03
0x04
0x05
0x06
0x07
Enumeration
(designation)
unspecified eMTA eSTB-IP eSTB-DSG eTEA eSG eRouter eDVA
Description
Given D-ONU port is not connected to a known external or internal device
Given D-ONU port is connected to a PacketCable/eMTA
Given D-ONU port is connected to an eSTB-IP
Given D-ONU port is connected to an eSTB-DSG
Given D-ONU port is connected to an eTEA
Given D-ONU port is connected to an eSG
Given D-ONU port is connected to an eRouter
Given D-ONU port is connected to an eDVA
11
Revised per OAMv2.0-N-12.0048-1 by JB on 3/12/13.
08/08/13
CableLabs
41
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Port type value
0x08
0x09 – 0xFF
Enumeration
(designation)
Description
SEB eSTB-IP Given D-ONU port is connected to a SEB eSTB-IP
Reserved and ignored on reception
9.1.16 Vendor Name (D7/00 11) R
This attribute represents the ONU vendor name. The attribute is an ASCII string, with no null terminator. It can be
the same as the ONU Manufacturer Organization Name. Format of the vendor name is vendor specific. The D-ONU
SHOULD limit the vendor name length to less than 32 bytes.
Table 40 - ONU Manufacturer Organization Name
Size Description
varies Vendor name string
Units
-
Default
-
Min
-
Max
9.1.17 Model Number (D7/00 12) R
This attribute represents the ONU model number. The attribute is an ASCII string, with no null terminator. It can be
number is vendor specific. The D-ONU SHOULD limit the model number length to less than 32 bytes.
Table 41 - ONU Model Number
Size Description
varies Model number string
Units
-
Default
-
Min
-
Max
9.1.18 Hardware Version (D7/00 13) R
This attribute represents the ONU hardware version. The attribute is an ASCII string, with no null terminator. It can
hardware version information is vendor specific. The D-ONU SHOULD limit the hardware version length to less than 32 bytes.
Table 42- ONU Hardware Version
Size Description
varies Hardware version string
Units
-
Default
-
Min
-
Max
12
Sections 9.1.17 - 9.1.19 added per OAMv2.0-N-12.0048-1 by JB on 3/12/13.
13
Tables 41 and 42 updated with corrected table captions and descriptions per OAMv2.0-N-13.0066-2 on 3/13/13 by JB.
42
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
9.1.19 Reset D-ONU (0xD9/0x0001)
Objects: D-ONU
This attribute resets the D-ONU, as if from power on.
9.2 Bridging
9.2.1 Dynamic Learning Table Size (0xD7/0x0101) R
Objects: D-ONU
This attribute is a capability attribute that represents the maximum size of the D-ONU MAC address learning table for the D-ONU as a whole. The total number of MAC addresses learned by the D-ONU cannot exceed this number.
Table 43 - Dynamic Learning Table Size
Size
4
Description
Dynamic MAC learning table size
Units
Entries n/a
Default
1
Min Max
0xFFFF FFFF
9.2.2 Dynamic Address Age Limit (0xD7/0x0102)
Objects: D-ONU
This attribute represents Dynamic MAC learning table age limit.
Table 44 - Dynamic Address Age Limit
Size
2
Description
Dynamic MAC learning table age limit
Units
10 ms
Default
2000 0
Min Max
0xFFFF
9.2.3 Dynamic MAC Table (0xD7/0x0103) R
Objects: User Port
This attribute represents the dynamically learned MAC address rules of one Ethernet port. MAC address are repeated within a single attribute until that attribute is full (21 addresses = 126 bytes). If necessary, such attributes are repeated as an attribute list until the entire table has been reported.
Table 45 - Dynamic MAC Table
Units Min Max Size
6
...
Description
MAC address 0
MAC address 1
-
-
--
-
Default
-
-
-
-
9.2.4 Static MAC Table (0xD7/0x0104) R
Objects: User Port
This attribute represents the statically provisioned MAC address table. The data structure is the same as the Get
Dynamic MAC Table attribute above.
08/08/13
CableLabs
43
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
9.2.5 S
1
Interface Port Auto-negotiation (0xD7/0x0105)
Objects: Network Port, User Port
This attribute represents the auto-negotiation advertisement values used by a port. The set command specifies the values to advertise, while the get command returns the current values along with the values the port can physically support.
Table 46 - S1 Interface Port Auto-Negotiation
Size
2
2
Description
Bit array of maximum capabilities (see Table 47).
In Set request message, this field is set to 0x00-00 and ignored on receiption.
Bit array of current capabilities (see Table 47). A capability
is advertised as supported when its bit = 1.
Units Default
Bitmap Depends on port
Bitmap Depends on port
-
Min
-
-
Max
-
Table 47 - Port Capabilities
Auto-Negotiation Capability
Half Duplex
Full Duplex
10 Mbps
100 Mbps
1000 Mbps
10 Gbps
Flow Control
Auto MDI/MDI-X
Unused (set to 0)
Bit 0 (LSB)
Bit 1
Bit 2
Bit 3
Bit 4
Bit 5
Bit 6
Bit 7
Bit 8-15
9.2.6 Source Address Admission Control (0xD7/0x0106)
Objects: User Port
This attribute controls the operation of the MAC Source Address-based admission control function operating on the
DPoE ONU port in context in the upstream direction
Table 48 - Source Address Admission Control
Size
1
Description
Indicates whether the Source Address
Admission Control for the given DPoE
ONU port is enabled or not.
0 = disabled
1 = enabled
Units
enum 0
Default
0
Min
1
Max
The MAC Source Address-based admission control function operating on the selected DPOE ONU port in the upstream direction controls what frames received from DPOE ONU ports are admitted for upstream transmission.
When the MAC Source Address-based admission control function is disabled, all frames received from the DPOE
ONU port are admitted for upstream transmission. When the MAC Source Address-based admission control function is enabled, the DPoE ONU MUST drop any frame received from the DPOE ONU ports if the MAC Source
14
Revised per OAMv2.0-N-12.0056-1on 3/12/13 by JB.
44
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
Address for such a frame is not present in the MAC address admission control table on the DPOE ONU. The said table may be filled through dynamic MAC learning or configured through provisioning.
9.2.7 MAC Learning Min Guarantee (0xD7/0x0107)
Objects: User Port
This attribute represents minimum number of MAC addresses that can be learned on an individual UNI port.
Table 49 - MAC Learning Min Guarantee
2
Size Description
Minimum guaranteed limit
Units
Entries 40
Default
0
Min
40
Max
9.2.8 MAC Learning Max Allowed (0xD7/0x0108)
Objects: User Port
This attribute represents maximum allowed number of MAC addresses on an individual S
1
port.
Table 50 - MAC Learning Max Allowed
2
Size Description
Maximum allowed limit
Units
Entries n/a
Default
0
Min Max
0xFFFF
9.2.9 MAC Learning Aggregate Limit (0xD7/0x0109)
Objects: D-ONU
This message represents the aggregate dynamic MAC address limit for the D-ONU as a whole. This is the maximum number of addresses that can be learned by all ports combined. Setting the limit to zero disables MAC learning on the D-ONU.
Table 51 - MAC Learning Aggregate Limit
2
Size Description
The D-ONU aggregate dynamic MAC address limit
Units
Entries 0
Default
0
Min Max
0xFFFF
9.2.10 Len Error Discard (0xD7/0x010A)
Objects: User Port
This attribute represents the Length Error Discard Enable status of the D-ONU ports. Length errors occur when the layer 2 length does not match the frame length.
Table 52 - Len Error Discard
Size
1
Description
If Length Error Discard Enable
0: Frames with a Length Error will be passed
1: Frames with a Length Error will be discarded
Units
Boolean 1
Default
0
Min
1
Max
08/08/13
CableLabs
45
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
9.2.11 Flood Unknown (0xD7/0x010B)
Objects: D-ONU
This message represents the configuration for flooding of downstream frames whose destination addresses have not been learned. Disabling will cause these frames to be discarded.
Table 53 - Flood Unknown
Size
1
Description
Flood Unknown DA option
0: Drop unknown MAC DA
1: Flood unknown MAC DA
Units
Boolean 1
Default
0
Min
1
Max
9.2.12 Local Switching (0xD7/0x010C)
Objects: User Port
This attribute represents the configuration of a port for local switching. With local switching enabled, a port may send traffic to any other user-side port of the D-ONU. This feature should be used with caution for unknown flooding.
Table 54 - Local Switching
Size
1
Description
Local Switching option
0: Disable local switching
1: Enable local switching
Units
Boolean 0
Default
0
Min
1
Max
9.2.13 LLID and Queue Configuration (0xD7/0x010D)
Objects: D-ONU
This TLV configures the number of LLIDs to be registered by the given D-ONU. The DPoE System sends this message to change the number of links to be registered, adding or subtracting LLIDs as the network configuration requires. The number of links is bundled together with the configuration of the upstream queues associated with each LLID, as well as the downstream queues on the D-ONU. The upstream queues hold frames destined for the given LLID. The downstream queues hold frames destined for the UNI Ethernet ports. Queue sizes are specified in the order of queue priority, where the first queue associated for the given LLID or port has the highest priority.
The DPoE ONU MUST reject a queue configuration message that changes queue numbers or size for any
LLIDs/queues that have port ingress rules that use those queues. The vCM MUST delete all port ingress rules that forward traffic to particular queues before those queues can be deleted (including by removing their LLID) or resized.
Table 55 - LLID and Queue Configuration
Size
Upstream Configuration
1
Description
N, the number of LLIDs to configure.
LLID 0 Configuration
1
M
M, the number of upstream queues for LLID 0
1 Queue 0 Size
Units
queues
4KB
1
1
Default
1
1
1
Min
8
-
Max*
255
15
Revised per OAMv2.0-12.0050-1 on 3/12/13 by JB.
46
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
Size Description Units
… …
1 Queue M - 1 Size
LLID 1 Configuration
…
LLID N - 1 Configuration
4KB
Downstream Configuration
1 P, the number of Ports to configure.
Port 0 Configuration (i.e., Ethernet port 1)
1
J
J, the number of downstream queues for Port 0
1 Queue 0 Size
… …
1 Queue J - 1 Size queues
4KB
4KB
Port 1 Configuration
…
Port P – 1 Configuration
8
Default
1
1
0
1
1
Min
-
-
-
8
-
Max*
Note
The Maximum value is subject to available queues. Some of these queues are required by the system for internal use, especially depending on the number of LLIDs to register.
The message above consists of two configuration sections: Upstream and Downstream. The upstream section of the message specifies LLID configuration. The TU interface port registers one or more LLIDs, and each LLID can be assigned one or more queues. The downstream section specifies UNI port configuration. Each port can be assigned one or more queues. The sum of queue sizes must not exceed the size reported in the Get D-ONU Information.
9.2.14 Firmware Filename (0xD7/0x010E) NVS R
Objects: D-ONU
This attribute represents the name of the DPoE ONU firmware file, as obtained by the vCM from the OSS. This attribute is read-only by OAM and is set during the software update process, where the name of the DPoE ONU firmware file is carried in the File Transfer Write Request PDU. The DPoE ONU firmware file name has the format of a null-terminated ASCII string.
9.2.15 MAC Table Full Behavior (0xD7/0x010F)
Objects: User Port
This attribute controls behavior of the D-ONU MAC address learning process when it has reached a limit of MAC addresses, and a new address is discovered. The default behavior is to discard the new address. The alternative is to overwrite the oldest address in the table with the newly discovered address.
Table 56 - MAC Table Full Behavior
Size
1
Description
MAC Table Full option
0: Discard new address
1: Overwrite oldest address
Units
Enumerated 0
Default
0
Min
1
Max
16
Revised per OAMv2.0-N-12.0056-1on 3/12/13 by JB.
08/08/13
CableLabs
47
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
9.2.16 Clear Dynamic MAC Table (0xD9/0x0101)
Objects: D-ONU, User Port
This action clears the dynamically learned MAC addresses table for the object in context, either a particular port, or the D-ONU as a whole (all S
1
ports on the D-ONU).
9.2.17 Add Dynamic MAC Address (0xD9/0x0102)
Objects: User Port
This attribute adds one or more dynamic MAC addresses to the table for the port in context.
Table 57 - Add Dynamic MAC Address
Units Default Min Size
6
...
Description
MAC address 0
MAC address 1
--
-
-
-
-
-
-
-
Max
9.2.18 Delete Dynamic MAC Address (0xD9/0x0103)
Objects: User Port
This attribute deletes one or more dynamic MAC addresses to the table for the port in context. Format is the same as for Add Dynamic MAC Address.
9.2.19 Clear Static MAC Table (0xD9/0x0104)
Objects: D-ONU, User Port
This action clears the entire static MAC address table for the object in context, either a particular port, or the D-
ONU as a whole (all S
1
ports on the D-ONU).
9.2.20 Add Static MAC Address (0xD9/0x0105)
Objects: User Port
This attribute adds one or more static MAC addresses from the forwarding table for the port in context.
Table 58 - Add Static MAC Address
Units Default Min Size
6
...
Description
MAC address 0
MAC address 1
-
-
-
-
-
-
-
-
Max
9.2.21 Delete Static MAC Address (0xD9/0x0106)
Objects: User Port
This attribute adds one or more static MAC addresses from the forwarding table for the port in context.
Table 59 - Delete Static MAC Address
Units Default Min Size
6
...
Description
MAC address 0
MAC address 1
-
-
-
-
-
-
-
-
Max
48
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
9.3 Statistics And Counters
Many counter attributes can be used with different object context to provide various granularity on the statistics. For example, a "frames transmitted" counter attribute might be applicable to queues, logical links, or ports. D-ONUs
MAY implement the coarser granularity counters by summing over all the finer-grained objects that feed into the coarser ones.
9.3.1 Rx Frames Green (0xD7/0x0201)
Objects: Network Port, User Port, Logical Link, Queue
This attribute represents the count of frames received at one port. If color marking is not in use, all received frames are considered "green" frames.
Table 60 - Rx Frames Green
Size
8
Description
Frames received at object in context
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.2 Tx Frames Green (0xD7/0x0202)
Objects: Network Port, User Port, Logical Link, Queue
This attribute represents the count of frames transmitted from one port. If color shaping is not in use, all transmitted frames are considered "green" frames.
Table 61 - Tx Frames Green
Size
8
Description
Frames transmitted from object in context
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.3 Rx Frame Too Short (0xD7/0x0203)
Objects: Network Port, User Port
This attribute represents RxFrameTooShort counter of one port.
Table 62 - Rx Frame Too Short
Size
8
Description
RxFrameTooShort counter of one port
Units
Frames -
Default
0
Min
9.3.4 Rx Frame 64 (0xD7/0x0204)
Objects: Network Port, User Port
This attribute represents RxFrame64 counter of one port.
Table 63 - Rx Frame
Size
8
Description
RxFrame64 counter of one port
Units
Frames -
Default
0
Min
Max
0xFFFF FFFF FFFF FFFF
Max
0xFFFF FFFF FFFF FFFF
08/08/13
CableLabs
49
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
9.3.5 Rx Frame 65_127 (0xD7/0x0205)
Objects: Network Port, User Port
This attribute represents RxFrame65_127 counter of one port.
Table 64 - Rx Frame 65_127
Size
8
Description
RxFrame65_127 counter of one port
Units
Frames -
Default
0
Min
9.3.6 Rx Frame 128_255 (0xD7/0x0206)
Objects: Network Port, User Port
This attribute represents RxFrame128_255 counter of one port.
Table 65 - Rx Frame 128_255
Size
8
Description
RxFrame128_255 counter of one port
Units
Frames -
Default
0
Min
9.3.7 Rx Frame 256_511 (0xD7/0x0207)
Objects: Network Port, User Port
This attribute represents RxFrame256_511 counter of one port.
Table 66 - Rx Frame 256_511
Size
8
Description
RxFrame256_511 counter of one port
Units
Frames -
Default
0
Min
9.3.8 Rx Frame 512_1023 (0xD7/0x0208)
Objects: Network Port, User Port
This attribute represents RxFrame512_1023 counter of one port.
Table 67 - Rx Frame 512_1023
Size
8
Description
RxFrame512_1023 counter of one port
Units
Frames -
Default
0
Min
9.3.9 Rx Frame 1024_1518 (0xD7/0x0209)
Objects: Network Port, User Port
This attribute represents RxFrame1024_1518 counter of one port.
Table 68 - Rx Frame 1024_1518
8
Size Description Units
RxFrame1024_1518 counter of one port Frames -
Default
0
Min
Max
0xFFFF FFFF FFFF FFFF
Max
0xFFFF FFFF FFFF FFFF
Max
0xFFFF FFFF FFFF FFFF
Max
0xFFFF FFFF FFFF FFFF
Max
0xFFFF FFFF FFFF FFFF
50
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
9.3.10 Rx Frame 1519 Plus (0xD7/0x020A)
Objects: Network Port, User Port
This attribute represents RxFrame1519Plus counter of one port.
Table 69 - Rx Frame 1519 Plus
Size
8
Description
RxFrame1519Plus counter of one port
Units
Frames -
Default
0
Min
9.3.11 Tx Frame 64 (0xD7/0x020B)
Objects: Network Port, User Port
This attribute represents TxFrame64 counter of one port.
Table 70 - Tx Frame 64
Size
8
Description
TxFrame64 counter of one port
Units
Frames -
Default
9.3.12 Tx Frame 65_127 (0xD7/0x020C)
0
Min
Objects: Network Port, User Port
This attribute represents TxFrame65_127 counter of one port.
Table 71 - Tx Frame 65_127
Size
8
Description
TxFrame65_127 counter of one port
Units
Frames -
Default
0
Min
9.3.13 Tx Frame 128_255 (0xD7/0x020D)
Objects: Network Port, User Port
This attribute represents TxFrame128_255 counter of one port.
Table 72 - Tx Frame 128_255
Size
8
Description
TxFrame128_255 counter of one port
Units
Frames -
Default
0
Min
9.3.14 Tx Frame 256_511 (0xD7/0x020E)
Objects: Network Port, User Port
This attribute represents TxFrame256_511 counter of one port.
Table 73 - Tx Frame 256_511
Size
8
Description
TxFrame256_511 counter of one port
Units
Frames -
Default
0
Min
Max
0xFFFF FFFF FFFF FFFF
Max
0xFFFF FFFF FFFF FFFF
Max
0xFFFF FFFF FFFF FFFF
Max
0xFFFF FFFF FFFF FFFF
Max
0xFFFF FFFF FFFF FFFF
08/08/13
CableLabs
51
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
9.3.15 Tx Frame 512_1023 (0xD7/0x020F)
Objects: Network Port, User Port
This attribute represents TxFrame512_1023 counter of one port.
Table 74 - Tx Frame 512_1023
Size
8
Description
TxFrame512_1023 counter of one port
Units
Frames -
Default
0
Min
9.3.16 Tx Frame 1024_1518 (0xD7/0x0210)
Objects: Network Port, User Port
This attribute represents TxFrame1024_1518 counter of one port.
Table 75 - Tx Frame 1024_1518
Size
8
Description
TxFrame1024_1518 counter of one port
Units
Frames -
Default
0
Min
9.3.17 Tx Frame 1519 Plus (0xD7/0x0211)
Max
0xFFFF FFFF FFFF FFFF
Max
0xFFFF FFFF FFFF FFFF
Objects: Network Port, User Port
This attribute represents TxFrame1519Plus counter of one port.
Table 76 - Tx Frame 1519 Plus
Size
8
Description
TxFrame1519Plus counter of one port
Units
Frames -
Default
0
Min
9.3.18 Queue Delay Threshold (0xD7/0x0212)
Max
0xFFFF FFFF FFFF FFFF
Objects: Queue
This attribute represents Threshold for Delay that causes Bytes Delayed counter to increment for a queue, hereafter referred to as “DelayThreshold”. The current object context is used to identify the queue for which this attribute is relevant.
Table 77 - Queue Delay Threshold
Size
1
Description
QueueDelayThreshold for a queue
Units
100us
Default
0x1E 0
Min
0xFF
Max
9.3.19 Queue Delay (0xD7/0x0213)
Objects: Queue
17
Revised tables and text 9.3.18 through 9.3.23 and deleted tables and text 9.3.24 - 9.3.28 per OAMv2.0-N-13.0066-2 on 3/13/13 by JB.
52
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
This attribute represents Maximum Frame Delay experienced since statistic reset for a queue. The current object context is used to identify the queue for which this attribute is relevant.
Table 78 - Queue Delay
Size
8
Description
QueueDelay for a queue
Units
100us -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.20 Frames Dropped (0xD7/0x0214)
Objects: Queue
This attribute represents the frames dropped due to queue overflow or rate control discard ("red" frames). The current object context is used to identify the queue for which this attribute is relevant..
Table 79 - Frames Dropped
Size
8
Description
FramesDropped counter for a queue
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.21 Bytes Dropped (0xD7/0x0215)
Objects: Queue
This attribute represents the bytes dropped due to queue overflow or rate control discard (bytes in "red" frames). The current object context is used to identify the queue for which this attribute is relevant.
Table 80 - Bytes Dropped
Size
8
Description
BytesDropped counter for a queue
Units
bytes -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.22 Bytes Delayed (0xD7/0x0216)
Objects: Queue
This attribute represents the bytes in frames with a D-ONU queue residency time greater than DelayThreshold for a queue. The current object context is used to identify the queue for which this attribute is relevant.
Table 81 - Bytes Delayed
Size
8
Description
BytesDelayed counter for a queue
Units
bytes -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.23 Tx Bytes Unused (0xD7/0x0217)
Objects: Logical Link
This attribute represents the bytes granted to the LLID but not filled with transmitted data.
Table 82 - Tx Bytes Unused
Size
8
Description
TxBytesUnused counter of one LLID
Units
bytes -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
08/08/13
CableLabs
53
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
9.3.24 Optical Mon Temperature (0xD7/0x021D)
Objects: Network Port
This attribute represents the current optical module temperature, expressed in the form of a 16 bit signed twos complement value in increments of 1/256 degrees Celsius valid between –40C and +125C.
Table 83 - Optical Mon Temperature
Size
2
Description
Current temperature
Units
1/256 C -
Default Min
0x8000
Max
0x7FFF
9.3.25 Optical Mon Vcc (0xD7/0x021E)
Objects: Network Port
This attribute represents the current optical module Vcc.
Table 84 - Optical Mon Vcc
Size
2 Current Vcc
Description Units
100 uV -
Default
9.3.26 Optical Mon Tx Bias Current (0xD7/0x021F)
0
Min
Objects: Network Port
This attribute represents the current optical module Tx bias current.
Table 85 - Optical Mon Tx Bias Current
Size
2
Description
Current Tx bias 2 uA
Units
-
Default
9.3.27 Optical Mon Tx Power (0xD7/0x0220)
0
Min
Objects: Network Port
This attribute represents the current optical module Tx power.
Table 86 - Optical Mon Tx Power
Size
2
Description
Current Tx power
Units
0.1uW -
Default
9.3.28 Optical Mon Rx Power (0xD7/0x0221)
Objects: Network Port
0
Min
Max
0xFFFF
Max
0xFFFF
Max
0xFFFF
18
Revised per OAMv2.0-12.0050-1 on 3/12/13 by JB.
19
Revised per OAMv2.0-12.0050-1 on 3/12/13 by JB.
20
Revised per OAMv2.0-12.0050-1 on 3/12/13 by JB.
21
Revised per OAMv2.0-12.0050-1 on 3/12/13 by JB.
22
Revised per OAMv2.0-12.0050-1 on 3/12/13 by JB.
54
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
This attribute represents the current optical module Rx power.
Table 87 - Optical Mon Rx Power
Size
2
Description
Current Rx power
Units
0.1uW -
Default
0
Min Max
0xFFFF
9.3.29 Rx Frames Yellow (0xD7/0x0222)
Objects: Network Port, User Port, Logical Link, Queue
This attribute represents the count of frames received at one port. If color marking is not in use, this value is zero.
Table 88 - Rx Frames Yellow
Size
8
Description
Frames received at object in context
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.30 Tx Frames Yellow (0xD7/0x0223)
Objects: Network Port, User Port, Logical Link, Queue
This attribute represents the count of frames transmitted from one port. If color shaping is not in use, all transmitted frames are considered "green" frames.
Table 89 - Tx FramesYellow
8
Size Description
Frames transmitted from object in context
Units Default
Frames - 0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.31 Tx Bytes Green (0xD7/0x0224)
Objects: Network Port, User Port, Logical Link, Queue
This attribute represents the count of bytes in green frames transmitted from one port. If color shaping is not in use, all transmitted frames are considered "green" frames.
Table 90 - Tx Bytes Green
8
Size Description
Frames transmitted from object in context
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.32 Rx Bytes Yellow (0xD7/0x0225)
Objects: Network Port, User Port, Logical Link, Queue
This attribute represents the count of bytes in yellow frames received at one port. If color shaping is not in use, this value is zero.
9.3.33 Rx Bytes Green (0xD7/0x0226)
Objects: Network Port, User Port, Logical Link, Queue
This attribute represents the count of bytes in green frames received at one port. If color shaping is not in use, all received frames are considered "green" frames.
08/08/13
CableLabs
55
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
8
Size Description
Frames transmitted from object in context
Table 91 - Tx Bytes Green
Units Default
Frames - 0
Min
9.3.34 Tx Bytes Yellow (0xD7/0x0227)
Max
0xFFFF FFFF FFFF FFFF
Objects: Network Port, User Port, Logical Link, Queue
This attribute represents the count of bytes in yellow frames transmitted from one port. If color shaping is not in use, this value is zero.
Table 92 - Tx Bytes Yellow
8
Size Description
Frames transmitted from object in context
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.35 Tx Frames Unicast (0xD7/0x0228)
Objects: Network Port, User Port
This attribute represents the count of frames transmitted with a unicast L2 DA.
Table 93 - Tx Frames Unicast
8
Size Description
Frames transmitted from object in context
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.36 Tx Frames Multicast (0xD7/0x0229)
Objects: Network Port, User Port
This attribute represents the count frames transmitted with a multicast L2 DA (bit 40 set).
Table 94 - Tx Frames Multicast
8
Size Description
Frames transmitted from object in context
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.37 Tx Frames Broadcast (0xD7/0x022A)
Objects: Network Port, User Port
This attribute represents the count of frames transmitted with the broadcast L2 DA (all 1s).
Table 95 - Tx Frames Broadcast
8
Size Description
Frames transmitted from object in context
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.38 Rx Frames Unicast (0xD7/0x022B)
Objects: Network Port, User Port
This attribute represents the count frames received with a L2 unicast DA (bit 40 = 0).
56
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
8
Size Description
Frames received at object in context
Table 96 - Rx Frames Unicast
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.39 Rx Frames Multicast (0xD7/0x022C)
Objects: Network Port, User Port
This attribute represents the count of frames received with a multicast L2 DA (bit 40 set).
Table 97 - Rx Frames Multicast
8
Size Description
Frames received at object in context
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.40 Rx Frames Broadcast (0xD7/0x022D)
Objects: Network Port, User Port
This attribute represents the count of frames received with the broadcast L2 DA (all 1s).
Table 98 - Rx Frames Broadcast
8
Size Description
Frames received at object in context
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.41 Number of Programmable Counters (0xD7/0x022E) R
Objects: D-ONU
This capabilities attribute indicates the number of programmable frame/byte counters supported by the D-ONU hardware.
9.3.42 L2CP Frames Rx (0xD7/0x022F)
Objects: Network Port, User Port
Number of layer 2 control protocol frames received.
Table 99 - L2CP Frames Rx
8
Size Description Units
L2CP frames received at object in context Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.43 L2CP Octets Rx (0xD7/0x0230)
Objects: Network Port, User Port
Number of octets in layer 2 control protocol frames received.
23
Revised and added new tables to 9.3.47 - 9,3,54 per OAMv2.0-12.0050-1 on 3/12/13 by JB.
08/08/13
CableLabs
57
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Table 100 - L2CP Octets Rx
Default
8
Size Description Units
Octets in L2CP frames received at object in context
Octets - 0
Min
9.3.44 L2CP Frames Tx (0xD7/0x0231)
Max
0xFFFF FFFF FFFF FFFF
Objects: Network Port, User Port
Number of layer 2 control protocol frames transmitted.
Table 101 - L2CP Frames Tx
8
Size Description
L2CP frames transmitted at object in context
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.45 L2CP Octets Tx (0xD7/0x0232)
Objects: Network Port, User Port
Number of octets in layer 2 control protocol frames transmitted.
Table 102 - L2CP Octets Tx
8
Size Description
Octets in L2CP frames transmitted at object in context
Units
Octets -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.46 L2CP Frames Discarded (0xD7/0x0233)
Objects: Network Port, User Port
Number of layer 2 control protocol frames discarded (because the D-ONU was configured to discard those protocols, rather than tunnel or peer them).
Table 103 - L2CP Frames Discarded
8
Size Description
L2CP frames discarded at object in context
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.47 L2CP Octets Discarded (0xD7/0x0234)
Objects: Network Port, User Port
Number of octets in layer 2 control protocol frames discarded (because the D-ONU was configured to discard those protocols, rather than tunnel or peer them).
Table 104 - L2CP Octets Discarded
8
Size Description
Octets in L2CP frames discarded at object in context
Units
Octets -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
58
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
9.3.48 Tx L2 Errors (0xD7/0x0235)
Objects: Network Port, User Port
Number of frames that failed to transmit because of an error in the data link layer (too many collisions, etc.).
Table 105 - Tx L2 Errors
8
Size Description
L2 frames discarded at object in context in the transmit direction
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.49 Rx L2 Errors (0xD7/0x0236)
Objects: Network Port, User Port
Number of received frames discarded due to errors in the frame (FCS errors, length errors, etc.).
Table 106 - Rx L2 Errors
8
Size Description
L2 frames discarded at object in context in the receive direction
Units
Frames -
Default
0
Min Max
0xFFFF FFFF FFFF FFFF
9.3.50 Clear Counters (0xD9/0x0201)
Objects: D-ONU
This action clears all statistics counters for the D-ONU.
9.3.51 Programmable Frame/Byte Counter (0xD8/nnnn)
Objects: D-ONU
There are a maximum of 32,768 programmable counter attributes, "Programmable Counter 0" through
"Programmable Counter 32767". The 0xD8 branch indicates a programmable counter; the leaf code indicates the exact counter. Programmable counters count both bytes and frames. The leaf codes of a frame counter and the corresponding byte counter are related; the frame counter with leaf code I corresponds to the byte counter with leaf code I + 0x8000.
The programmable counter index for the frame counter (0..32767) is used as the parameter for the Increment
Counter rule result. The rule result increments both the frame and byte counters for frames that match the rule condition.
9.4 Alarms
57 Event Notification PDU.
9.4.1 Port Stat Threshold (0xD7/0x0301)
Objects: Network Port, User Port
This attribute allows the OAM client to specify an alarm to be generated when a port statistics counter exceeds a certain value at the end of a 1-second sampling period. A rising threshold and a falling threshold (high-water mark and low-water mark) are provided to allow hysteresis. The alarm condition will occur when the statistic is greater
08/08/13
CableLabs
59
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services than or equal to the rising threshold. The alarm condition will be cleared when the statistic is less than or equal to the falling threshold. A value of 0 for the rising threshold means that the alarm is disabled.
Table 107 - Port Stat Threshold
Size
3
4
4
Description
Statistic Attribute branch/leaf
Rising Threshold (to set alarm; 0 disables the alarm)
Falling Threshold (to clear alarm)
Units
-
As stat
As stat
-
-
-
Default
0
0
0
Min Max
0xFF FFFF
0xFFFF FFFF
0xFFFF FFFF
9.4.2 Link Stat Threshold (0xD7/0x0302)
Objects: Logical Link
This attribute allows the OAM client to specify an alarm to be generated when a LLID statistics counter exceeds a certain value at the end of a 1-second sampling period. A rising threshold and a falling threshold (high-water mark and low-water mark) are provided to allow hysteresis. The alarm condition will occur when the statistic is greater than or equal to the rising threshold. The alarm condition will be cleared when the statistic is less than or equal to the falling threshold. A value of 0 for the rising threshold means that the alarm is disabled.
Table 108 - Link Stat Threshold
Size
3
4
4
Description
Statistic Attribute Branch/Leaf)
Rising Threshold (to set alarm; 0 disables the alarm)
Falling Threshold (to clear alarm)
Units
-
As stat
As stat
-
-
-
Default
0
0
0
Min Max
0xFF FFFF
0xFFFF FFFF
0xFFFF FFFF
9.4.3 Suspend/Resume Alarm Reporting (0xD7/0x0303)
Objects: D-ONU, User Port, PON Port, Queue, Logical Link
This attribute allows the DPoE System to enable or disable transmission of alarm messages generated by the given context object. An enabled alarm behaves normally per the definition for that alarm. While an alarm is disabled, a
D-ONU MUST NOT signal this alarm in an Event Notification TLV. Alarms can be disabled on a per-object basis.
The object is specified using the Object Context TLV. A single Suspend/Resume Alarm Reporting message carries a total of N alarm status information tuples, where each alarm is described by the (Event Code, Enabled/Disabled)
message. Attempting to enable or disable an alarm message which is not relevant to the associated object context will result in an error..
Table 109 - Alarm Enable
Size
1
1
...
1
1
Description
Event Code(0)
Enabled /Disabled [0] (Enabled=1, Disabled=0)
...
Event Code [N-1]
Enabled/Disabled [N-1]
Units
Boolean
...
Boolean
Default
-
0
...
-
0
0
0
...
0
0
Min
0xFF
1
...
0xFF
1
Max
24
Revised text and table per OAMv2.0-N-12.0059-2 on 3/13/13 by JB.
60
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
When the Suspend/Resume Alarm attribute (0xD7/0x0303) is carried in the Get Response eOAMPDU, it contains
current object context.
9.4.4 Retrieve Current Alarm Summary (0xD9/0x0301)
Objects: D-ONU
This action directs the D-ONU to send a report of all currently raised alarm conditions. To report, the D-ONU generates a series of one or more Event Notification PDUs containing DPoE Alarm TLVs corresponding to all current alarm conditions at the D-ONU.
9.5 Security
Security attributes control encryption on the EPON. Details of encryption methods and their use can be found in
9.5.1 Encryption Key Expiry Time (0xD7/0x0401)
Objects: Logical Link
This attribute represents the timeout value for encryption keys. A new key will be generated and exchanged periodically, as this timer expires. A timeout value of 0 is used to disable security (i.e., encryption). The minimum non-zero value should be at least 10 seconds.
Table 110 - Encryption Key Expiry Time
Size
2
Description
Timeout value sec
Units
0
Default
0/10
Min Max
0xFFFF
9.5.2 Encryption Mode (0xD7/0x0402)
Objects: Logical Link
This attribute sets the encryption method to be used on a particular logical link. Details of encryption methods are
Table 111 - Encryption Mode
Size
1
Description
Encryption Method
0: None
1: 1Down
2: 10Down
3: 10Bi
Units
enum 0
Default
0
Min
3
Max
9.6 Frame Processing
9.6.1 Port Ingress Rule (0xD7/0x0501)
Objects: Network Port, User Port
This attribute represents a rule in the ingress table of the current port. A single rule, which can be complex and larger than the 128-byte contents of a single TLV, is represented in an OAM frame as a series of TLVs with this attribute code. The first byte of the attribute is always a subtype indicator, which indicates the structure of the rest of the TLV contents.
08/08/13
CableLabs
61
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
A single rule is represented by a sequential series of Port Ingress Rule TLVs, which must start with one Header subtype, then one or more Clause subtype TLVs, then one or more Result subtype TLVs, and finally end with a
Terminator subtype. For each rule, DPoE System MUST include one Header subtype, one or more Clause subtypes, one or more Result subtypes, and end with the Terminator subtype. Similarly, for each rule, D-ONU MUST include one Header subtype, one or more Clause subtypes, one or more Result subtypes, and end with the Terminator subtype.
The entire table of rules for a port would be represented as a large attribute, and thus include one or more
Header/Clause/Result/Terminator sequences, ultimately terminated by a zero-length container with the Port Ingress
Rule attribute value.
Table 112 - Rule Attribute Subtypes
0
1
2
Field Value Name
Terminator
Header
Clause
3 Result
Description
Indicates end of one individual rule
Information which pertains to the entire rule
One single clause of the rule condition; all clauses are ANDed together to form the condition that determines whether the rule matches
One single result that occurs if the rule condition is true
9.6.1.1 Rule Attribute – Terminator Subtype
The terminator subtype indicates the end of a single rule. There are no further contents in the body of this subtype.
9.6.1.2 Rule Attribute – Header Subtype
All rules begin with a Rule attribute of the Header subtype.
Table 113 - Rule Attribute Header Subtype
1
1
Size Name
Subtype
Precedence
Header (01)
Precedence of the rule (0x00..0xFF)
Description
Note:
0x00 is considered the highest rule precedence value, and 0xFF the lowest. Note that is the reverse of the order in the DOCSIS config file TLVs; the DPoE System inverts the precedence range when constructing DPoE OAM rules from those TLVs.
Size
1
1
1
1
1
1
1 varies
9.6.1.3 Rule Attribute – Clause Subtype
Rule clauses define the condition that must evaluate to true for the rule to match a frame. All clauses of a rule are evaluated and the individual results ANDed together to determine the match condition. An individual clause is a binary operation which relates a field in the frame with a constant match value via a binary operator.
Table 114 - Rule Attribute Clause Subtype
Name
Subtype
Field Code
Field Instance
MSB Mask
LSB Mask
Operator
Match Value Length
Match Value
Description
Clause (02)
Code representing the field of the frame for this clause; see Table 115.
Which instance of a field identified by code (if there is more than one)
Bits to ignore on the most significant side of the field
Bits to ignore on the least significant side of the field
Binary operator for this rule
Number of bytes of Match Value to follow
Constant value combined with field value via the binary operator for this clause
62
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
Some fields, such as VLAN tags, occur in multiple instances in some frames. To distinguish two such fields, a Field
Instance is used in conjunction with the Field Code. Instances of such fields are numbered starting from 0 in the order in which they are transmitted in the frame. So, for example, C-VLAN tag 0 would be the outermost tag in a frame, immediately after the addresses, with two C-VLAN tags, with C-VLAN tag 1 being the inner tag, closer to the payload of the frame.
The most-significant- and least-significant-bits masks are used to reduce the number of field codes and provide flexibility for frame processing rules. A VLAN tag, for instance, is coded as one field. Commonly, however, rules might be interested in just the Tag Protocol Identifier (TPID), just the Class of Service (CoS), or just the VID portions of this field. A rule can compare these subfields by using the MSB and LSB masks to isolate the sub-field of interest. Similarly, the IPv4 TOS field is 8 bits wide, but the same bits are interpreted as IP Precedence (upper three bits) or DSCP. Any of these interpretations can be accommodated with the single IPv4 TOS field and the
the Customer Destination or Source MAC address.
The match value is a variable-length field, always an integral number of octets wide. Values are right-aligned in this field, occupying the least significant bits.
Since IPv4 and IPv6 headers have similar semantics, and a single frame can only be one or the other, but not both, of these types, some field codes are re-used for the IP equivalents like the addresses or priority fields. Rule sets that need to treat the same field differently based on protocol should use the EtherType field to distinguish IPv4 from
IPv6.
Table 115 - Field Codes
Value
(hex)
0x06
0x07
0x08
0x09
0x0A
0x0B
0x0C
0x0D
0x00
0x01
0x02
0x03
0x04
0x05
0x0E
0x0F
0x10
0x11
0x12
0x13
0x14
0x15
0x16
Description
LLID Index
L2 Destination MAC address
L2 Source MAC address
L2 Type/Len
S-VLAN Tag
C-VLAN Tag
MPLS Label Stacking Entry (LSE)
IPv4 TOS/IPv6 Traffic Class
IPv4 TTL/IPv6 Hop Limit
IPv4/IPv6 Protocol Type (Note 3)
IPv4 Source Address
IPv6 Source Address
IPv4 Destination Address
IPv6 Destination Address
IPv6 Next Header
IPv6 Flow Label
TCP/UDP source port
TCP/UDP destination port
B-Tag ([802.1ah])
Reserved
25
Revised per OAMv2.0-N-13.0062-1 on 3/13/13 by JB.
N
N
N
N
N
Y
Y
Y
N
N
N
N
N
N
N
N
N
-
N
N
N
Y* (Note 1)
N
Multiple?
08/08/13
CableLabs
63
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Value
(hex)
0x17
0x18
0x19
0x1A
0x1B
0x1C
0x1D
0x1E
0x1F
Description Multiple?
Reserved
Custom field 0
Custom field 1
Custom field 2
Custom field 3
Custom field 4
Custom field 5
Custom field 6
Custom field 7
-
N
N
N
N
N
N
N
N
Note 1:
IPv6 extension headers are instanced in the sense that there can be a variable number of them. However, they are not ordered in a frame. The instance number for this field is not the usual 0..N-1th instance of an instanced field, but is instead the Next Header value for that header type assigned by the IANA.
Note 2:
LLID Index represents the local index of the logical link instantiated on the DPoE ONU. For example, for a
DPoE ONU supporting 8 LLIDs, the value of LLID Index would range from 0 to 7. In this way, the LLID Index has only local, DPoE ONU specific meaning. The LLID Index matches the LLID in order of the link MAC address. That is, LLID Index 0 on a particular DPOE ONU is the LLID with the numerically lowest MAC address on that DPOE ONU; LLID Index 1 is the next higher MAC address, and so on.
Note 3:
IPv6 Protocol Type represents the Next Header field of the last extension header in the chain, which might contain any number of optional extension headers..
4
5
6
7
0
1
2
3
Field Value
F
==
!=
<=
>= exists
!exist
T
Symbol
Table 116 - Rule Operators
Description
Never match
Field equal to value
Field not equal to value
Field less than or equal to value
Field greater than or equal to value
True if field exists (value ignored)
True if field does not exist (value ignored)
Always match
9.6.1.4 Rule Attribute – Result Subtype
Rule results represent the processing performed on a frame when the frame matches the rule condition.
Table 117 - Rule Attribute Result Subtype
Size
1
1 varies
Name
Subtype
Rule Result
Result Parameters
Description
Result (03)
Rule Result Parameters, as defined for each result
64
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
Code
(hex)
0x00
0x01
0x02
Name
NOP
Discard
Forward
0x03
0x04
0x05
0x06
0x07
0x08
0x09
0x0A
0x0B
Queue
Set
Copy
Delete
Insert
Replace
Clear Delete
Clear Insert
Increment
Counter
Table 118 - Rule Results
Description
No operation
Set Discard Flag for Frame
Clear Discard Flag for Frame (Forward
Frame)
Set destination queue for frame
Paramet er Len
0
0
0
4
Set output field
Copy output field
4+ n
4
Parameter
{object type, object instance, queue
Field to set; n bytes of value
Field to set from field used in last clause of rule
Field Code to remove from frame
Field Code to insert into frame
Field Code to replace
Delete field
Insert field
Delete field and Insert current output field
Do not delete field (override other Delete result)
Do not insert field (override other Insert result)
Increments programmable counter for frames that match this rule, and bytes in those frames
2
2
2
2
2
2
Field Code not to delete
Field Code not to insert
Index for programmable counter to increment
9.6.1.4.1 NOP
The NOP result has no net effect, and does not affect the state of the frame. It can be useful as a placeholder result.
9.6.1.4.2 Discard
Frames are considered to be associated with a "discard" flag. If the discard flag is true after all rule processing, the frame will be discarded. This result sets the discard flag to true.
9.6.1.4.3 Forward
The Forward result sets the discard flag for a frame to false. The frame will be forwarded. (See the Queue result,
9.6.1.4.4 Queue
The Queue result sets the destination queue for a frame. A queue is specified as a {object type, object instance,
whether the port is a LLID or User Port, and uses the same values as the Object Context. Note that this parameter
has the same format as the Queue Object defined in Section 8.15.5. (See Table 27 - Queue Object).
9.6.1.4.5 Set
The Set result sets the value of an output field for the frame. The result takes as parameters the field descriptor to set, followed by the value for that field. Bits protected by the Mask values are not modified by the Set operation.
This feature allows setting just part of a field; for example, just the PCP bits in a VLAN tag. Values for fields that are not an integral multiple of eight bits wide are right-justified in the parameter value, and are padded with zeros on the left (most significant) bits.
08/08/13
CableLabs
65
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Size
1
1
1
1 varies
Name
Field Code
Field Instance
MSB Mask
LSB Mask
Value
Table 119 - Set Parameters
Description
Field code to set
Field Instance to set
Number of most significant bits not to modify
Number of least significant bits not to modify
New value for output field
9.6.1.4.6 Copy
The Copy result copies the value of some field into the specified output field. The source field is the field used in the
bits, or to copy an inner VLAN tag to an outer one. Bits of the output field protected by the Mask values are not modified by the Copy operation.
Table 120 - Copy Parameters
1
1
1
1
Size Name
Field Code
Field Instance
MSB Mask
LSB MAsk
Description
Field code to set
Field Instance to set
Number of most significant bits not to modify
Number of least significant bits not to modify
9.6.1.4.7 Delete
This result marks a field of a frame to be deleted. If the Delete flag is set after all rules have been processed, the deleted field will not be present in a forwarded frame. This result is commonly used to remove VLAN tags or other encapsulation from a frame. Note that it is not possible to delete just part of a field with "Mask" bits similar to some other field syntax.
Table 121 - Delete Parameters
1
1
Size Name
Field Code
Field Instance
Description
Field Code to delete
Field Instance to delete
9.6.1.4.8 Insert
The Insert result adds a field to a frame. If the Insert flag is set after all rules have been processed, the output field will be added to the frame. The value of the field normally will be Set by some other rule result. The default value for a field that did not exist in the frame is all zeroes. This result is commonly used to add VLAN tags or other encapsulation to a frame.
Table 122 - Insert Parameters
1
1
Size Name
Field Code
Field Instance
Description
Field Code to insert
Field Instance to insert
66
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
9.6.1.4.9 Replace
Replace combines the Insert and Delete results into a single operation for convenience, resulting in overwriting a field of a frame with a new value. This result is commonly used to translate priority values or VLAN tag values.
Table 123 - Replace Parameters
1
1
Size Name
Field Code
Field Instance
Description
Field Code to replace
Field Instance to replace
9.6.1.4.10 Clear Delete
This result clears the Delete flag for a field, reversing the decision of a lower precedence rule to delete the given field.
Table 124 - Clear Delete Parameters
1
1
Size Name
Field Code
Field Instance
Description
Field Code to keep
Field Instance to keep
9.6.1.4.11 Clear Insert
This result clears the Insert flag for a field, reversing the decision of a lower precedence rule to insert the given field.
Table 125 - Clear Insert Parameters
1
1
Size Name
Field Code
Field Instance
Description
Field Code not to insert
Field Instance not to insert
9.6.2 Custom Field (0xD7/0x0502)
Objects: Network Port, User Port
This attribute represents the fields parsed from each frame that are used in frame processing rules to filter or classify the frames.
Each D-ONU port contains a table of ingress rules that are applied to the frames received on the port. Each field is programmed with a field code. The code describes the field parsed from the frame in terms of protocol layer, dword in the frame, bit start, and bit width.
Table 126 - Custom Field
Size
1
1
1
1
1
1
Description
Layer select
32-bit word offset
Least significant bit (bit offset)
Bit width
Reference Count
Units
enum
32-bit words
Bits
Bits
Number of clauses
-
-
-
-
-
-
Default
0
1
0
18
0
0
Min Max
0x1F
8
8
31
32
255
The Reference Count indicates the number of clauses in rules that are currently using this field. If the field is currently unused, the Reference Count will be zero. When this is the case, the Layer Select, Dword offset, Least significant bit, and Bit width fields will contain the maximum possible values.
08/08/13
CableLabs
67
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Fields with a non-zero Reference Count cannot be reprogrammed with the Set PDU. All rules using a given field must be deleted, reducing the reference count to zero, before the meaning of that field is changed.
The Reference Count field is ignored in Set messages, and should be set to zero by the transmitter.
Table 127 - Custom Field Layer Values
Layer Value
0x0
0x1
0x2
0x3
0x4
0x5
0x6
0x7
0x8
0x9
0xA
Name Description
Preamble/L2 LLID, DA, SA, SNAP headers (if present)
LLID, B-DA, B-SA, I-Tag
EtherType
S-VLAN Tags
L2 protocol type of remainder of the frame
All S-VLAN tags in the frame
C-VLAN Tags
MPLS LSEs
IPv4
IPv6
All C-VLAN tags in the frame
MPLS LSEs, if any, in the frame
Frames with EtherType 0800
Frames with EtherType 86DD
Generic L3
TCP/UDP
Generic L4
Payload of a frame that is not IPv4 or IPv6, according to the EtherType
IPv4 or IPv6 frames containing UDP or TCP (according to the IP protocol type field)
Payload of IP frames that is not TCP or UDP
9.6.2.1 Preamble/L2 Header
The preamble/L2 layer consists of the LLID and L2 Ethernet header fields of the received frame. This layer also
have SNAP encapsulation.
3
1
3
0
2
9
2
8
2
7
Reserved (Unknown)
Reserved (Always 0)
L2 DA [31:0]
L2 SA [47:16]
L2 SA [15:0]
2
6
2
5
2
4
2
3
2
2
2
1
LLID Value
2
0
1
9
1
8
1
7
1
6
1
5
1
4
1
3
1
2
L2 DA [47:32]
1
1
1
0
9 8 7 6 5 4 3 2 1 0
Reserved
L2 Type Field [15:0]
Figure 7 - Preamble/L2 without SNAP
Figure 8 shows the offsets into this layer when the frame has SNAP encapsulation.
3
1
3
0
2
9
2
8
2
7
Reserved (Unknown)
Reserved (Always 0)
L2 DA [31:0]
L2 SA [47:16]
L2 SA [15:0]
DSAP [7:0]
OUI [15:0]
2
6
2
5
2
4
2
3
2
2
2
1
LLID Value
2
0
SSAP [7:0]
1
9
1
8
1
7
1
6
1
5
1
4
1
3
1
2
L2 DA [47:32]
1
1
1
0
9 8 7 6 5 4 3 2 1 0
Reserved
L2 Length Field [15:0]
CTL [7:0]
L2 Type Field [15:0]
OUI [23:16]
Figure 8 - Preamble/L2 with SNAP
26
Revised table per OAMv2.0-N-13.0062-1 on 3/13/13 by JB.
68
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
9.6.2.2
(a TPID value of 0x88E7 immediately following the SA).
3
1
3
0
2
9
2
8
2
7
Reserved (Unknown)
Reserved (Always 0)
B- DA [31:0]
B-SA [47:16]
B- SA [15:0]
Reserved (Always 0)
2
6
2
5
2
4
2
3
2
2
2
1
LLID Value
2
0
I-SID
1
9
1
8
1
7
1
6
1
5
1
4
1
3
1
2
B-DA [47:32]
I-Tag TPID
1
1
1
0
9 8 7 6 5 4 3 2 1 0
Reserved
9.6.2.3 EtherType
The EtherType layer consists only of the 16-bit EtherType value, wherever it may be located in the source frame.
format can be tested by testing the existence of the EtherType.
3
1
3
0
2
9
2
8
2
7
2
6
2
5
2
4
2
3
2
2
2
1
2
0
1
9
1
8
1
7
1
6
1
5
1
4
1
3
1
2
1
1
1
0
9 8 7 6 5 4 3 2 1 0
Reserved (Unknown) Layer 2 EtherType
Figure 10 - EtherType Layer
9.6.2.4 S-VLAN Tags
The S-VLAN tag layers consist of all S-VLAN tags identified in the frame. An S-VLAN tag is defined by the TPID
value has been defined.
3
1
3
0
TPID 0
TPID 1
TPID 2
…
2
9
2
8
2
7
2
6
2
5
2
4
2
3
2
2
2
1
2
0
1
9
1
8
1
7
1
6
1
5
PRI
PRI
PRI
1
4
1
3
1
2
1
1
1
0
C VID 0
C VID 1
C VID 2
9 8 7 6 5 4 3 2 1 0
Figure 11 - S-VLAN Layer
9.6.2.5 C-VLAN Tags
The C-VLAN tag layers consist of all C-VLAN tags identified in the frame. A "C-VLAN tag" is defined by the
if that value has been defined.
08/08/13
CableLabs
69
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
3
1
3
0
TPID 0
TPID 1
TPID 2
…
2
9
2
8
2
7
2
6
2
5
2
4
2
3
2
2
2
1
2
0
1
9
1
8
1
7
1
6
1
5
PRI
PRI
PRI
1
4
1
3
1
2
1
1
1
0
C VID 0
C VID 1
C VID 2
9 8 7 6 5 4 3 2 1 0
Figure 12 - C-VLAN Layer
9.6.2.6 MPLS LSEs
The MPLS LSEs layer consists of all MPLS LSEs identified in the frame, including the Label, Traffic Class (TC),
Bottom of the Stack (S), and Time to Live (TTL) fields present in the given MPLS LSE instance,
as defined in
3
1
3
0
Label 0
Label 1
Label 2
2
9
2
8
2
7
2
6
2
5
2
4
2
3
2
2
2
1
2
0
1
9
1
8
1
7
1
6
1
5
1
4
1
3
Figure 13 - MPLS LSEs Layer
1
2
1
1
TC 0
TC 1
TC 2
1
0
9 8 7 6 5 4 3 2 1 0
S TTL 0
S TTL 1
S TTL 2
9.6.2.7 IPv4
The IPv4 layer only exists in frames with EtherType 0x0800, and consists of the 40 bytes of standard IPv4 header, followed by any IPv4 options. Note the bit ordering in this layer is consistent with the other layers in this specification, but is the reverse of IETF documentation.
3
1
3
0
2
9
2
8
2
7
2
6
Version
Identification
Time to Live
Hdr Len
Source IP Address
Destination IP Address
IP Options (if any) …
2
5
2
4
2
3
2
2
Protocol
2
1
2
0
Type of Service
1
9
1
8
1
7
1
6
1
5
1
4
1
3
1
2
1
1
1
0
9 8 7 6 5 4 3 2 1 0
Length of datagram
Flags Fragment Offset
Header Checksum
Figure 14 - IPv4 Layer
9.6.2.8 IPv6
The IPv6 layer only exists in frames with EtherType 0x86DD, and consists of the 40 bytes of base IPv6 header, followed by extension headers. Note the bit ordering in this layer is consistent with the other layers in this specification, but is the reverse of IETF documentation.
27
Revised text and table per OAMv2.0-N-13.0062-1 on 3/13/13 by JB.
70
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
3
1
3
0
2
9
2
8
2
7
2
6
2
5
2
4
2
3
2
2
2
1
2
0
1
9
1
8
1
7
1
6
1
5
1
4
1
3
1
2
1
1
1
0
9 8 7 6 5 4 3 2 1 0
Version
Payload Length
Traffic Class
Source Address
Source Address
Source Address
Source Address
Destination Address
Destination Address
Destination Address
Destination Address
Flow Label
Next Header Hop Limit
Figure 15 - IPv6 Layer
9.6.2.9 Generic L3
The Generic L3 layer consists of all bytes after the VLAN or MPLS layers in frames that are not IP frames; that is, those frames with EtherType other than 0x0800 or 0x86DD. Rules that match custom fields in the Generic L3 layer likely need also to match the EtherType to ensure that the frame contains the expected protocol.
9.6.2.10 TCP/UDP
The TCP/UDP layer consists of the bytes of the standard TCP or UDP header, if the frame is an IP frame (v4 or v6), and if the IP Protocol type indicates UDP or TCP.
3
1
3
0
2
9
Source Port
2
8
2
7
2
6
2
5
2
4
2
3
2
2
2
1
2
0
1
9
1
8
1
7
1
6
1
5
1
4
1
3
1
2
Destination Port
1
1
1
0
9 8 7 6 5 4 3 2 1 0
Figure 16 - Layer TCP/UDP
9.6.2.11 Generic L4
The Generic L4 layer consists of all bytes after the IP header (v4 or v6) if the IP protocol type is not UDP and not
TCP. Rules that match custom fields in the Generic L4 layer likely need also to match the IP protocol type field to ensure that the frame contains the expected protocol.
9.6.3 C-VLAN TPID (0xD7/0x0503)
Objects: Network Port, User Port
This attribute represents an alternate EtherType value that is used to identify a C-VLAN tag in a frame, in addition to the standard IEEE value of 0x8100. D-ONUs with an alternate C-VLAN TPID will accept either the alternate value or 0x8100 as indicating a C-VLAN tag. C-VLAN tags added by a D-ONU are always added with the standard value of 0x8100 by default. If the "Insert This TPID" field is set to TRUE (1), then this alternate TPID will be used for all tags inserted by the D-ONU instead.
Table 128 - C-VLAN TPID
Size
2
1
Description
Alternate C-VLAN TPID
Insert This TPID
Units
-
Boolean
Default
0x8100
0
0
0
Min Max
0xFFFF
1
08/08/13
CableLabs
71
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
9.6.4 S-VLAN TPID (0xD7/0x0504)
Objects: Network Port, User Port
This attribute represents an alternate EtherType value that is used to identify an S-VLAN tag in a frame, in addition to the standard IEEE value of 0x88A8. D-ONUs with an alternate S-VLAN TPID will accept either the alternate value or 0x88A8 as indicating an S-VLAN tag. VLAN tags added by a D-ONU are always added with the standard value of 0x88A8 by default. If the "Insert This TPID" field is set to TRUE (1), then this alternate TPID will be used for all tags inserted by the D-ONU instead.
Table 129 - S-VLAN TPID
Size
2
1
Description
Alternate S-VLAN TPID
Insert This TPID
Units
Boolean
Default
0x88A8
0
0
0
Min Max
0xFFFF
1
9.6.5 IPMC Forwarding Rule Configuration (0xD7/0x0505)
Objects: D-ONU
This attribute defines the fields in a frame that are used to identify a unique IP multicast group. In some networks, the DA alone may not uniquely identify a group. Generally, as few fields as possible to preserve uniqueness are used to conserve resources.
The IPMC Multicast Control PDU is used to start and stop forwarding of a group. This attribute defines what fields are matched by the forward hardware that is altered when the IPMC Multicast Control PDU is processed.
Table 130 - IPMC Forwarding Rule Configuration
Size
2 Field Bitmap
Bit 0: LLID
Bit 1: L2 DA
Bit 2: L2 SA
Bit 3: IP DA
Bit 4: IP SA
Description Units
Bitmap 0
Default
0
Min Max
0xFFFF
If L2 fields are used, the L2 addresses are derived from the L3 IP addresses in the IP Multicast Control PDU by the standard address mapping rules for IP multicast.
9.6.6 I- TPID (0xD7/0x0506)
Objects: Network Port, User Port
This attribute represents an alternate I-TPID value that is used to identify an I-Tag in a frame, in addition to the
0x88E7 as indicating an I-Tag. I-Tags added by a D-ONU are always added with the standard value of 0x88E7 by default. If the "Insert This TPID" field is set to TRUE (1), then this alternate I-TPID will be used for all I-Tags inserted by the D-ONU instead.
Table 131 - I-TPID
Size
2
1
Description
Alternate I- TPID
Insert This TPID
Units
Boolean
Default
0x88E7
0
0
0
Min Max
0xFFFF
1
72
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
9.6.7 B-TPID (0xD7/0x0507)
Objects: Network Port, User Port
This attribute represents an alternate EtherType value that is used to identify a B-Tag in a frame, in addition to the value of 0x88A8 as defined in [802.1Q]. D-ONUs with an alternate B-TPID will accept either the alternate value or
0x88A8 as indicating a B-Tag. B-Tags added by a D-ONU are always added with the standard value of 0x88A8 by default. If the "Insert This TPID" field is set to TRUE (1), then this alternate B-TPID will be used for all B-Tags inserted by the D-ONU instead.
Table 132 - B-TPID
Size
2
1
Description
Alternate B-TPID
Insert This TPID
Units
Boolean
Default
0x88A8
0
0
0
Min Max
0xFFFF
1
9.6.8 Clear Port Ingress Rules (0xD9/0x0501)
Objects: Network Port, User Port
This action deletes all ingress frame processing rules of the current port.
9.6.9 Add Port Ingress Rule (0xD9/0x0502)
Objects: Network Port, User Port
This action adds the Port Ingress Rule, which preceded this TLV to the port in context.
9.6.10 Delete Port Ingress Rule (0xD9/0x0503)
Objects: Network Port, User Port
This action deletes the Port Ingress Rule, which preceded this TLV to the port in context.
9.7 Service Level Agreements
9.7.1 Broadcast Rate Limit (0xD7/0x0601)
Objects: User Port
This attribute represents a limit on the number of broadcast frames that can be received through the Ethernet interface. The rates refer to packet counts in a second. Once the count is exceeded, the discard result will be set for the packet at precedence 1. D-ONU rules can override the discard with a forward result at higher precedence. When set to 0xFF-FF-FF-FF, the broadcast rate filtering is disabled.
Table 133 - Broadcast Rate Limit
Size
4
Description
The maximum number of broadcast packets allowed from context user port in 1 second.
Units
packets / second
Default Min
20 0000 0
Max
0xFF-FF-
FF-FF
9.7.2 Obsolete (0xD7/0x0602)
This attribute is deprecated in DPoEv2.0.
28
Revised per OAMv2.0-12.0050-1 on 3/12/13 by JB.
08/08/13
CableLabs
73
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
9.7.3 Obsolete (0xD7/0x0603)
This attribute is deprecated in DPoEv2.0.
9.7.4 Queue Committed Information Rate (0xD7/0x0604)
Objects: Queue
This attribute represents the CIR rate for output from a queue.
Table 134 - Queue CIR
2
4
Size Description
Committed Burst Size (0 to disable)
Committed Information Rate
Units
256 Bytes
1 Kbps
9.7.5 FEC Mode (0xD7/0x0605)
0
0
Default
0
0
Min Max
0xFFFF
0xFFFF FFFF
Objects: Network Port, Logical Link
This attribute represents the current FEC mode.
For any PX type device, operating at the effective data rate of 1 Gbit/s in downstream and upstream directions, the upstream and downstream links support values as shown in Table 128, both for reading and writing.
For any PRX type device, operating at the effective data rate of 10 Gbit/s downstream and 1 Gbit/s upstream, the
downstream link supports only the value “FEC is ON” for the “The D-ONU rx/downstream FEC” attribute. On read, the ONU returns the value of “FEC is ON” for the “The D-ONU tx/upstream FEC” attribute. Any attempt to write any value other than “FEC is ON” into the “The D-ONU rx/downstream FEC” attribute is ignored.
For any PR type device, operating at the effective data rate of 10 Gbit/s in downstream and upstream directions, only the value “FEC is ON” is supported for both downstream and upstream links. On read, the ONU returns the value of
“FEC is ON” for the “The D-ONU rx/downstream FEC” attribute and the “The D-ONU tx/upstream FEC” attribute.
Any attempt to write any value other than “FEC is ON” into the “The D-ONU rx/downstream FEC” attribute and the
“The D-ONU tx/upstream FEC” attribute is ignored.
Table 135 - FEC Mode
1
Size
1
Description
The D-ONU rx/downstream FEC
0: Off – No FEC
1: On – FEC is ON
The D-ONU tx/upstream FEC
0: Off – No FEC
1: On – FEC is ON
Units
enum enum
0
Default
0
0
Min
0
1
1
Max
9.7.6 Queue Excess Information Rate (0xD7/0x0606)
Objects: Queue
This attribute represents the EIR rate for output from a queue.
29
Revised per OAMv2.0-N-12.0052-1 on 3/12/13 by JB.
74
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
2
4
Size Description
Excess Burst Size (0 to disable)
Queue EIR
Table 136 - Queue EIR
Units
256 Bytes
1 Kbps
0
0
Default
0
0
Min Max
0xFFFF
0xFFFF FFFF
9.7.7 Queue Color Marking (0xD7/0x0607)
Objects: Queue
This attribute represents the method of marking frames according to particular shaper results, usually described as
"color" values. When color marking is enabled, the field indicated in this attribute will be overwritten before frame egress with the green or yellow color value according to the rate limiter results for that frame.
Table 137 - Queue Color Marking
Size
1
1
1
1
1
1
1
Description
Enable Color Marking
Field Code
Field Instance
MSB Mask
LSB Mask
Green Value
Yellow Value
Units
Boolean
Default Min Max
0
0
0
0
0
0
0
0
0
0
0
0
0
0
1
0xFF
0xFF
0xFF
0xFF
0xFF
0xFF
9.7.8 Queue Rate Limiter Capabilities (0xD7/0x0608) R
Objects: D-ONU
This capabilities attribute describes support for the rate limiting function in the D-ONU hardware. The "Number of
Rate Limiters" fields indicates how many instances of hardware exist; that is, how many different services can be independently controlled with this feature. A value of 0 indicates the feature is not supported.
"Min Increments" for rate limits indicate the smallest multiple of the field units (256 bytes / 1Kbps) which can actually be enforced. For example, hardware that can rate limit only to multiples of 64 Kbps would have a CIR Min
Increment of 64.
"Color Aware?" indicates whether the function is sensitive to incoming color marking. "Coupling Configurable?" indicates whether the CIR+EIR coupling behavior for yellow frames can be changed. When Coupling Configurable? is FALSE, "Coupling Behavior Default" indicates the coupling behavior that is always present. "Color Marking
Support?" indicates whether the hardware can alter egress frames to show the results from the rate limiter function.
"Smart Color Drop?" indicates whether the hardware is capable of considering the color of a frame when making decisions to drop frames from a queue.
Table 138 - Queue Rate Limiter Capabilities
2
2
1
1
2
2
2
Size Description
Number of Rate Limiters
CBS Min Increment
CIR Min Increment
EBS Min Increment
EIR Min Increment
Color Aware?
Coupling Configurable?
Units
Instances
256 bytes
1K bps
256 bytes
1K bytes
Boolean
Boolean
1
1
0
0
0
1
1
Default
0
0
0
0
0
0
0
Min Max
0xFF FF
0xFF FF
0xFF FF
0xFF FF
0xFF FF
1
1
08/08/13
CableLabs
75
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
1
1
1
Size Description
Coupling Behavior Default
Color Marking Support?
Smart Color Drop?
Units
Boolean
Boolean
Boolean
0
0
0
Default
9.7.9 Coupling Flag (0xD7/0x0609)
Objects: Queue
Indicates the value of the MEF coupling flag for joint behavior of the CIR/EIR shapers.
Table 139 - Coupling Flag
1
Size
Coupling Flag
Description Units
Boolean 0
Default
0
0
0
Min
1
1
1
Max
0
Min
1
Max
9.7.10 Enable User Traffic (0xD9/0x0601)
Objects: D-ONU, Logical Link
Enable user data traffic for the object in context. If the object is Logical Link, this enables user traffic for the link only. If the object is D-ONU, traffic for all logical links is enabled. The Disable User Traffic message stops this traffic. D-ONUs boot with user data traffic disabled. If a link deregisters and then re-registers, the traffic is disabled.
9.7.11 Disable User Traffic (0xD9/0x0602)
Objects: D-ONU, Logical Link
The Disable message causes the D-ONU to disable all user data traffic for the object in context. If the object is
Logical Link, this disables user traffic for the link only. If the object is D-ONU, traffic for all logical links is disabled OAM and MPCP traffic remains intact. The Enable User Traffic message restores the user traffic. D-ONUs boot with user traffic disabled. If a link deregisters and then re-registers, the traffic is disabled.
9.7.12 Loopback Enable (0xD9/0x0603)
Objects: Logical Link, User Port
1 interface using this action.
This attribute enables MAC or PHY loopback at the specified D-ONU S
1
interface (port). Figure 17 below is an
example of Set Loopback for a D-ONU S
1
interface (port). When a D-ONU S
1
interface (port) is in loopback, packets sent upstream to the UNI port will be dropped. Packets sent downstream are looped back upstream and transmitted out the TU interface port of the D-ONU. Traffic flowing to other ports will not be affected. This
the TU interface side of the D-ONU.
76
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
ONU S
1
interface
(port) in Loop-back
OLT
EPON Port
PON
ONU
Device 1
UNI Ports
LNP Port EPON Port
Device 2
Figure 17 - Set Loopback for D-ONU S
1
Interface
Size
1
Table 140 - Loopback Enable
Description
Location (0 = PHY, 1 = MAC, 2 = TU interface link)
Units
0
Default Min Max
0 2
9.7.13 Loopback Disable (0xD9/0x0604)
Objects: Logical Link, User Port
This attribute takes the specified entity out of loopback. If the given entity is not in loopback, this message is ignored.
Table 141 - Loopback Disable
Size
1
Description
Location (0 = PHY, 1 = MAC, 2 = [802.3ah] EPON link)
Units
enum 0
Default Min Max
0 2
The procedure for initiating a loopback is to send an Enable Loopback command with the port label of the port on which the loopback is to be established. After the loopback has been set, an autonomous loopback alarm message
the value from the Get Loopback Timeout Host Interface message. If the loopback is not cleared by the Host within
the loopback has been cleared.
08/08/13
CableLabs
77
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Host Processor Host Interface Timer
Scenario 1
Enable Loopback
Enable Loopback Reply
Autonomous Alarm Message
(Loopback Alarm)
StartTimer(Timeout)
This is the value from:
Get Loopback
Timeout
StopTimer
Disable Loopback
Disable Loopback Reply
Autonomous Alarm Message
(Loopback Alarm)
Enable Loopback
Enable Loopback Reply
Autonomous Alarm Message
(Loopback Alarm)
StartTimer(Timeout)
Scenario 2
Disable Loopback
Autonomous Alarm Message
(Loopback Alarm)
Timer Expired
Figure 18 - Enable/Disable Loopback
9.7.14 Laser Tx Power Off (0xD9/0x0605)
Objects: Network Port
This attribute turns off the laser Tx for specified time for diagnostic purposes. Note that this message can also instruct a D-ONU to permanently remove itself from the network. Setting the power off time to 0 enables the laser power again, bringing an D-ONU back onto the network without waiting for an earlier timer to expire.
Table 142 - Laser Tx Power Off
Size
2
Description
Disable time
Units
Seconds -
Default Min
0
(turn laser on)
Max
0xFFFF
(disable permanently)
9.8 Clock Transport
9.8.1 Clock Transport Capabilities (0xD7/0x0701) R
Objects: User Port
timing interfaces.
30
Revised sections 9.8.1 - 9.8.5 per OAMv2.0-N-13.0074-1 on 6/17/13 by JB.
78
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
Size
1
1
1
Description
1PPS Pulse Support
TOD String Support
Table 143 - Clock Transport Capabilities
Units
Boolean
Boolean
Boolean
Default
0 (unsupported) 0
0 (unsupported) 0
0 (unsupported) 0
Min
9.8.2 Enable Clock Transport (0xD7/0x0702)
1
1
1
Max
Objects: User Port
This attribute enables the selected type of clock transport interface on the given user port on the D-ONU.
Table 144 - Clock Transport Enable
Size
1
1
1
Description
1PPS Pulse Output
TOD String Output
Units
Boolean
Boolean
Boolean
Default
0 (disabled)
0 (disabled)
0 (disabled)
0
0
0
Min
1
1
1
Max
9.8.3 Time Transfer (0xD7/0x0703)
Objects: D-ONU
synchronization event on the D-ONU, indicating a reference MPCP clock time and the ToD value when the local D-
ONU MPCP clock reaches the value carried in the ‘MPCP Reference Point’ field.
When at least one 1PPS+TOD interface is enabled on the D-ONU, this attribute sets the MPCP time for the next
1PPS pulse for the clock transport function. The value carried in the ‘MPCP Reference Point' is the time for the next
1PPS pulse. The value carried in the 'TOD String’ field represents the reference TOD value at the time of the 1PPS pulse. This value is variable length binary data, and may contain embedded NULs (ASCII 0) or other non-printable
ASCII, depending on the TOD format in use for the particular DPoE Network.
Table 145 - Time Transfer
Size Description
4 MPCP Reference Point
Varies TOD String
Units
16 ns TQ
-
-
-
Default
0
-
Min Max
0xFFFF FFFF
-
9.8.4 Propagation Parameters (0xD7/0x0704)
Objects: D-ONU
These values represent the refractive index of the fiber connected to this D-ONU in the upstream and downstream wavelengths, multiplied by the coefficient of 2
24
. (That is, there is an implied radix point after the most significant 8 bits of this value.)
Table 146 - Propagation Parameters
Size
4 ndown
Description Units
dimensionless
Default
0x01999999 0
Min Max
0xFFFF FFFF
31
Revised per OAMv2.0-12.0050-1 on 3/12/13 by JB.
08/08/13
CableLabs
79
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Size
4 nup
Description Units
dimensionless
Default
0x01999999 0
Min Max
0xFFFF FFFF
9.8.5 RTT (0xD7/0x0705)
Objects: D-ONU
This attribute represents the latest value of the round-trip time (RTT) measured by the DPoE System for the given
D-ONU, using the mechanisms defined in [802.3] for EPON.
Table 147 - RTT
Size
4 RTT
Description Units
16 ns TQ -
Default
0
Min Max
0xFFFF FFFF
9.9 DEMARC Automatic Configuration
This section contains attributes to support DEMARC devices subtended from a D-ONU.
9.9.1 DAC Configuration (0xD7/0x0800)
Objects: User Port
details) associated with the LLDP Transmit/Receive agent operating on the given UNI port, i.e., the aggregate of S-
Tag, C-Tag, I-Tag, B-Tag, and B-DA in whatever combination that needs to be relayed by the LLDP to the
DEMARC.
Table 148 - DAC configuration
4
4
6
4
6
Size Name
S-Tag
C-Tag
I-Tag
B-Tag
B-DA
Description
S-Tag value for DAC management traffic
C-Tag value for DAC management traffic
I-Tag value for DAC management traffic
B-Tag value for DAC management traffic
B-DA value for DAC management traffic
9.9.2 DAC Configuration Flags (0xD7/0x0801)
Objects: User Port
This attribute indicates which of the DAC Configuration Parameters listed in 0xD7/0x0800 are to be processed by the DAC function on the given port (corresponding bit is set to 1) or not (corresponding bit is set to 0).
80
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
1
Size Name
DAC Configuration Flags
Table 149 - DAC Configuration Flags
Description
Bit-encoded field, indicating which of the DAC Configuration Parameters listed in
0xd7/0x0800 are to be processed by DAC function on the given port (corresponding bit is set to 1) or not (corresponding bit is set to 0). The following bit encoding is defined. bit 0: S-Tag bit 1: C-Tag bit 2: I-Tag bit 3: B-Tag bit 4: B-DA bits 5-7 are reserved and set to 0.
9.9.3 DAC Password Challenge (0xD7/0x0802)
Objects: User Port
This attribute sets the password challenge for the given DAC instance, required for the operation of the DAC
The password challenge may be set for each LLDP Transmit/Receive agent operating on the given UNI port and can be modified independently of the S-Tag/C-Tag configuration parameter.
Table 150 - DAC password challenge
Size Type Name Description
Varies String password challenge string Password challenge for the secure config file download, as defined in DEMARC
9.9.4 DAC Configuration Enable / Disable (0xD7/0x0803)
Objects: User Port
This attribute is used to control the admin status of the given LLDP instance associated with the specific User Port
Object. When set to "1", the given LLDP instance is enabled, while when set to "0", the given LLDP instance is disabled. When read as "1", the given LLDP instance is currently enabled while when read as "0", the given LLDP instance is currently disabled. By default, this attribute is assigned the value of "0" upon D-ONU reboot.
Table 151 - DAC configuration Enable / Disable
Size
1
Description
LLDP instance status
Units
Boolean 0
Default
0
Min
1
Max
08/08/13
CableLabs
81
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
10 MULTICAST LLID REGISTRATION
DPoE Systems are capable of using additional multicast LLIDs other than just one global broadcast LLID (0x7FFF on 1G-EPON, 0x7FFE for 10G-EPON). This feature allows subdivision of the physical EPON into subsets, which can provide independent encryption and rate control for different services, providers, ISPs, and other such distinctions useful in a carrier-grade multiple-service network.
The broadcast LLID is a special case of a multicast LLID, which is automatically assigned to all D-ONUs on the
PON. The broadcast LLID is a well-known value used by D-ONUs for discovery, and is the default multicast LLID associated with any newly-registered unicast LLID.
Every unicast LLID is associated with exactly one multicast LLID (possibly the broadcast LLID). A multicast LLID may be associated with more than one unicast LLID.
Multicast LLIDs carry traffic only in the downstream direction. DPoE OAM related to management of a multicast
LLID is carried on one of the associated unicast LLIDs.
types; therefore, OAM messages are used for this feature instead. DPoE OAM extensions enable users to request and assign multicast LLIDs to groups of D-ONUs.
10.1 IP Multicast Control
IP multicast (IPMC) groups are a special case of multicast traffic. D-ONUs forward IPMC groups only when commanded to do so by the DPoE System using the IP Multicast Control PDU. This message contains all the information that might be used by the D-ONU to forward an IPMC group. The information actually used is defined
Table 152 - IP Multicast Control
Width
(Octets)
Field Value (hex)
1
2
16
16
1
N
Action 0: Add Ports to group forwarding list
1: Remove Ports from group forwarding list
2: Remove all ports and unregister the mLLID
Multicast LLID on which this group appears LLID
IP SA
IP DA
IP source address for group. IPv4 addresses are aligned in the four least significant bytes.
IP destination address for group. IP v4 addresses are aligned in the four least significant bytes.
Number of Ports Number of UNI Port instance numbers that follow
Port List of port instance numbers to be added or removed to this IPMC group
10.2 IP Multicast Control Response
This message acknowledges receipt and processing of an IP Multicast Control Request message by the D-ONU.
Table 153 - IP Multicast Control Response
Width (Octets)
1
Field
Result Code 0: No error
1: Failed
Value (hex)
82
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
10.3 Multicast Registration
The multicast registration message associates a multicast LLID with a unicast LLID assigned by the standard MPCP registration process. The default multicast LLID for a unicast link is 0x7FFF or 0x7FFE (the standard broadcast
LLID as appropriate for the downstream speed at which the D-ONU is registered, 1G or 10G, respectively).
Table 154 - Multicast Registration
Width (Octets)
1
2
Field
Flags
Multicast LLID value
Value (hex)
Varies; e.g., 0x7FFF for 1G broadcast, or a value chosen by the DPoE System for a multicast LLID.
As previously assigned to the D-ONU 2 Unicast LLID value
Flags values are the same as for the standard REGISTER MPCPDU and REGISTER ACK MPCPDU.
Table 155 - Multicast Registration Flags
1
2
3
4
Value (hex) Meaning
(Re)Register
Deallocate
Success
Nack
10.4 Multicast Response
The Multicast Response PDU is returned by the D-ONU to acknowledge receipt of the Multicast Registration PDU.
Table 156 - Multicast Response
Width (Octets)
1
2
Field
Flags
Multicast LLID value
2 Unicast LLID value
Value (hex)
Varies; e.g., 7FFF for broadcast or a value chosen by the DPoE System for a multicast LLID.
As previous assigned to the D-ONU
08/08/13
CableLabs
83
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
11 SECURITY
related to security and authentication.
11.1 Key Exchange
DPoE OAM extensions include a key exchange protocol. This can be used to synchronize keys between the DPoE
System and D-ONU. The Key Exchange PDU begins with a subtype code to distinguish PDU types used in the key exchange protocol.
The Key Assignment PDU is used to transmit a key value to the network peer.
Table 157 - Key Assignment
1
2
Width (Octets)
1
1
Varies
Field
Key Exchange Subtype
LLID
Key Number
Key Length
Key
Value (hex)
0: Key Assignment
LLID value, as in frame preamble, for the logical link to which this message applies
0..1; indicates key phase
Number of bytes of key data (16 for 128-bit AES)
Random data equal to Length bytes. The first byte is the most significant byte of key data.
The Key Assignment Acknowledgement PDU is sent in some applications of the protocol after a Key Assignment
PDU is received.
Table 158 - Key Assignment Ack
1
2
Width (Octets)
1
Field
Key Exchange Subtype
LLID
Key Number
Value (hex)
1: Key Assignment Acknowledgement
LLID value, as in frame preamble, for the logical link to which this message applies
0..1; indicates key phase
84
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
12 FILE TRANSFER
DPoE extensions enable D-ONUs to download new firmware upgrades and other files from the DPoE System using a simple file transfer protocol.
of IP. This protocol differs from TFTP in the following ways:
• It includes support for only one data encoding option (binary).
• It supports variable sized frames, to suit the negotiated length of the Ethernet OAM frame and take advantage of the longer MTU.
• It acknowledges next block to receive rather than last block received, to avoid the Sorcerer's Apprentice problem without extra timers.
• It replaces the file pathname string with a numeric file type identifier.
To maximize interoperability, the contents of D-ONU files are considered to be opaque to the DPoE System and management system. There is intentionally no standardized header that all D-ONU models must support. An EMS might well add headers to binary files for D-ONUs for its own purposes of storage and tracking, but these headers would be removed before sending the data to the D-ONU. Conversely, any information which a particular D-ONU needs for its own purposes for storage and validation must be included in the D-ONU file; the exact format of this data is up to the D-ONU vendor so long as the file format meets the requirements of this section. The DPoE System does not parse into the contents of files for the D-ONU, but only acts as a gateway to transfer the files.
12.1 File Transfer PDU Header
File Transfer PDUs have a common header, shown below.
Table 159 - File Transfer PDU Header
6
Width (Octets)
1
3
1
6
2
1
2
1 varies
Ethernet DA
Field
Ethernet SA
Ethernet Type
Subtype
Flags
Opcode
OUI
DPoE Opcode
File Transfer Opcode
File Transfer PDU body
Value (hex)
0x01:80:C2:00:00:02
([802.3] OAM multicast address)
As per sending MAC
0x8809 (Ethernet Slow Protocol)
FE (Vendor extended)
0x001000 (DPoE EPON)
0x09 (File Transfer)
As per each PDU type, defined below
Table 160 - File Transfer PDU Opcodes
Value (hex) File Transfer PDU Opcode
Reserved
Write Request
File Transfer Data
File Transfer Ack
0x0
0x1
0x2
0x3
08/08/13
CableLabs
85
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
12.1.1 File Transfer Write Request
The File Transfer Write Request OAM PDUs indicates a request to initiate a file transfer from the DPoE System to the D-ONU, including the target DPoE ONU firmware file name, transferred in the format of a null-terminated
ASCII string.. The recipient prepares to receive a file.
The response to a File Transfer Request is a File Transfer Ack message. The error code of the Ack is either zero
(Ok), allowing the transfer to proceed, or non-zero, indicating the reason that the transfer cannot take place.
Table 161 - File Transfer Write Request
Width (Octets)
varies
Field
OSS Filename
Value (hex)
Null-terminated ASCII string
12.1.2 File Transfer Data
File Transfer Data PDUs contain the data for the current file. Each PDU carries a sequence number and size field, specifying the number of file data bytes to follow. Data PDUs are sent one block at a time in sequential order. Each block is acknowledged by the recipient before the next block is sent. (This is a "stop and wait" protocol.) The first block of a file has sequence number 0.
The response to a Transfer Request is a File Transfer Ack message. The error code of the Ack is either zero (Ok), allowing the transfer to proceed, or non-zero, indicating the reason that the transfer was aborted. The Ack also contains the block number of the next block the recipient expects to receive.
Once the file transfer begins, at least one Data PDU must be sent every second. If the recipient fails to receive a
Data PDU every second, a timeout is counted and the recipient sends a File Transfer Ack. This message contains the timeout error code and the sequence number indicating the desired block. Three successive timeouts will abort the file transfer process. In this case, the file on the recipient is unchanged.
A Data PDU may be sent with a size of zero. This resets the block reception timer on the recipient to prevent a timeout. It does not advance the block sequence number or the state of the received file. This feature can be used to keep a transfer alive in the event of an unanticipated delay at the sender.
Table 162 - File Transfer Data
Width (Octets)
2
2
(Size)
Field
Block Number
Block Width (Octets)
File data
Value (hex)
Increments
Varies
Varies
12.1.3 File Transfer Ack
The Acknowledgement PDUs contain a sequence number and an error code. The sequence number is the number of the next block expected by the recipient. The error code indicates the status of the transfer. A non-zero error code aborts the file transfer and leaves the files on the recipient unchanged.
To signal the end of a file transfer, the sender sends an Ack PDU. This PDU contains sequence number 0 and a code indicating the status of the transfer. (The transfer status indicated is assessed by the sender, not the recipient.) A zero status instructs the recipient to commit the file to permanent storage. A non-zero status instructs the recipient to discard the file, even if the transfer appears successful to the recipient. This Ack is the only Ack sent by the sender in this protocol.
32
Revised per OAMv2.0-N-12.0056-1on 3/12/13 by JB.
86
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
The final Ack from the sender is acknowledged by a final Ack from the recipient. The recipient sends the Ack after it has committed the file or discarded it. Committing a file to flash requires more time than processing a single data frame. Therefore, the timeout for the final Ack response from the recipient should be at least 15 seconds.
Table 163 - File Transfer Ack
2
1
Width (Octets) Field
Block Number
Response Code
Value (hex)
Increments
As per File Acknowledgement Response Code table, below
Table 164 - File Acknowledgement Response Code
Ack Response Code
OK
Undefined
Not Found
No Access
Full
Illegal Operation
Unknown ID
Bad Block
Timeout
Busy
Incompatible File
Corrupted File
Meaning
No errors
Unknown error, or one not covered elsewhere
Read requested file that is not available
Access permissions do not allow the requested read/write
Storage is full, and cannot hold the written file
Cannot perform requested operation in current state
Requested file ID is not supported by this device
Block received in error
No block received before timer expiration
Cannot perform requested action due to other activity
Received file is incompatible with this device. File incompatibility is determined by the device vendor.
File was received corrupted and is unusable by this device. File integrity is determined by the device vendor.
0xB
Value (hex)
0x0
0x1
0x2
0x3
0x4
0x5
0x6
0x7
0x8
0x9
0xA
08/08/13
CableLabs
87
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Appendix I Branch/Leaf Code Reference (Informative)
I.1
[802.3] Clause 30 Attributes (Branch 0x07)
and DPoE attributes.
Table 165 - [802.3] Clause 30 Attributes (Branch 07)
Leaf (HEX)
MAC
0x00 01
0x00 02
0x00 03
0x00 04
0x00 05
0x00 06
0x00 07
0x00 08
0x00 09
0x00 0A
0x00 0B
0x00 0C
0x00 0E
0x00 0F
0x00 12
0x00 13
0x00 14
0x00 15
0x00 16
0x00 17
Attribute Read/ Write
MAC ID
Frames Tx OK
Single Collision Frames
Multiple Collision Frames
Frames Rx OK
FCS Err
Alignment Error
Octets Tx OK
Frames Deferred
Late Collisions
Excessive Collisions
Lost MAC Tx Err
Octets Rx OK R
Frames Lost MAC Rx Error R
Multicast Frames Tx
Broadcast Frames Tx
R
R
R
R
R
Frames Excessive Deferral R
Multicast Frames Rx R
Broadcast Frames Rx
In Range Length Error
R
R
R
R
R
R
R
R
R
R
R
Description
ID for this MAC in this device
Frames transmitted
Frames suffering a single collision
Frames suffering multiple collisions
Frames received with no errors
Frames received with FCS errors
Alignment errors
Octets transmitted in frames with no errors
Deferred due to collisions
Collisions after frame in progress
Frames dropped due to too many collisions
Frames lost due to MAC transmission error
Octets received in good frames
Frames lost due to MAC receive error
Frames transmitted with a multicast address
Frames transmitted with a broadcast address
Frames dropped due to too many backoff retries
Frames received with multicast address
Frames received with broadcast address
[802.3] format frames received with actual length not equal to
length field
Frames received out of allowed length (short or long)
Frames received longer than the maximum permitted
Port enabled or disabled
MAC Address of the port
Number of collisions detected by MAC
0x00 18
0x00 19
0x00 1A
0x00 1D
0x00 1E
PHY
Out of Range Length Error
Frame Too Long
MAC Enable Status
MAC Address
MAC Collision Frames
0x00 20
0x00 23
PHY Type
PHY Symbol Err During
Carrier
PHY Admin State 0x00 25
MAU
0x00 47
Auto-negotiation
MAU Media Available
0x00 4E Auto Neg ID
0x00 4F
0x00 50
Auto Neg Admin State
Auto Neg Remote Signal
R
R
R/W
R
R
R
R
R/W
R
R
R/W
R
Type of PHY for this port
Transmission errors detected
PHY enabled or disabled
88
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
Leaf (HEX)
0x00 51
0x00 52
0x00 53
0x00 54
0x00 55
0x00 56
0x00 57
MAC
Attribute Read/ Write
Auto Neg Config R
Auto Neg Local Tech R/W
Auto Neg Advertised Tech R/W
Auto Neg Rx Tech R
Auto Neg Local Select
Auto Neg Advert Select
Auto Neg Rx Select
R
R
R
0x00 5A
MAC Control
0x00 5D
Duplex Status
MAC Ctrl Functions
Supported
MAC Ctrl Frames Tx 0x00 5E
0x00 5F
0x00 60
MAC Ctrl Frames Rx
MAC Ctrl Unsupported Op
Rx
MAC Ctrl Pause Delay 0x00 61
0x00 62 MAC Ctrl Pause Tx
0x00 63
OMP Emulation
MAC Ctrl Pause Rx
0x01 18
0x01 19
0x01 20
0x01 22
MPCP Frames Tx
MPCP Frames Rx
MPCP Tx Discovery
MPCP Disc Timeout
0x01 43
0x01 44
R/W
R
R
R
R
R
R
R
FEC
0x01 24
0x01 25
0x01 39
0x01 3A
FEC Corrected Blocks R
FEC Uncorrectable Blocks R
FEC Ability
FEC Mode
OMP Emulation
0x01 3B MPCP Tx Gate
R/W
R/W
0x01 3C
0x01 3D
0x01 3E
0x01 3F
0x01 40
MPCP Tx Reg Ack
MPCP Tx Register
MPCP Tx Reg Req
MPCP Tx Report
MPCP Rx Gate
R
R
R
R
R
R
0x01 41
0x01 42
MPCP Rx Reg Ack
MPCP Rx Register
MPCP Rx Reg Req
MPCP Rx Report
R
R
R
R
R
R
R
R
Description
I.2 DPoE Attributes (Branch 0xD7)
D7 attribute details.
08/08/13
CableLabs
89
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
I.3
[802.3] Clause 30 Actions (Branch 09) (Informative)
These actions are defined in [802.3] Clause 30, and are repeated here for ease of reference.
Table 166 - [802.3] Clause 30 Actions (Branch 09)
0x00 05
0x00 0B
0x00 0C
Leaf (HEX) Attribute
PHY Admin Control
Auto Neg Renegotiate
Auto Neg Admin Ctrl
Description
Enable/disable PHY
Force renegotiation
Auto Neg enable/disable
I.4 DPoE Actions (Branch 0xD9)
An action is identified by a Variable Container. Action parameters, if any, are included in the data portion of the container in the Set Request OAM PDU. Actions with no parameters have a zero length Container (Width code
0x80).
Responses to an action in the Set Response OAM PDU similarly have a list of Containers. Typically the response is just the result code (0x80, No Error, or a failure code). A response could return a result in the data portion of the container.
See Sections 9.7.6 through 9.7.14 for DPoE OAM PDUs for Branch D9.
90
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
Appendix II Example PDUs (Informative)
This informative-only appendix shows examples of DPoE OAM PDUs to illustrate the format and usage of these messages.
II.1 Get and Get Response
This example shows the use of the Object ID in a complex Get message that requests attributes from several objects.
The Get message received from the DPoE System is shown on the left, with the corresponding D-ONU response on the right. The frame begins with some attribute TLVs (branch 7, D7), both standard and DPoE, without an object context. These attributes by definition refer to the default object, which is the EPON port and logical link on which the message was received. The D-ONU responds to an Object ID simply by echoing the TLV back in the Get
Response. For each Variable Descriptor in the Get message, the D-ONU creates a matching Variable Container.
Note that there is one response indicating an error code. All errors designate a length of 0 bytes, so there is no data
the message; it is not padding.
Get Get Response
08/08/13
DA
SA
Length/Type
Subtype
Flags
FE
00-10-00
01
07
D7
D7
...
Leaf
Leaf
Leaf
D6
07
D7
D7
...
Leaf
Leaf
Leaf
Leaf
Len
D6
07
D7
D7
Leaf
Leaf
Leaf
Leaf
Len
00
00 00
(Pad)
FCS
DA
SA
Length/Type
Subtype
Flags
FE
00-10-00
02
07
D7
D7
...
Leaf
Leaf
Leaf
Len
Len
Len
Object ID
Object ID
D6
07
D7
D7
...
Leaf
Leaf
Leaf
Leaf
Len
Len
Len
Len
D6
07
D7
D7
Leaf
Leaf
Leaf
Leaf
Len
Len
Len
Err
00
00 00
(Pad)
FCS
Figure 19 - Get and Get Response
Data
Data
Data
Object ID
Data
Data
Data
Object ID
Data
Data
CableLabs
91
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
II.2 Set and Set Response
This example shows a Set message, including a change in Object ID. Note that both standard and extended attributes can be set in a single message. Set messages have Variable Containers rather than Descriptors in the Get, because to set an attribute, you must specify both the attribute and its new value. The response to a Set is a TLV with a return code (usually RcOk, but perhaps an error) indicating zero data. Actions (branch codes 0x09, 0xD9) can also be included in a set message. Actions often have parameters (ex: Add MAC address (M1)), so they are also Variable
Containers. For consistency in parsing, even actions with no parameters, such as D-ONU Reset, use the Variable
Container format with a length of zero.
Set Set Response
DA
SA
Length/Type
Subtype
Flags
FE
00-10-00
03
07
D7
D7
...
Leaf
Leaf
Leaf
Len
Len
Len
09
D9
D9
...
D6
07
D7
Leaf
Leaf
Leaf
Leaf
Leaf
Leaf
Len
Len
Len
Len
Len
0x80
00 00 00
(Pad)
FCS
Data
Data
Data
Object ID
Data
Data
Data
Data
DA
SA
Length/Type
Subtype
Flags
FE
00-10-00
04
07
D7
D7
...
Leaf
Leaf
Leaf
Ok
Ok
Ok
09
D9
D9
...
D6
07
D7
Leaf
Leaf
Leaf
Leaf
Leaf
Leaf
Ok
Err
Ok
Len
Ok
Ok
00 00 00
(Pad)
FCS
Figure 20 - Set and Set Response
Object ID
92
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
II.3 Large Attribute Values
This example illustrates the format for a large return value, in this case the MAC address table for a particular UNI port. The Get Request PDU contains a single attribute, but the reply is larger than 128 bytes, and so requires several containers for the response.
Get Get Response
DA
SA
Length/Type
Subtype
Flags
FE
00-10-00
01
D6
D7
00 06
01 03
01 00
DA
SA
Length/Type
Subtype
Flags
FE
00-10-00
02
D6
D7
D7
D7
00 06
01 03
01 03
01 03
01
126
12
0x80
00
MAC addr 1..21
MAC addr 22..23
00
00 00
00
00 00
(Pad)
FCS
(Pad)
FCS
Figure 21 - Large Attribute Values
II.4 Multi-Part Replies
The following diagram illustrates the use of the sequence number attribute in a two-part reply to a single Get PDU.
For the sake of example, the reply is assumed to be a single attribute, an extremely large MAC address table, as in the previous example. A multi-part reply also might be generated in response to a long list of small attributes.
Note that the large attribute is not terminated in the first frame as it is not yet complete, but is terminated only in the second frame.
08/08/13
CableLabs
93
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
94
Get
DA
SA
Length/Type
Subtype
Flags
FE
00-10-00
01
D6
D7
00 06
01 03
00 00 00
(Pad)
FCS
01 00
Get Response
DA
SA
Length/Type
Subtype
Flags
FE
00-10-00
02
Response Frame
D6
D7
. . .
D7
00 06
01 03
01 03
01
126
D7
00
(Pad)
FCS
00 01
00 00
126
2
1 of 2
00
MAC addr 1..21
MAC addr N..N+20
00 00
DA
SA
Length/Type
Subtype
Flags
FE
00-10-00
02
Response Frame
2 of 2
D7
00
D6
D7
D7
D7
Figure 22 - Multi-Part Replies
(Pad)
FCS
00 00
00 06
01 03
01 03
01 03
01
126
12
0x80
00 01 2
00
MAC addr N+21..N+42
MAC addr N+43..N+44
80 01
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
II.5 Encryption and Key Exchange Messages
This PDU is used to set the key exchange interval on the D-ONU.
1
2
1
22
1
1
?
6
?
1
DPoE OAM Header
Opcode 3 (Set)
Branch D6 (Object)
Leaf 2 (Link)
Width 1
Link Index
Variable Containers
Key Expiry Time
Variable Containers
0 (terminator)
List of variable containers
Object Context (Optional)
1
2
1
2
Branch D7 (DPoE)
Leaf 05 01
Width 2
Timeout Value (seconds)
Figure 23 - Set Key Exchange Timer Request PDU
+ Ethernet Frame
DA................01 80 c2 00 00 02
SA................54 4b 37 21 00 00
EtherType.........88 09 (Slow Protocol)
SubType...........03 (OAM)
+ OAM PDU
Flags...........00 10
Code............fe (Organization Specific)
OUI.............00 10 00 (DPoE)
+ DPoE PDU
OpCode........03 (Set)
+ TLV
Branch......d6 (Object Context)
Leaf........00 02 (LLID)
Width.......02
Value.......00 00 (LLID Index 0)
+ TLV
Branch......d7 (DPoE attribute)
Leaf........05 01 (Encryption Key Expiry Time)
Width.......02
Value.......00 3c (60 seconds)
+ TLV
Branch......00 (Branch null (terminator))
Leaf........00 00 (Leaf null (terminator))
+ PAD
+ FCS
08/08/13
CableLabs
95
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
II.5.1 Set Key Exchange Timer Response PDU
This PDU is returned to inform the DPoE System if the D-ONU was successfully configured (or not successfully configured) with the Key Exchange Timer value specified in a Set Request Message.
?
6
1
1
22
1
1
2
?
1
DPoE OAM Header
Opcode 4 (Set Response)
Branch D6 (Object)
Leaf 2 (Link)
Width 1
Link Index
Variable Containers
Key Expiry Time
Variable Containers
0 (terminator)
List of variable containers
Object Context (Optional)
1
2
1
Branch D7 (DPoE)
Leaf 05 01
0x80 (No Error)
Figure 24 - Set Key Exchange Timer Response PDU
+ Ethernet Frame
DA................01 80 c2 00 00 02
SA................54 4b 37 01 00 ab
EtherType.........88 09
SubType...........03 (OAM)
+ OAM PDU
Flags...........00 50
Code............fe (Organization Specific)
OUI.............00 10 00 (DPoE)
+ DPoE PDU
OpCode........04(Set Response)
+ TLV
Branch......d6 (Object)
Leaf........00 02 (LLID)
Width.......02
Value......00 00 (LLID Index)
+ TLV
Branch......d7 (DPoE Attribute)
Leaf........05 01 (Encryption Key Expiry Time)
Width/Code..80 (No Error)
+ TLV
Branch......00 (Branch null (terminator))
Leaf........00 00 (Leaf terminator)
+ PAD
+ FCS
96
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
II.5.2 Get Key Exchange Timer PDU
This PDU may be used by the DPoE System to query the D-ONU to determine the currently specified Key
Exchange Timer value used by one of the D-ONU's links.
2
1
1
22
1
1
?
1
?
6
DPoE OAM Header
Opcode 1 (Get)
Branch D6 (Object)
Leaf 2 (Link)
Width 1
Link Index
Variable Descriptors
Key Expiry Time
Variable Descriptors
0 (terminator)
List of variable descriptors
Object Context (Optional)
1
2
Branch D7 (DPoE)
Leaf 05 01
Figure 25 - Get Key Exchange Timer PDU
+ Ethernet Frame
DA................01 80 c2 00 00 02
SA................54 4b 37 21 00 00
EtherType.........88 09 (Slow Protocol)
SubType...........03 (OAM)
+ OAM PDU
Flags...........00 10
Code............fe (Organization Specific)
OUI.............00 10 00 (DPoE)
+ DPoE PDU
OpCode........01 (Get)
+ TLV
Branch......d6 (Object Context)
Leaf........00 02 (Link)
Width.......02
Value......00 00 (LLID Index 0)
+ TLV
Branch......d7 (DPoE Attribute)
Leaf........05 01 (Key Exchange Expiry Time)
+ TLV
Branch......00 (Branch null (terminator))
+ PAD
+ FCS
08/08/13
CableLabs
97
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
II.5.3 Get Key Exchange Timer Response PDU
All D-ONU implementations respond either with the provisioned Key Exchange Timer Value or an appropriate error
Container Value if queried by the DPoE System.
1
?
6
?
1
22
1
1
2
1
DPoE OAM Header
Opcode 2 (Get Response)
Branch D6 (Object)
Leaf 2 (Link)
Width 1
Link Index
Variable Containers
Key Expiry Time
Variable Containers
0 (terminator)
List of variable descriptors
Object Context (Optional)
1
2
1
2
Branch D7 (DPoE)
Leaf 05 01
Width 2
Timeout Value
Figure 26 - Get Key Exchange Timer Response PDU
+ Ethernet Frame
DA................01 80 c2 00 00 02
SA................54 4b 37 01 00 ab
SubType...........88 09 (Slow Protocol)
Flags.............03 (OAM)
+ OAM PDU
Flags...........00 50
Code............fe (Organization Specific)
OUI.............00 10 00 (DPoE)
+ DPoE PDU
OpCode........02 (Get Response)
+ TLV
Branch......d6 (Object Context)
Leaf........00 02 (Link)
Length......02
Value......00 00 (LLID Index 0)
+ TLV
Branch......d7 (DPoE attribute)
Leaf........05 01 (Key Exchange Expiry Timer)
Width.......02
Value.......00 3c
+ TLV
Branch......00 (Branch null (terminator))
+ PAD
+ FCS
98
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
II.6 Key Exchange Message
This message is example showing the key value being the D-ONU to DPoE System.
+ Ethernet Frame
DA................01 80 c2 00 00 02
SA................54 4b 37 01 00 ab
EtherType.........88 09 (Slow Protocol)
SubType...........03 (OAM)
+ OAM PDU
Flags...........00 50
Code............fe (Organization Specific)
OUI.............00 10 00 (DPoE)
+ DPoE PDU
OpCode........08 (Key Exchange)
KeyNumber.....00
KeySize.......10
Key...........04 b9 98 48 04 a2 72 41
d1 a0 5a 36 67 db 85 66
+ PAD
+ FCS
II.7 Example 1Down Key Exchange Sequence
Set Key Exchange Timer (60 seconds)
---------------------------
01 80 c2 00 00 02 54 4b 37 21 00 00 88 09 03 00
10 fe 00 10 00 03 d7 05 01 02 00 3c 00 00 00 ...
Set Key Exchange Timer Response
-------------------------------
01 80 c2 00 00 02 54 4b 37 01 00 ab 88 09 03 00
50 fe 00 10 00 04 d7 05 01 80 00 00 ...
Get Key Exchange Timer
----------------------
01 80 c2 00 00 02 54 4b 37 21 00 00 88 09 03 00
10 fe 00 10 00 01 d7 05 01 00 00 00 ...
Get Key Exchange Timer Response
-------------------------------
01 80 c2 00 00 02 54 4b 37 01 00 ab 88 09 03 00
50 fe 00 10 00 02 d7 05 01 02 00 3c 00 00 ...
Key Exchange Message
--------------------
01 80 c2 00 00 02 54 4b 37 01 00 ab 88 09 03 00
50 fe 00 00 10 00 01 10 ad b5 01 ab cc a8 12 68 eb 94 35 7d ec 08 3c 65 00 00 00 ...
Key Exchange Message
--------------------
01 80 c2 00 00 02 54 4b 37 01 00 ab 88 09 03 00
50 fe 00 10 00 08 00 10 94 cb 49 59 38 d1 5b a3 d2 7d e6 ca fd 00 9f 1f 00 00 00 ...
08/08/13
CableLabs
99
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Key Exchange Message
--------------------
01 80 c2 00 00 02 54 4b 37 01 00 ab 88 09 03 00
50 fe 00 10 00 08 01 10 80 52 4c cc 21 9d 08 ea
4e 18 f5 fb 24 48 79 d6 00 00 ...
02
01
01
02
II.8 LLID and Queue Configuration TLV
The following example shows the contents of a Link and Queue Configuration TLV that configures two links and two UNI ports as follows
• Upstream Configuration: N (number of links) = 2
• LLID 0 configuration: [M=2, (Queue 0 Size=10, Queue 1 size=10)]
• LLID 1 configuration: [M=1, (Queue 0 Size = 5)]}
• Downstream Configuration: P (number of ports) = 2
• Port 0 (i.e., UNI port 1) configuration: [J=2, (Queue 0 Size=5, Queue 1 Size=5)]
• Port 1 (i.e., UNI port 2) configuration: [J=1, (Queue 0 Size=8)]
D7 01 0D 0C
02
02
; branch/leaf for LLID/Queue Config TLV; length 12 bytes
; 2 LLIDs
; LIID 0 has 2 queues
05
05
05
0A
0A
08
; LLID 0 queue 0 is size 40 KB
; LLID 0 queue 1 is size 40 KB
; LLID 1 has 1 queue
; LLID 1 queue 0 is size 20 KB
; 2 User Ports
; Port 0 has 2 queues
; Port 0 queue 0 is size 20 KB
; Port 0 queue 1 is size 20 KB
; Port 1 has 1 queue
; Port 1 queue 0 is size 32 KB
100
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
Appendix III Life Cycle of a Logical Link (Informative)
The diagram below illustrates some events in the OAM sequence for a "typical" logical link. As a merely informative example, this diagram does not require a particular order of operation or set of messages. Any such
only.
OLT ONU
MPCP Discovery Gate
Register Request
Register
Register Ack
MPCP Registration
Info (DPOE TLV)
Info (DPOE TLV)
Info (DPOE TLV)
Info (DPOE TLV)
Set (Encryption Mode, Key Exchange Timer)
Response
EAP-TLS Request
EAP-TLS Response
Get ONU Info
Response
Set (FEC)
Response
Set Report Thresholds
Response
Set (ONU Config)
Response
Set (Up/Down Classification, Filter Rules)
Response
Get (Statistics)
Response
Event Notification
Set (ACL Rule)
Response
Set (Multicast Forwarding Entry)
Response
OAM Discovery
Establish Security
Provision Basic Link
Properties
Provision Config
Based on Services
In Service
Operations
08/08/13
MPCP Register (Deregister)
OAM Event Notification (Dying Gasp)
MPCP Register (Deregister)
Figure 27 - Logical Link Life Cycle
Deregistration
CableLabs
101
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
III.1 MPCP Registration
Clause 77. Range to the D-ONU and MAC address of the logical link are first available at this point.
III.2 OAM Discovery
Support for this extension is indicated by including a DPoE Info TLV in each Info PDU during discovery. As the active device, the DPoE System always transmits the first OAM PDU. The D-ONU begins transmitting its own Info
PDUs once it receives a PDU from the DPoE System. (Note that the ONU PDU is not strictly a response to the
DPoE System; these PDUs are sent based on a local timer, but that timer does not start until the first PDU arrives
the in-service state. It would be unusual for more than two PDUs to be required, as there is not a lot of negotiation to be carried out in this step.
III.3 Establish Discovery
It is desirable to establish encryption and authenticate the newly-discovered D-ONU as soon as possible, and before user data traffic is allowed to pass the D-ONU. These processes are carried out as defined by the DPoE specifications. Other OAM should be postponed until encryption has been established and the D-ONU has been authenticated.
III.4 Provision Basic Link Properties
The D-ONU ID and capabilities for the newly-discovered link would normally be queried early in the lifetime of a link. Any basic link properties necessary to operate the link might be provisioned first. For example, FEC for the link might be enabled.
III.5 Provision Configuration Based on Services
Once the identity of the D-ONU has been established and the link has been configured, the DPoE System can consult its database and configure the D-ONU as required to support the services authorized for this user.
Commands might be sent to the D-ONU to establish its basic configuration (number of logical links, queues, and classification scheme); MPCP report thresholds would be established as appropriate for the SLA for the logical link; filter rules for the link might be established.
The first link registered from a physical D-ONU is likely to see more activity than others, as the DPoE System would provision configuration global to the entire D-ONU on this link, but not repeat that provisioning for later links.
III.6 In Service Operations
Periodic activity can be expected on a logical link once it is in service and basic provisioning has been established.
For example, statistics might be regularly polled on the D-ONU by periodically sending a Get PDU requesting statistics attributes of various objects of interest. Some alteration in the provisioning of the D-ONU may occur based on events that occur after the D-ONU has registered. For example, DHCP snooping might learn an IP address assigned to a user device; in response, the DPoE System provisions an anti-spoofing ACL rule on the D-ONU to match that particular MAC/IP combination. Systems with remote-controlled multicast forwarding (as opposed to local D-ONU forwarding based on IGMP or MLD snooping) might send commands to add and remove multicast forwarding entries to the D-ONU as required. The D-ONU might autonomously report events to the DPoE System, particularly indications of faults.
III.7 Link Deregistration
The logical link will typically disappear when it is deregistered by management command, for example when a user unsubscribed from a service and that logical link is no longer needed, or if the D-ONU is powered off.
102
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
Appendix IV Example Rules (Informative)
This section shows some example rule sets to accomplish particular actions on a frame.
IV.1 Field Masking Example
Some field codes have sub-fields that are of interest. For example, an S-Tag has TPID, PCP, DEI, and VID fields.
Rather than assign every sub-field a unique code for identification, the OAM message allows a number of bits on both the most significant ("left)" side of the field and the least significant ("right") side to be ignored for purposes of
the sake of notation in the following example and figures, a sub-field identifier will be written with the format
{Field Code, Instance, MSB, LSB}.
As an example, to specify the TPID sub-field of an S-Tag in a PB frame, the sub-field identifier is {0x07,0,0,16}:
0x07 (identifies an S-VLAN field, per Table 91)
0 refers to the instance of the S-Tag in the frame
0 refers to the MSB mask (ignore no bits on the left side)
16 refers to and the LSB mask (ignore all bits of the VID, DEI, and PCP fields).
Similarly, to select just the PCP field of an S-Tag in a PB frame, the sub-field identifier is {0x07,0,16,13}:
0x07 (identifies an S-VLAN field, per Table 91)
0 refers to the instance of the S-Tag in the frame
16 refers to the MSB mask (ignore the 16 MSB -- the TPID)
13 refers to the LSB mask (ignore the VID and DEI).
The following figures depict the sub-field identifiers for OAM messages using the format described above.
Figure 28 depicts the sub-field identifiers used for an untagged Ethernet frame.
48 bits
DA
48 bits
SA
16 bits
0x0800 Payload
DestMacAddr
TLV 22.10.1
Link OAM
{0x01,0,0,0}
To match full MAC
SourceMacAddr
TLV 22.10.2
Link OAM
{0x02,0,0,0}
To match full
MAC
ProtocolType
TLV 22.10.3
Link OAM
{0x03,0,0,0}
To match full Type
Figure 28 - Field Masking Example for Untagged Frame
08/08/13
CableLabs
103
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Type fields are able to be identified within the 802.1Q C-tagged frame, in addition to the fields in the tag.
32 bits
C-VLAN Tag
48 bits
DA
48 bits
SA
16 bits
C-TCI
Link OAM
{0x08,0,16,0}
16 bits 3 bits 1 bit 12 bits 16 bits
0x8100 PCP CFI VID 0x0800 Payload
DestMacAddr
TLV 22.10.1
Link OAM
{0x01,0,0,0}
To match full MAC
SourceMacAddr
TLV 22.10.2
C-PCP
Link OAM
{0x08,0,16,13}
Link OAM
{0x02,0,0,0}
To match full MAC
802.1ad
C-VLAN TPID
TLV 22.14.5
Link OAM
{0x08,0,0,16}
802.1ad
C-VLAN VID
TLV 22.14.6
Link OAM
{0x08,0,20,0}
C-CFI
Link OAM
{0x08,0,19,12}
ProtocolType
TLV 22.10.3
Link OAM
{0x03,0,0,0}
To match full Type
Figure 29 - Field Masking Example for 802.1Q C-tagged Frame
104
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
and Protocol Type fields are able to be identified within the 802.1ad tagged frame, in addition to the S-Tag and C-
Tag fields.
32 bits
S-VLAN Tag
32 bits
C-VLAN Tag
16 bits
S-TCI
Link OAM
{0x07,0,16,0}
16 bits
C-TCI
Link OAM
{0x08,0,16,0}
48 bits
C-DA
48 bits
C-SA
16 bits 3 bits 1 bit 12 bits 16 bits 3 bits 1 bit 12 bits 16 bits
0x88a8 PCP DEI VID 0x8100 PCP CFI VID 0x0800 Payload
DestMacAddr
TLV 22.10.1
Link OAM
{0x01,0,0,0}
To match full MAC
SourceMacAddr
TLV 22.10.2
Link OAM
{0x02,0,0,0}
To match full MAC
Link OAM
{0x07,0,16,13}
802.1ad
S-VLAN TPID
TLV 22.14.1
Link OAM
S-PCP
{0x07,0,0,16}
802.1ad
S-VLAN VID
TLV 22.14.2
Link OAM
{0x07,0,20,0}
C-PCP
Link OAM
{0x08,0,16,13}
S-DEI
Link OAM
{0x07,0,19,12}
802.1ad
C-VLAN TPID
TLV 22.14.5
Link OAM
{0x08,0,0,16}
C-CFI
Link OAM
{0x08,0,19,12}
ProtocolType
TLV 22.10.3
Link OAM
{0x03,0,0,0}
To match full Type
802.1ad
C-VLAN VID
TLV 22.14.6
Link OAM
{0x08,0,20,0}
Figure 30 - Field Masking Example for 802.1ad Tagged Frame
Protocol Type fields are able to be identified, in addition to the B-Tag, I-Tag, S-Tag and C-Tag fields. This example illustrates that to the D-ONU, a B-Tag is effectively an S-Tag, which is followed by an I-Tag, since both the B-Tag and S-Tag fields use 0x88a8 as the TPID. Therefore, to identify the B-Tag, the OAM message uses the sub-field identifier for the first instance of the S-Tag (i.e., 0). Likewise, to identify the S-Tag of the encapsulated 802.1ad frame the OAM message uses a sub-field identifier for the second instance of the S-Tag (i.e., 1).
Destination MAC address or Customer Source MAC address. This deviates from IEEE 802.1ah, and applies to all
DPoE requirements.
08/08/13
CableLabs
105
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
A B-tag is an S-tag that is followed by an
I-Tag. Hence, S-tag instance 0 is B-Tag to Link OAM.
48 bits
B-DA
48 bits
B-SA
16 bits
0x88a8
32 bits
B Tag
16 bits
B-TCI
Link OAM
{0x07,0,16,0}
3 bits 1 bit
PCP DEI
12 bits
B-VID
48 bits
I Tag*
16 bits
0x88e7
32 bits
I-TCI*
Link OAM
{0x06,0,16,0}
*In DPoE, I-Tag does not include C-DA or
C-SA
3 bits 1 bit 1 bit
PCP DEI UCA
3 bits 24 bits 48 bits 48 bits
Res I-SID C-DA C-SA
Link OAM
{0x04,0,0,0}
to match full
MAC
802.1ah
B-SA
TLV 22.15.6
Link OAM
{0x05,0,0,0}
to match full MAC
802.1ah
B-ProtocolType
TLV 22.15.3
Link OAM
{0x07,0,0,16}
{0x07,0,19,12}
802.1ah
B-PCP
802.1ah
B-DEI
Link OAM
Link OAM
{0x07,0,16,13}
802.1ah
B-VID
TLV 22.15.4
Link OAM
{0x07,0,20,0}
802.1ah
I-ProtocolType
TLV 22.15.1
Link OAM
{0x06,0,0,32}
802.1ah
I-DEI
Link OAM
{0x06,0,19,28}
802.1ah
I-PCP
Link OAM
{0x06,0,16,29}
Reserved
Link OAM
{0x06,0,21,24}
UCA
Link OAM
{0x06,0,20,27}
Customer
DestMacAddr
TLV 22.10.1
Link OAM
{0x01,0,0,0} to
match full mac
I-SID
TLV 22.15.2
Link OAM
{0x06,0,24,0}
Customer
SourceMacAddr
TLV 22.10.2
Link OAM
{0x02,0,0,0} to
match full mac
S Tag
C Tag
S-TCI
Link OAM
{0x07,1,16,0}
C-TCI
Link OAM
{0x08,0,16,0}
16 bits 3 bits 1 bit 12 bits 16 bits 3 bits 1 bit 12 bits 16 bits
0x88a8 PCP DEI VID 0x8100 PCP CFI VID 0x0800 Payload
802.1ad
S-VLAN TPID
TLV 22.14.1
Link OAM
{0x07,1,0,16}
S-PCP
Link OAM
{0x07,1,16,13}
802.1ad
S-VLAN VID
TLV 22.14.2
Link OAM
{0x07,1,20,0}
S-DEI
Link OAM
{0x07,1,19,12}
C-PCP
Link OAM
{0x08,0,16,13}
802.1ad
C-VLAN TPID
TLV 22.14.5
Link OAM
{0x08,0,0,16}
802.1ad
C-VLAN VID
TLV 22.14.6
Link OAM
{0x08,0,20,0}
C-CFI
Link OAM
{0x08,0,19,12}
ProtocolType
TLV 22.10.3
Link OAM
{0x03,0,0,0}
To match full Type
Figure 31 - Field Masking Example for 802.1ah Encapsulated 802.1ad Tagged Frame
IV.2 TPID Translation
Some legacy equipment uses pre-standard TPID values to indicate S-VLAN tags. For example, two tags in a frame might have TPIDs 0x9100 and 0x8100, rather than 0x88A8 and 0x8100. It can be desirable to normalize the TPID values so that core equipment only need be concerned with standard VLAN tag values.
Translating a value is a matter of matching frames to which we want to apply this translation, and then rewriting the appropriate value in the frame. Let's assume that the D-ONU has been instructed to treat TPID 0x9100 as a C-
VLAN tag. The TPID of a VLAN tag can be found in the most significant 16 bits of the tag.
For these frames, we want to overwrite the VLAN tag with another VLAN tag with identical VID, but with a different TPID. One way to do this is to copy the input field to the output, and then overwrite the TPID.
Condition: ({C-VLAN 0, 0, 16} == 0x9100)
Result: Copy C-VLAN 0; Set (C-VLAN 0, 0, 16} 0x88A8; Replace C-VLAN 0;
106
CableLabs
08/08/13
DPoE™ OAM Extensions Specification DPoE-SP-OAMv2.0-I03-130808
Appendix V Acknowledgements
On behalf of our industry, we would like to thank the following individuals for their contributions to the development of this specification, listed in alphabetical order of company affiliation.
Contributor Company Affiliation
John Dickinson, Edwin Mallette
Paul Gray, Drew Davis, Victor Hou
Bright House Networks
Broadcom
Curtis Knittle, Vikas Sarawat, Karthik Sundaresan, Lane Johnson, Glenn Russell CableLabs
Jimmy Hu
Tim Brophy
Mehmet Toy, Shamim Akhtar
Mike Holmes, Wen Li
Hesham ElBakourey
Victor Blake
Janet Bean
Dylan Ko
Michael Peters, Christopher Griffith
Robert Harris, Armin Sepehri
Marek Hajduczenia
Ciena
Cisco
Comcast
Finisar Corporation
Hitachi
Independent Consultant
Motorola
Qualcomm-Atheros
Sumitomo
Time Warner Cable
ZTE
08/08/13
CableLabs
107
DPoE-SP-OAMv2.0-I03-130808 Cable Data Services
Appendix VI Revision History
VI.1 Engineering Changes for DPoE-SP-OAMv2.0-I02-130328
The following Engineering Changes were incorporated into DPoE-SP-OAMv2.0-I02-130328:
ECN
OAMv2.0-N-12.0048-1
OAMv2.0-N-12.0050-1
OAMv2.0-N-12.0052-1
OAMv2.0-N-12.0056-1
OAMv2.0-N-12.0059-2
OAMv2.0-N-13.0062-1
OAMv2.0-N-13.0066-2
Date Accepted
10/8/2012
10/18/2012
10/31/2012
12/6/2012
12/7/2012
12/15/2012
1/24/2013
Summary Author
eOAMv2.0 for HW_REV, VENDOR, and MODEL
Fixes to incorrect definition of attributes and TLV formats in OAMv2 I01
Removal of optional requirement for 10G-EPON FEC
Changes to OAM resulting from comments submitted by IEEE P1904.1
Curtis Knittle
Marek Hajduczenia
Marek Hajduczenia
Marek Hajduczenia
Suspend/Resume Alarm changes (align with SIEPON) Marek Hajduczenia
Changes to MPLS definition in DPoE OAM specs Marek Hajduczenia
Delay and Drop Counters Simplification for OAMv2.0 Curtis Knittle
VI.2 Engineering Changes for DPoE-SP-OAMv2.0-I03-130808
The following Engineering Changes were incorporated into DPoE-SP-OAMv2.0-I03-130808:
ECN Date Accepted
OAMv2.0-N-13.0074-1 04/11/2013
OAMv2.0-N-13.0077-1 05/09/2013
Summary
Fixes to object context designation for some of clock transport TLVs
Restore dropped eOAM Requirements
Author
Marek
Hajduczenia
Steve Burroughs
108
CableLabs
08/08/13
advertisement
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
