DPoE SP DEMARCv1.0 C01 160830 1

DOCSIS® Provisioning of EPON Specifications
DPoEv1.0
DPoE Demarcation Device Specification
DPoE-SP-DEMARCv1.0-C01-160830
CLOSED
Notice
This DPoE™ specification is the result of a cooperative effort

undertaken at the direction of Cable Television Laboratories, Inc. for the
benefit of the cable industry and its customers. You may download,
copy, distribute, and reference the documents herein only for the
purpose of developing products or services in accordance with such
documents, and educational use. Except as granted by CableLabs in a
separate written license agreement, no license is granted to modify the
documents herein (except via the Engineering Change process), or to
use, copy, modify or distribute the documents for any other purpose.
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. To the extent this document contains or refers to documents
of third parties, you agree to abide by the terms of any licenses
associated with such third party documents, including open source
licenses, if any.
Cable Television Laboratories, Inc. 2012 - 2016
DPoE-SP-DEMARCv1.0-C01-160830 DOCSIS® Provisioning of EPON Specifications
DISCLAIMER
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. Any use or reliance on the information or opinion in
this document is at the risk of the user, and CableLabs and its members 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.
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 entities, technology advances, or changes in equipment design,
manufacturing techniques, or operating procedures described, or referred to, herein.
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 of its members to purchase any
product whether or not it meets the characteristics described in the document. Unless granted in a separate written
agreement from CableLabs, nothing contained herein shall be construed to confer any license or right to any
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.

2 CableLabs 08/30/16
DPoE Demarcation Device Specification DPoE-SP-DEMARCv1.0-C01-160830
Document Status Sheet
Document Control Number: DPoE-SP-DEMARCv1.0-C01-160830
Document Title: DPoE Demarcation Device Specification
Revision History: I01 – Released 04/10/12

I02 – Released 06/14/13
I03 – Released 11/14/13
I04 – Released 08/07/14
C01 – Closed 08/30/2016
Date: August 30, 2016
Status: Work in Draft Issued Closed

Progress
Distribution Restrictions: Author CL/Member CL/ Member/ Public

Only Vendor
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 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.
Issued A generally public document that has undergone Member and Technology
Supplier review, cross-vendor interoperability, and is for Certification testing if
applicable. Issued Specifications are subject to the Engineering Change
Process.
Closed 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/30/16 CableLabs 3
Contents
1 INTRODUCTION ...............................................................................................................................................6
1.1 Demarcation Device (DEMARC) Introduction .............................................................................................6
1.2 Scope .............................................................................................................................................................7
1.3 Goals ..............................................................................................................................................................7
1.4 Requirements .................................................................................................................................................7
1.5 DPoE Version 1.0 Specifications ...................................................................................................................8
1.6 History of the DEMARC Specification .........................................................................................................8
1.7 Reference Architecture ..................................................................................................................................8
1.8 DPoE Interfaces and Reference Points ..........................................................................................................9
2 REFERENCES .................................................................................................................................................. 12
2.1 Normative References.................................................................................................................................. 12
2.2 Informative References ................................................................................................................................ 13
2.3 Reference Acquisition.................................................................................................................................. 15
3 TERMS AND DEFINITIONS .......................................................................................................................... 16
3.1 DPoE Network Elements ............................................................................................................................. 16
3.2 Other Terms ................................................................................................................................................. 18
4 ABBREVIATIONS AND ACRONYMS .......................................................................................................... 19
5 DEMARC IN THE DPOE NETWORK .......................................................................................................... 21
5.1 Background .................................................................................................................................................. 21
5.2 DEMARC Interface Independence .............................................................................................................. 22
6 DEMARC BASIC REQUIREMENTS ............................................................................................................ 23
6.1 DPoE Metro Ethernet Service ...................................................................................................................... 23
6.2 IEEE Standards Requirements ..................................................................................................................... 23
6.3 Metro Ethernet Forum Standards ................................................................................................................. 23
6.4 IP Network Element Requirements ............................................................................................................. 23
7 IP MANAGEMENT FOR A DEMARC .......................................................................................................... 24
8 DEMARC AUTO-CONFIGURATION (DAC)............................................................................................... 26
8.1 Introduction to DAC .................................................................................................................................... 26
8.2 DAC Architecture and Overview................................................................................................................. 26
8.3 DAC DEMARC State Model ...................................................................................................................... 27
8.3.1 POWER_OFF State ............................................................................................................................. 28
8.3.2 INIT State ............................................................................................................................................. 28
8.3.3 PRE_DAC State ................................................................................................................................... 28
8.3.4 DAC_PATH State ................................................................................................................................ 29
8.3.5 DHCP State ......................................................................................................................................... 29
8.3.6 CONFIG State ..................................................................................................................................... 31
8.3.7 OPERATIONAL State .......................................................................................................................... 33
8.3.8 Global transitions ................................................................................................................................ 34
8.3.9 General DEMARC Requirements ........................................................................................................ 35
8.4 DPoE ONU Detailed Description ................................................................................................................ 35
8.5 DPoE System Detailed Description ............................................................................................................. 36
8.5.1 DPoE System DAC DHCP Relay Requirements .................................................................................. 37
8.6 DAC Messaging Sequence .......................................................................................................................... 37
ANNEX A DPOE EXTENSIONS FOR LLDP ................................................................................................... 39
ANNEX B CM CONFIGURATION FILE TLVS FOR DAC .......................................................................... 40

B.1 DAC Disable/Enable Configuration ............................................................................................................ 40

B.2 CM Interface Mask (CMIM) Encoding ....................................................................................................... 40
B.3 Upstream Service Class Name ..................................................................................................................... 41
B.4 Downstream Service Class Name ................................................................................................................ 41
B.5 Examples of CM Configuration Files .......................................................................................................... 41
B.5.1 A Single DEMARC Connected to the SFP-ONU ................................................................................. 41
B.5.2 Two DEMARCs connected to the S-ONU ............................................................................................ 42
ANNEX C L-OAMPDUS FOR LLDP ................................................................................................................ 43
C.1 DAC Configuration Parameters (0xD7/0x0800) ......................................................................................... 43
C.2 DAC Configuration Enable / Disable (0xD7/0x0803) ................................................................................. 43
ANNEX D IP NETWORK ELEMENT CONFIGURATION EXAMPLE ...................................................... 44
D.1 Example IP-SG Configuration for DAC ...................................................................................................... 44
D.2 DAC DHCP Relay Requirements ................................................................................................................ 44
ANNEX E PARAMETERS AND CONSTANTS............................................................................................... 45
APPENDIX I ACKNOWLEDGEMENTS .......................................................................................................... 46
APPENDIX II REVISION HISTORY .............................................................................................................. 47
II.1 Engineering Change for DPoE-SP-DEMARCv1.0-I02-130614.................................................................. 47
Figures
Figure 1 - DPoEv1.0 Reference Architecture ................................................................................................................9
Figure 2 - DPoEv1.0 Interfaces and Reference Points................................................................................................. 10
Figure 3 - D-ONU Types ............................................................................................................................................. 17
Figure 4 - DPoE Network Elements ............................................................................................................................ 17
Figure 5 - DPoE Network Showing the Metro Ethernet Service Forwarding Path from MN to MU .......................... 25
Figure 6 - BB-ONU or S-ONU .................................................................................................................................... 26
Figure 7 - BP-ONU...................................................................................................................................................... 26
Figure 8 - DAC DEMARC State Diagram .................................................................................................................. 28
Figure 9 - High level DAC messaging sequence. ........................................................................................................ 38
Figure 10 - DPoE-specific LLDPDU Structure ........................................................................................................... 39
Tables
Table 1 - DPoE 1.0 Series of Specifications ..................................................................................................................8
Table 2 - DPoEv1.0 Interface and Reference Point Descriptions ................................................................................ 10
Table 3 - Backoff values for retransmission of DHCPDISCOVER ............................................................................ 30
Table 4 - LLDPDU Vendor-specific (TLV 127) for DPoE with OUI (0x00-10-00) ................................................... 39
Table 5 - DAC Configuration Parameters ................................................................................................................... 43
Table 6 - DAC Configuration Enable / Disable ........................................................................................................... 43

1 INTRODUCTION
DOCSIS Provisioning of EPON (DPoE) specifications are a joint effort of CableLabs, cable operators, vendors, and
suppliers to support EPON technology using existing DOCSIS-based back office systems and processes.
Ethernet PON or EPON is an IEEE Ethernet 802.3 standard for a passive optical network (PON). A PON is a
specific type of 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. Appendix I in
[DPoE-ARCHv1.0] has a more detailed explanation of multi-access optical networks.
This version of the DPoE specifications focuses 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), and
Metro Ethernet (MEF) services. DPoE Networks offer IP(HSD) services functionally equivalent to DOCSIS
networks using a model similar to DOCSIS, where the DPoE System acts like a DOCSIS CMTS, and the DPoE
System and DPoE ONU act like a DOCSIS CM.
1.1 Demarcation Device (DEMARC) Introduction

The DEMARC was introduced in DPoE specifications to fill a need by operators for a device to act as the
demarcation point between the MSO’s DPoE Network access interface on the DPoE ONU (D-ONU) or the MSO’s
Ethernet Network access interface on a non-EPON network, and the Customer Equipment (CE) as defined in the
Metro Ethernet Forum MEF specifications. By definition the DEMARC is an Ethernet device connected to the D-
ONU MEF I-NNI (MI) or non-EPON MEF I-NNI interface providing one or more MEF UNI (MU) interfaces to one
or more CE devices.
The DEMARC is not a Customer Premise Equipment (CPE) as defined in DOCSIS or DPoE specifications. The
specifications contained herein do not apply to a device connected to the Cable Modem to CPE Interface (CMCI).
The DEMARC in one scenario may play the role of a Network Interface Device (NID). In some cases, a DPoE ONU
is sufficient to meet the operator's needs. There are a variety of reasons that an operator might elect to use a
DEMARC with a D-ONU rather than just a D-ONU. Among these reasons may be factors such as:
Port requirements
The wide variety of devices that can be a DEMARC includes switches, routers, NIDs, gateways, firewalls, security
devices, and many other types of Ethernet devices that provide Metro Ethernet or other services. DEMARCs might
be used by operators to provide a larger number or greater variety of Ethernet port types. DEMARCs might also be
used by operators to provide ports for other (over the top) services as described below.
Physical Requirements
DEMARCs can have operators' requirements that extend beyond the DPoE specifications. These could, for example,
include physical requirements such as those for rack-mounting, outside plant operations, electrical power, or other
physical requirements.
Multiple Tenant Unit Requirements
DEMARCs are likely to be used for Multiple Tenant facilities because they have a larger number of ports. Operators
may also have additional requirements for management and operations of a DEMARC that is used to provide
services to multiple customers.
Over-the-Top Services
DEMARCs can also be used by operators to provide services beyond the Metro Ethernet services. For example, an
operator might use a DEMARC to provide MU interfaces and also run IP(HSD) services on other ports. Another
example might be MU interfaces and a "soft MU" (terminated on the DEMARC) with IP running over the Metro
Ethernet service to a SIP proxy with IP/Ethernet, FXS or NxT1 interface(s) for voice.
Other Requirements

Operators might need advanced service management and Metro Ethernet circuit management features such as
SOAM, QoS, over-the-top IP/MPLS (such as U-PE), or other functionality that is not provided by stand-alone D-
ONUs.
1.2 Scope
This specification describes some of the requirements for DEMARCs for providing Metro Ethernet services. This
specification is not a comprehensive set of requirements for a DEMARC because, by definition, the requirements for
the DEMARC include physical, port, service, management, and other requirements that are beyond the scope of the
DPoE specifications.
The focus of the DEMARC specification is on the requirements for the interface between the MSO’s network and
the DEMARC. This specification also provides a means for automating the in-band management path for the
DEMARC, and for transferring a configuration file to the DEMARC.
1.3 Goals
Operators are likely to widely use DEMARCs to meet a variety of Metro Ethernet and over-the-top service needs for
both single-tenant and multi-tenant businesses or commercial services. The goal of this specification is to:
• Describe, but not specify, basic requirements for MEF functionality for a DEMARC.
• Describe the use of MI and MU interfaces with a DEMARC.
• Provide detailed requirements for the automatic distribution of a pre-existing device configuration from the
operator's Operations and Support Systems (OSS) to the DEMARC.
• Provide independence of automation from the type of pluggable or baseband interface on the DEMARC.
Since the requirements for MI and MU interfaces are clearly specified in [DPoE-MEFv1.0], this specification makes
reference to the [DPoE-MEFv1.0] specification, but does not provide any additional technical requirements for these
interfaces.
Historically, operators configured the DEMARC manually with either an Element Management System
(EMS)/Network Management System (NMS) or by manually writing configuration files.
1.4 Requirements
Throughout this document, the words that are used to define the significance of particular requirements are
capitalized. These words are:
"MUST" This word means that the item is an absolute requirement of this specification.
"MUST NOT" This phrase means that the item is an absolute prohibition of this specification.
"SHOULD" 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 1.0 Specifications

A list of the specifications included in the DPoE version 1.0 series is provided in Table 1. For further information
please refer to http://www.cablelabs.com/dpoe/specifications.
Table 1 - DPoE 1.0 Series of Specifications
Designation Title
DPoE-SP-ARCHv1.0 DPoE Architecture Specification
DPoE-SP-DEMARCv1.0 DPoE Demarcation Device Specification
DPoE-SP-OAMv1.0 DPoE OAM Extensions Specification
DPoE-SP-PHYv1.0 DPoE Physical Layer Specification
DPoE-SP-SECv1.0 DPoE Security and Certificate Specification
DPoE-SP-IPNEv1.0 DPoE IP Network Element Requirements
DPoE-SP-MULPIv1.0 DPoE MAC and Upper Layer Protocols Interface Specification
DPoE-SP-MEFv1.0 DPoE Metro Ethernet Forum Specification
DPoE-SP-OSSIv1.0 DPoE Operations and Support System Interface Specification
1.6 History of the DEMARC Specification

This specification was developed between the releases of DPoEv1.0 and DPoEv2.0 specifications. Consequently,
there are terms introduced in this document that extend the concepts and terminology beyond those which were used
in the other DPoE version 1.0 specifications. Generally, these terms are well defined and their meaning will be clear
to readers of this specification.
1.7 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, which may be an off-the-shelf EPON ONU or EPON SFP-ONU. The remaining elements in the
architecture are existing servers and systems in the operator’s network. All of the server elements have connectivity
through an IP (TCP/IP) network. Transport of bearer traffic and (in some cases) Layer 2 (L2) OAM signaling is
available through either IP or L2 Ethernet-based Network Interfaces.

DPoE-SP-IPNEv1.0
SSH/Telnet
TACACS+
RADIUS
HTTP
NTP
FTP/SFTP
TFTP DOCSIS 3.0 Equivalent IP Service
External
RSH
eSAFE
SNMP eSAFE SNMP SNMP External
eSAFE
eSAFE EVCs EVCs
DPoE-SP-OSSIv1.0
OSSI
SNMP
DPoE-SP-OAMv1.0 IEEE WiFi
EPON OAM + EPON OAM Extensions 802.1 eDVA
Switch
eRouter
OSS WiFi
sDVA
R DPoE-SP-PHYv1.0
ODN
IP/Transport X DEMARC
ONU
Network
R R
DEMARC
OLT
DPoE Standalone ONU
R/X DPoE System
ONU
DPoETM
Bridge ONU DEMARC
DPoE-SP-IPNEv1.0 IEEE
IEEE 802.3 (EPON) 802.1
Routing Switch DEMARC
ARP
IS-IS
OSPF
MP-BGP DPoE-SP-MEFv1.0
MEF EVCs
Figure 1 - DPoEv1.0 Reference Architecture
1.8 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 sub-
systems. The reference points have protocols that run across them, or have a common format of bearer traffic (with
no signaling protocol). All of the interfaces are bi-directional interfaces that support two-way communications. The
protocols in DPoE specifications operate within different layers based on the [802.3], [802.1], IETF, MEF, and
CableLabs specifications. The C reference points are uni-directional for upstream (CO) or downstream (CS)
classification, respectively.

DPoE-SP-IPNEv1.0
SSH/Telnet
TACACS+
RADIUS
HTTP
NTP
FTP/SFTP
External
RSH
eSAFE
eSAFE
D eSAFE EVCs EVCs
DPoE-SP-OSSIv1.0
OSSI CO S1 LCI CMCI MU
SNMP
CS DPoE-SP-OAMv1.0 IEEE WiFi
Switch
eRouter
OSS TU WiFi
sDVA
R DPoE-SP-PHYv1.0
ODN
ONU
Network
R R
DEMARC
OLT
DPoE Standalone ONU MI MEF
R/X DPoE System INNI
ONU
DPoETM
Bridge ONU DEMARC
MN IEEE 802.3
MEF INNI X MI
L2VPN MEF
DPoE-SP-IPNEv1.0 INNI
IEEE 802.3 (EPON) MI IEEE
802.1
ARP
IS-IS IEEE 802.3
OSPF
DPoE-SP-MEFv1.0
S2 Frame Labels
MP-BGP 802.1 MAC
MEF EVCs 802.1 q VLAN
802.1ad or q-in-q
802.1ah ISID or MAC-in-MAC
KEY
Reference Point Interface
(GREEN) (RED)
Figure 2 - DPoEv1.0 Interfaces and Reference Points
Table 2 - DPoEv1.0 Interface and Reference Point Descriptions
Interface or Interface or Reference Point Description

Reference Point
MN 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.
D The D interface is the DOCSIS IP NNI interface. It is an operator network facing interface,
sometimes called a Network to Network Interface (NNI) or 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.
TU The TU interface is a short form of expressing the interface between the DPoE System and
the DPoE ONU.
C The C reference point is used to describe traffic ingress to a DPoE classifier.
CO The CO reference point is used to explain traffic ingress to a DPoE ONU upstream classifier.
CS The CS reference point is used to explain traffic ingress to a DPoE System downstream
classifier.

Interface or Interface or Reference Point Description

Reference Point
S The S interface is an IEEE 802 interface. The S interface may be an internal interface (such
as [802.3] across a GMII SERDES or XGMII interface in an SFP-ONU, SFP+ONU or XFP-
ONU) or it may be an external [802.3] interface.
S1 is an interface for a DPoE Standalone ONU. S2 is a reference point used to describe
services supported with the DPoE Bridge ONU.
S1 The S1 interfaces are the general case of all interfaces on a DPoE Standalone ONU. S1
interfaces may be CMCI, LCI, MI, or MU interfaces.
S2 The S2 reference point is used to describe traffic ingress to and egress from interfaces on a
DEMARC device in a DPoE System. Although there are no specifications or requirements
for the S2 reference point, informative text refers to the S2 reference point to provide the full
context for the use of a DPoE Bridge ONU in a DEMARC device providing Metro Ethernet
services.
LCI The Logical CPE Interface (LCI) interface is an eDOCSIS interface as defined in
[eDOCSIS]. The eDOCSIS architecture is [802.1d] MAC-based according to the DOCSIS
3.0 specifications; however, DOCSIS L2VPN clearly supports [802.1Q] switching. In
practice, therefore, the eDOCSIS interface consists of a DOCSIS classifier and [802.1]
switch as illustrated. The function of a DOCSIS classifier is in part replaced by forwarding
(tagging and encapsulation) in MEF and in part covered by classifiers in this specification.
CMCI 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.
MI MI is usually an S interface (or S reference point) that operates as a MEF INNI.
A DPoE ONU that provides a MEF INNI has an MI interface.
A DPoE ONU can have MU as an interface and an MI reference point on different S
interfaces in a single DPoE ONU.
The MI interface or reference point is an [802.3] interface (or reference point) between a
DPoE ONU and a DEMARC device.
MU MU is usually an S interface (or S reference point) that operates as a MEF UNI.
A DPoE ONU that directly provides a MEF UNI (MU) interface has MU as an interface.
A DPoE ONU can have MU as an interface and an MI reference point on different S
interfaces in a single DPoE ONU.
The MU interface or reference point is an [802.3] interface (or reference point) between a
DPoE ONU or a DEMARC device and a customer’s equipment.

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.
In this specification, terms “802.1ad” and “802.1ah” are used to indicate compliance with the [802.1ad] and
[802.1ah] standards, respectively, now incorporated as part of [802.1Q]. For all intents and purposes, claiming
compliance to [802.1Q], [802.1ad], or [802.1ah] in the scope of this specification will be treated as claiming
compliance to IEEE Std 802.1Q-2011. Unless otherwise stated, claiming compliance to 802.1Q-2005 requires a
specific date reference.
[802] IEEE Std 802-2001, IEEE Standard for Local and Metropolitan Area Networks: Overview
and Architecture, 2001.
[802.1] Refers to entire suite of IEEE 802.1 standards unless otherwise specified.
[802.1AB] IEEE Std 802.1AB-2009, IEEE Standard for Local and Metropolitan Area Networks –
Virtual Bridged Local Area Networks – Amendment 6: Provider Backbone Bridges, 2009.
[802.1AE] IEEE Std 802.1AE-2006, IEEE Standard for Local and Metropolitan Area Networks: –
Media Access Control (MAC) Security, 2006.
[802.1ah] IEEE Std 802.1ah-2008, IEEE Standard for Local and Metropolitan Area Networks –
Station and Media Access Control Connectivity Discovery, January 2008. Former
amendment to 802.1Q, now part of 802.1Q-2011.
[802.1d] IEEE Std 802.1d™-2004, IEEE Standard for Local and Metropolitan Area Networks –
Media Access Control (MAC) Bridges
[802.1Q] 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.
[802.3] IEEE Std 802.3-2012, IEEE Standard for Ethernet, December 2012.
[CANN-DHCP-Reg] CableLabs DHCP Options Registry, CL-SP-CANN-DHCP-Reg, Cable Television
Laboratories, Inc.
[CMCIv3.0] Data-Over-Cable Service Interface Specifications, Cable Modem to Customer Premise
Equipment Interface Specification, CM-SP-CMCIv3.0, Cable Television Laboratories, Inc.
[DPoE-IPNEv1.0] DOCSIS Provisioning of EPON, IP Network Element Requirements, DPoE-SP-IPNEv1.0,
Cable Television Laboratories, Inc.
[DPoE-MEFv1.0] DOCSIS Provisioning of EPON, Metro Ethernet Forum Specification, DPoE-SP-MEFv1.0,
[DPoE-MULPIv1.0] DOCSIS Provisioning of EPON, MAC and Upper Layer Protocols Requirements, DPoE-
SP-MULPIv1.0, Cable Television Laboratories, Inc.
[eDOCSIS] Data-Over-Cable Service Interface Specifications, eDOCSIS Specification, CM-SP-
eDOCSIS, Cable Television Laboratories, Inc.
[G.805] ITU-T Recommendation G.805 (03/00), Generic functional architecture of transport
networks.

2.2 Informative References

This specification uses the following informative references.
[802.1ad] IEEE Std 802.1ad-2005™-2006, 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
[802.1ag] 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.1ax] IEEE Std 802.1ax-2008, IEEE Standard for Local and Metropolitan Area Networks – Link
Aggregation, January 2008.
[802.3ac] IEEE Std 802.3ac™-1995, IEEE Standard for Carrier Sense Multiple Access with Collision
Detection (CSMA/CD) Access Method and Physical Layer Specifications - Frame
Extensions for Virtual Bridged Local Area Network (VLAN) Tagging on 802.3 Networks,
January 1995. Now part of [802.3].
[802.3ag] IEEE Std 802.3ag™-2007, IEEE Standard for Local and Metropolitan Area Networks –
Virtual Bridged Local Area Networks-Amendment 5: Connectivity Fault Management,
January 2007.
[802.3as] IEEE Std 802.3as™-2006, Amendment 3 to IEEE Standard for Information technology -
Telecommunications and information exchange between 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 3,
November 2006.
[DOCSIS] Refers to DOCSIS 3.0 Specification unless otherwise specified.
[DPoE-ARCHv1.0] DOCSIS Provisioning of EPON, DPoE Architecture Specification, DPoE-SP-ARCHv1.0,
[DPoE-OAMv1.0] DOCSIS Provisioning of EPON, OAM Extensions Specification, DPoE-SP-OAMv1.0,
[DPoE-OSSIv1.0] DOCSIS Provisioning of EPON, Operations and Support System Interface Specification,
DPoE-SP-OSSIv1.0, Cable Television Laboratories, Inc.
[DPoE-PHYv1.0] DOCSIS Provisioning of EPON, Physical Layer Specification, DPoE-SP-PHYv1.0, Cable
Television Laboratories, Inc.
[DPoE-SECv1.0] DOCSIS Provisioning of EPON, Security and Certificate Specification, DPoE-SP-SECv1.0,
[eRouter] Data-Over-Cable Service Interface Specifications, eRouter Specification, CM-SP-eRouter,
[I2C] UM10204, I2C-bus specification and user manual, Rev. 03, 10 June 2007,
http://www.nxp.com/acrobat/usermanuals/UM10204_3.pdf.
[L2VPN] Data-Over-Cable Service Interface Specifications, Layer 2 Virtual Private Networks, CM-
SP-L2VPN, Cable Television Laboratories, Inc.
[MEF 6] Metro Ethernet Forum, MEF 6.1 Ethernet Services Definitions, Phase 2, April 2008.
[MEF 9] Metro Ethernet Forum, Abstract Test Suite for Ethernet Services at the UNI, October 2004.
[MEF 14] Metro Ethernet Forum, Abstract Test Suite for Traffic Management Phase 1, November
2005.
[MEF 21] Metro Ethernet Forum, Service OAM and Requirements Framework, Phase 1, April 2007.

[MEF 26] Metro Ethernet Forum, External Network to Network Interface (ENNI) – Phase 1, January
2010.
[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 768] IETF RFC 768, User Datagram Protocol. August 1980.
[RFC 1350] IETF RFC 1350, The TFTP Protocol (Revision 2), July 1992.
[RFC 2011] IETF RFC 2011, SNMPv2 Management Information Base for the Internet Protocol using
SMIv2, K. McCloghrie, November 1996.
[RFC 2131] IETF RFC 2131, Dynamic Host Configuration Protocol, March 1997.
[RFC2132] IETF RFC 2132, DHCP Options and BOOTP Vendor Extensions, S. Alexander, March
1997.
[RFC 2863] IETF RFC 2863, The Interfaces Group MIB, June 2000.
[RFC 3046] DHCP Relay Agent Information Option, January 2001.
[RFC 3203] IETF RFC 3203, DHCP reconfigure extension, December 2001.
[RFC 3418] IETF RFC 3418/STD0062, Management Information Base (MIB) for the Simple Network
Management Protocol (SNMP), June 2000.
[RFC3986] IETF RFC 3986, Uniform Resource Identifier (URI): Generic Syntax, T. Berners-Lee,
January 2005.
[RFC 4188] IETF RFC 4188, Definitions of Managed Objects for Bridges, September 2005.
[RFC 4293] IETF RFC 4293, Management Information Base for the Internet Protocol (IP), April 2006.
[RFC 4361] IETF RFC 4361, Node-specific Client Identifiers for Dynamic Host Configuration Protocol
Version Four (DHCPv4), February 2006.
[RFC 5905] IETF RFC 5905, Network Time Protocol Version 4: Protocol and Algorithms Specification,
June 2010.
[SCTE 174] 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,
[SFF-8077i] SFF-8077i 10 Gigabit Small Form Factor Pluggable Module, Revision 4.0, 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 12 May
2001.

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
• Institute of Electrical and Electronics Engineers (IEEE), +1 800 422 4633 (USA and Canada);
http://www.ieee.org
• 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
• International Telecommunication Union (ITU), Place des Nations, CH-1211, Geneva 20, Switzerland; Phone
+41-22-730-51-11; Fax +41-22-733-7256. Internet: http://www.itu.int
• MEF: Metro Ethernet Forum, 6033 W. Century Blvd, Suite 830, Los Angeles, CA 90045
Phone +1-310-642-2800; Fax +1-310-642-2808. Internet: http://metroethernetforum.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

3 TERMS AND DEFINITIONS

3.1 DPoE Network Elements
DPoE Network This term means the entire network described in Figure 2 from the D or MN
interface to the LCI, S, MI, or MU interface (see Figure 2 for interface and
reference points), depending on the service being described. The DPoE Network
includes the part of a DEMARC that supports DEMARC Auto Configuration.
DPoE System This term means all the collected elements that provide the DPoE function within
the operator's network facilities. This includes the EPON OLT function, DOCSIS
service functions required for the D interface, Metro Ethernet service functions
required for the MN interface, and IP NE element management, routing and
forwarding functions specified in [DPoE-IPNEv1.0]. The DPoE System is depicted
in Figure 4.
DPoE ONU (D-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 and the DPoE Bridge ONU.
DPoE Standalone ONU This term means a D-ONU that provides all the functions of a B-ONU and also
(S-ONU) provides at least one CMCI port. An S-ONU can optionally have one or more
eSAFEs.
DPoE Bridge ONU (B-ONU) This term means a D-ONU that is capable of [802.1] forwarding but cannot do all
the encapsulation functions required to be a DPoE Standalone 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 This term means a D-ONU that is a B-ONU that is pluggable. Pluggable BP-ONUs
(BP-ONU) include devices such as an SFP-ONU (1G-EPON), SFP+ONU (10G-EPON), or
XFP-ONU (10G-EPON).
DPoE Bridge Baseband ONU This term means a D-ONU that is a B-ONU that has a baseband IEEE Ethernet
(BB-ONU) interface. BB-ONUs include those with one or more [802.3] baseband PMDs. (See
[DPoE-ARCHv1.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).

Logical Used for DPoE Specifications

(Normative Requirements) D-ONU
Used for DPoE Specifications

Logical (Normative Requirements) or for
+ Product informative text.
B-ONU S-ONU
May be used for DPoE

Product informative, but not for normative
specifications.
S-ONU
S-ONU S-ONU
Likely products. MUST not be +eSAFE
+eSAFEs +.1ah
used for DPoE normative +.1ah
Product (specifications). Should not be BP-ONU
Options BB-ONU
used for DPoE informative.
Logical DPoE Elements

D-ONU DPoE ONU
B-ONU Bridge ONU
BP-ONU Bridge Pluggable ONU
BB-ONU Bridge Baseband ONU
S-ONU Standalone ONU BB-ONU
SFP-ONU SFP+ONU XFP-ONU +.1ah
Real ONUs
S-ONU Standalone ONU
BB-ONU Bridge Baseband ONU
BP-ONU Bridge Pluggable ONUs

SFP-ONU SFP ONU (1G-EPON)
SFP+ONU SFP+ ONU (10G-EPON)
XFP-ONU XFP-ONU (10G-EPON)
Figure 3 - D-ONU Types
IEEE WiFi
802.1 eDVA
Switch
eRouter
CE
X DEMARC CE
EPON ONU
CHIP DEMARC CE
R
OLT
S-ONU
DPoE System EPON CE
CHIP
DEMARC CE
ONU DEMARC CE
BB-ONU
EPON
B-ONU CHIP
DEMARC
BP-ONU ONU CE
DPoE Network
D-ONU
Figure 4 - DPoE Network Elements

3.2 Other Terms1
1G-EPON EPON as first defined in [802.3ah], now part of [802.3].

10G-EPON EPON as first defined in [802.3av], now part of [802.3].
Cable Modem CPE Interface CMCI as defined in [MULPIv3.0]
Customer Equipment Customer Equipment as defined in [DPoE-MEFv1.0]
Customer Premise Equipment Customer Premise Equipment as defined in [DOCSIS]
(CPE)
DAC-Path The management VLAN path established for IP-based management traffic
from DEMARC to the router on the DPoE System
DAC-Path VLAN Set The set of VLAN tags used to identify management frames traversing the
DAC-Path
Ethernet Passive Optical Network Refers to both 1G-EPON and 10G-EPON collectively
(EPON)
EPON Operations and Maintenance EPON OAM messaging as defined in [802.3] and [DPoE-OAMv1.0];
Messaging (OAM) Ethernet OAM is not the same as EPON OAM; Ethernet OAM is
[802.1ag].
Network Interface Device (NID) A DEMARC in DPoE specifications
1
Revised per DEMARCv1.0-N-14.0167-1 on 7/3/14 by JB.

4 ABBREVIATIONS AND ACRONYMS

This specification uses the following abbreviations:
BOOTP Bootstrap protocol

CMCI Cable Modem CPE Interface
CE Customer Equipment
CPE Customer Premise Equipment
DA Destination Address
DAC DEMARC Automatic Configuration
DDMI Digital Diagnostic Monitoring Interface
DDMM Digital Diagnostic Memory Map
DHCP Dynamic Host Configuration Protocol
DPoE DOCSIS Provisioning of EPON
DR Default Router
EPL (E-LINE) Ethernet Private Line
EPON Ethernet Passive Optical Network
EMS Element Management System
EVC Ethernet Virtual Connection
E-VPL Ethernet Virtual Private Line
IP(HSD) High Speed Data (Broadband Internet Access using DOCSIS)
I-NNI Internal Network to Network Interface
IP Internet Protocol
I-SID [802.1ah] I-Component Service Identifier
LCI Logical CPE Interface
LLDP Link Layer Discovery Protocol
LLDPDU Link Layer Discovery Protocol Data Unit
LLID Logical Link Identifier
MAC Media Access Control (sublayer)
MEF Metro Ethernet Forum
MEN Metro Ethernet Network
MI MEF I-NNI Interface
MLS Multi-Layer Switching
MN MEF I-NNI Interface to operators' MEN
MU MEF UNI Interface
NID Network Interface Device
NNI Network to Network Interface
NMS Network Management System
OAM EPON Operations Administration and Maintenance
ODN Optical Distribution Network

OLT Optical Line Termination

ONU Optical Network Unit
OSS Operations and Support Systems
PB Provider Bridging [802.1ad]
P2P Point-to-Point
P2PE Point-to-Point Emulation
PHY Physical Layer
PMD Physical Media Dependent (Sublayer)
PON Passive Optical Network
QoS Quality of Service
R IP Router
SA Source Address
SFP Small Form-factor Pluggable
SFF Small Form-Factor Committee
SFP-ONU Small Form-factor Pluggable ONU
SFP+ Small Form-factor Pluggable Plus (+)
SFP+ ONU Small Form-factor Pluggable Plus (+) ONU
SFTP Secure File Transfer Protocol
SSH Secure Shell
UNI User Network Interface
URI Uniform Resource Identifier
vCM Virtual Cable Modem
WDM Wavelength Division Multiplexing
X IEEE Ethernet Switch (Generic)
XFP X Form-factor Pluggable
XFP-ONU X Form-factor Pluggable ONU

5 DEMARC IN THE DPOE NETWORK

5.1 Background
The process of manually creating, distributing, and updating configuration files is time-consuming and prone to
human error and other challenges. One of the challenges of provisioning a device at the customer premises is the
fact that there is no industry standard solution for provisioning Ethernet devices.
There are two widely used industry standards for IP-based automatic device configuration. These are the bootstrap
protocol (BOOTP) and the Dynamic Host Configuration Protocol (DHCP). Both solutions assume that the device in
question is attached to an IP network. While this is a valid assumption for IP network-based services (like Internet
access or IP-VPNs) it is invalid for Metro Ethernet services, where automated allocation of VLAN IDs is needed
and currently not provided by any existing Ethernet protocol. When Metro Ethernet services are offered, typically
with an Ethernet access network technology, multiple Ethernet services can be multiplexed over the access network.
For example, if a DEMARC is used in a Multiple Tenant Unit environment, it is desired to separate the provisioning
of the management path to the DEMARC and provisioning of the DEMARC itself from the provisioning of services
for individual customers connected to the DEMARC. In particular, it is required is to de-couple the process of
provisioning of the DEMARC management path from the process of CM provisioning which is typically associated
with individual customers. The challenge is that there is no standard means to identify which Ethernet service (in the
case of MEF – which Ethernet Virtual Connection (EVC)) should be used for management, versus those used for
UNI forwarding. 2Even if an operator follows a recommendation of MEF, suggesting to use C-VID 4090 for this
purpose, such recommendations are based on the assumption that the Ethernet access link is dedicated. There are no
provisions for how to handle the in-band management traffic when that traffic is present on a platform like the DPoE
System (or any OLT or Ethernet switch) where there are multiple such VIDs. There are also additional security,
operational, and scaling concerns when using a single C-VLAN ID for in-band management across multiple
DEMARC devices.
In an access network, the DEMARC is located in the customer premises and typically is either the access network
termination device or is attached to an access network termination device. Either the DEMARC or the access
network termination device has connectivity to the operator's network across an access network interface. In a DPoE
Network, the access network interface corresponds to the TU interface.
For Metro Ethernet services, the TU interface carries one or more logical Ethernet services, organized into EVCs as
described by MEF. By definition, an EVC carries Ethernet frames from one UNI to another UNI. The problem for
operators is how to have an IP connection for managing the DEMARC that is outside of any of those EVCs. More
specifically, the problem is how to automate a standard method of providing an IP connection in-band on the TU
interface.
The solution cannot simply rely on the use of the "default VLAN" because a single management VLAN cannot be
used on a shared network (i.e., a PON) across multiple devices, and still be unique for each premise or for each
DEMARC. Even where it is possible to operate a single management VLAN shared across multiple devices,
operating a single VLAN (which is a single broadcast domain) across multiple DEMARCs and multiple customer
premises presents multiple operational, scaling and security concerns. The operators require a dedicated Ethernet
control path (established using any specified combination of [802.1Q] 3 tagging for Ethernet frames) for each
DEMARC in order to isolate management traffic from regular subscriber traffic and address security concerns.
In addition to the device provisioning challenges listed above, a method for identifying a configuration file for a
DEMARC is not currently standardized.
This specification provides requirements for automating the configuration of an in-band DEMARC management
path over a DPoE Network, providing the name for the DEMARC configuration file, and the means for file transfer
2
The Metro Ethernet Forum (MEF) Ethernet Access Services Definition D0.96 recommends the use of VLAN ID = 4090 for in-
band management of service-provider devices. An operator can use VLAN ID 4090 for in-band management by provisioning the
DAC Serving Group for VID=4090.
3
Please see the note on the [802.1Q] standard compliance in subsection 2.1.

from the OSS to the DEMARC over the DPoE Network, therefore creating a DEMARC Automatic Configuration
(DAC) mechanism.
5.2 DEMARC Interface Independence

Additionally, this specification supports automatic configuration of DEMARC across any pluggable or baseband
Ethernet interface, including deployed B-ONUs.

6 DEMARC BASIC REQUIREMENTS

The DEMARC is a DPoE Network element used to provide Metro Ethernet UNI services to business or commercial
customers. Requirements contained herein represent a set of minimum requirements for a DEMARC to provide
Metro Ethernet services (as defined by MEF) with automatic DEMARC discovery and configuration to operate both
customer services as well as IP-based management by the operator.
Figure 1 shows a simplified DPoE Network with DPoE System, a D-ONU, and a DEMARC. The D-ONU provides
an MI interface to a DEMARC. The DEMARC has the MI interface to the D-ONU and an MU interface for Metro
Ethernet service connected to the CE.
6.1 DPoE Metro Ethernet Service

The DEMARC MUST support the MEF UNI (MU) interface requirements specified for a D-ONU in [DPoE-
MEFv1.0].
6.2 IEEE Standards Requirements

The DEMARC MUST support the IEEE specifications as defined for a D-ONU in [DPoE-MEFv1.0].
6.3 Metro Ethernet Forum Standards

The DEMARC MUST support the MEF specifications as defined for a D-ONU in [DPoE-MEFv1.0].
6.4 IP Network Element Requirements

The DEMARC SHOULD support the same IP management service requirements defined for a DPoE System in
[DPoE-IPNEv1.0]. Common examples of these types of services include Secure Shell (SSH), Secure File Transfer
Protocol (SFTP), Trivial File Transfer Protocol (TFTP), Secure HTTP (HTTPS), SNMPv2, SNMPv3, and
SYSLOG.

7 IP MANAGEMENT FOR A DEMARC

This specification provides a method for provisioning an Ethernet control path to the DEMARC, relying on
[802.1Q] tagging.
The DPoE version 1.0 specifications enable an operator to provision an Ethernet Private Line (EPL) as illustrated in
Figure 5 (orange line) and use that EVC to run Ethernet or IP-based management of the DEMARC over the top of
the DPoE Network. In such a case, the operator must also provision the EVC in the D-ONU (vCM) configuration
file to make sure the respective management traffic is forwarded correctly through the D-ONU.
When operating an Ethernet access network, the operator can provision an EPL in a fashion similar to what is
described in the previous paragraph, and use that EVC to run Ethernet or IP-based management of the DEMARC
over the top of the Ethernet access network. In this case the operator must provision the EVC in the associated
Ethernet access network equipment using device-specific configuration mechanisms not covered by this
specification.
Additionally, this specification introduces an automated method of identifying a DEMARC, creating an Ethernet
path through the operator’s access network to the DEMARC, assigning an IP address to the DEMARC, initiating a
file transfer for a DEMARC configuration file, and making the DEMARC available as an IP-addressable device
connected to the operator’s IP router (R), as illustrated in Figure 5 (purple line). This automated method is hereafter
referred to as DEMARC Auto Configuration (DAC).
The DPoE Network uses the Provider Bridging model to establish a data path from the DEMARC, through the D-
ONU to the DPoE System. When Provider Bridging is used, one or more S-VLANs are allocated for DAC and a
dedicated C-VLAN (for that allocated S-VLAN) is assigned to each DEMARC, creating a unique combination of S-
VLAN and C-VLAN tags that uniquely identifies the DEMARC. The S-VLANs are assigned to a DAC Serving
Group. Within the serving group, the DPoE System autonomously allocates C-VLANs.
Hereafter, the Ethernet control path is referred to as the “DAC-Path”, and the set of VLAN tags used to identify
DEMARC management frames traversing the DAC-Path are referred to as the “DAC-Path VLAN set”.

DPoE-SP-IPNEv1.0
SSH/Telnet
TACACS+
RADIUS
HTTP
NTP
FTP/SFTP
External
RSH
eSAFE
eSAFE
D eSAFE EVCs EVCs
DPoE-SP-OSSIv1.0
OSSI CO S1 LCI CMCI MU
SNMP
CS DPoE-SP-OAMv1.0 IEEE WiFi
Switch
eRouter
OSS TU WiFi
sDVA
R DPoE-SP-PHYv1.0
ODN
ONU
Network
R R
DEMARC
OLT
DPoE Standalone ONU MI MEF
R/X DPoE System INNI
ONU
DPoETM
Bridge ONU DEMARC
MN IEEE 802.3
MEF INNI X MI
L2VPN MEF
DPoE-SP-IPNEv1.0 INNI
IEEE 802.3 (EPON) MI IEEE
802.1
ARP
IS-IS IEEE 802.3
OSPF
DPoE-SP-MEFv1.0
S2 Frame Labels
MP-BGP 802.1 MAC
MEF EVCs 802.1 q VLAN
802.1ad or q-in-q
802.1ah ISID or MAC-in-MAC
Figure 5 - DPoE Network Showing the Metro Ethernet Service Forwarding Path from MN to MU

8 DEMARC AUTO-CONFIGURATION (DAC)

8.1 Introduction to DAC
The DAC process provides a means for the automatic discovery of a DEMARC in the network, configuration of an
in-band IP management path for the DEMARC, and the discovery and transfer of a DEMARC configuration file
specific to the particular DEMARC that is discovered and connected.
As with DOCSIS, this specification does not describe the process to generate a configuration file the DEMARC, nor
does this specification describe the contents of a configuration file. A DEMARC configuration file is required for a
file transfer to occur. The DEMARC configuration file may be generated at any time prior to the file transfer.
8.2 DAC Architecture and Overview

By definition, a DEMARC is an Ethernet device that connects to the MI interface of a D-ONU and provides one or
more MU interfaces, as depicted in Figure 5. Figure 6 shows an example of a BB-ONU or S-ONU connected to a
DEMARC.
ONU X
D-ONU
(BB-ONU or S-ONU)
IEEE
802.1
Switch DEMARC MU
MI
Figure 6 - BB-ONU or S-ONU
Within the scope of this specification, the operations of the S-ONU and a BB-ONU are considered to be identical.
The operation of a BP-ONU requires additional specifications because a BP-ONU depends on the DEMARC for
electrical power, certain functions of the combined operations, and enabling of the pluggable (BP-ONU) interface.
Figure 7 shows the relationship between the DEMARC and the BP-ONU, together with the location of the MI
interface within the DEMARC.
ONU X
D-ONU
(BP-ONU)
IEEE
802.1
Switch MU
MI DEMARC
Figure 7 - BP-ONU

For example, the DEMARC can enable or disable the pluggable interface, configure BP-ONU transceiver
parameters, and read the current transceiver status information. Note that the [DPoE-OSSIv1.0] specification
specifically prohibits the configuration of the D-ONU from the UNI interface for CMCI or MU.
As shown in Figure 5, DAC requires a communication path between each DPoE Network element in sequence to
build an IP over Ethernet forwarding path to the DPoE System and ultimately to the OSS, required to retrieve the
DEMARC configuration file. The DPoE System, D-ONU, and DEMARC need to perform the following actions:
1. Initialize the DEMARC and the D-ONU.
2. Register and provision the D-ONU according to [DPoE-MULPIv1.0].
3. Transfer DAC-Path VLAN set to the DEMARC using [802.1AB] Link Layer Discovery Protocol (LLDP) PDUs
with DPoE extensions provided in Annex Aof this specification.
4. Use the acquired DAC-Path VLAN set to establish the DAC-Path to be used for IP-based DEMARC management
between the DEMARC and the OSS. The DAC-Path terminates at the IP router on the DPoE System. From there,
the DPoE System D interface provides IP forwarding from the DPoE System router to the OSS.
5. Perform IP network discovery and initialization on the DEMARC using DHCP over the DAC-Path. Included in
the options returned to the DEMARC is a set of parameters directing the DEMARC how to complete the next
phase of DAC.
6. The DEMARC requests the service configuration file using a file transfer protocol path from the location that was
specified in the received DHCP ACK options.
7. Upon receipt of the DEMARC configuration file, the DEMARC parses the configuration file and configures its
ports and services as specified in the configuration file.
This process is specified more fully in the following sections.
8.3 DAC DEMARC State Model

The DEMARC state model when executing the DAC procedure is shown in Figure 8. The state model is a reference
for describing the process and procedures required to accomplish the goal of discovering and provisioning
DEMARCs on the access network.
Figure 8 shows the flow diagram of the DAC process. Individual stages of the process are described in more detail.

Figure 8 - DAC DEMARC State Diagram
8.3.1 POWER_OFF State

The POWER_OFF state is the DEMARC’s initial state for the DAC process. The POWER_OFF state is reachable
via a global transition.
8.3.2 INIT State

The INIT state is reached when power is applied to the DEMARC or upon a commanded or un-commanded reboot.
The INIT state is reachable via a global transition.
In the INIT state the DEMARC executes POST and boots into its operating environment. If a BP-ONU is installed
in the DEMARC, the DEMARC initializes the BP-ONU per the procedures defined by [SFF-MSA] for pluggable
modules. No guarantee is provided that the D-ONU has or maintains connectivity to the DPoE Network when the
DEMARC enters into the INIT state or during the INIT state. Consequently, while the DEMARC is booting into its
operating environment it should not rely on the presence of an operational link to the access network.
Once the DEMARC reads, installs, and begins executing its locally stored configuration the INIT state is complete.
8.3.3 PRE_DAC State

In the PRE_DAC state the DEMARC operates according to the rules specified in the locally stored configuration. If
at any time an authorized third party modifies the running configuration, the DEMARC must continue operating
with the modified running configuration unless otherwise modified by the procedures of this state.
If an IP address was previously obtained via DHCP, the DEMARC MUST relinquish the lease for that IP address.
In the PRE_DAC state the DEMARC discovers the DAC-Path link configuration parameters.

The required DAC-Path VLAN set are transferred to the DEMARC via the Link Layer Discovery Protocol (LLDP)
as specified in [802.1AB], operating between the D-ONU and the DEMARC. The DEMARC MUST implement an
LLDP transmitter and receiver agent compliant with [802.1AB] to allow for bidirectional operation with a
corresponding LLDP agent in the D-ONU. The implemented LLDP agent receives LLDPDUs with the DAC-Path
VLAN set required to configure the DAC-Path. The structure of the LLDPDUs with DPoE extensions is provided in
Annex A of this specification.
Transferring the DAC-Path VLAN set from D-ONU to DEMARC may require more than one LLDPDU containing
DPoE extensions. Consequently, the DEMARC should not attempt communication on the DAC-Path until the
required DAC-Path VLAN set is received.
The DEMARC MUST transmit LLDPDUs with a source MAC address set to a 48-bit MAC Address associated with
the DEMARC chassis (referred to hereafter as the chassis MAC address).
Upon receipt of the DAC-Path VLAN set via the LLDP [802.1AB], the DEMARC transitions to the DAC_PATH
state.
8.3.4 DAC_PATH State

In the DAC_PATH state the DEMARC operates according to the rules specified in the locally stored configuration.
If at any time an authorized third party modifies the running configuration, the DEMARC must continue operating
with the modified running configuration unless otherwise modified by the procedures of this state.
In the DAC_PATH state the DEMARC further configures itself to use the DAC-Path for management
communication by using the DAC-Path VLAN set provided in the LLDPDU containing the DPoE extensions
outlined in Annex A of this specification. The presence of an LLDPDU with DPoE extensions is sufficient to:
1. Signal that DAC is enabled on the network
2. Convey to the DEMARC the DAC-Path VLAN set on which it must operate
Upon completion of DAC-Path configuration, the DEMARC MUST apply the DAC-Path VLAN set received from
the LLDP configuration to all frames on the DAC-Path. The DEMARC MUST NOT apply the DAC-Path VLAN set
to LLDPDUs exchanged between the DEMARC and D-ONU.
If the DEMARC is unable to configure itself to use the DAC-Path as described by the DAC-Path VLAN set, the
DEMARC transitions to the PRE_DAC state.
Once the DEMARC has successfully configured itself to use the DAC-Path, the DEMARC transitions to the DHCP
state.
8.3.5 DHCP State

In the DHCP state the DEMARC operates according to the rules specified in the locally stored configuration, plus
the modifications to support the DAC-Path. If at any time an authorized third party modifies the running
configuration, the DEMARC must continue operating with the modified running configuration unless otherwise
modified by the procedures of this state.
In the DHCP state the DEMARC begins executing the DHCP [RFC 2131] on the DAC-Path configured in the
DAC_PATH state.
When the DEMARC has received a complete set of IP operating parameters and next server information via the
DHCP protocol, and has reconfigured itself for operation using those parameters, the DEMARC transitions to the
CONFIG state.
If the DHCP fails for any reason, the DEMARC transitions back to the PRE_DAC state.
8.3.5.1 DHCP Requirements

The DEMARC MUST use DHCPv4 [RFC 2131] in order to obtain an IP address and other parameters needed to
establish IP connectivity with the OSS.

The DEMARC may receive multiple DHCPOFFER messages in response to its DHCPDISCOVER message. If a
received DHCPOFFER message does not include all of the required DHCPv4 fields and options as described in
Section 8.3.5.2, the DEMARC MUST discard the DHCPOFFER message and wait for another DHCPOFFER
message. If none of the received DHCPOFFER messages contain all the required DHCPv4 fields and options, the
DEMARC retransmits the DHCPDISCOVER message.
The backoff values for retransmission of DHCPDISCOVER messages SHOULD be chosen according to a uniform
distribution between the minimum and maximum values in the rows of Table 3.
Table 3 - Backoff values for retransmission of DHCPDISCOVER
Backoff Number Minimum (sec.) Maximum (sec.)

1 3 5
2 7 9
3 15 17
4 31 33
5 63 65
The DEMARC SHOULD implement a different retransmission strategy for the RENEWING and REBINDING
states, as recommended in [RFC 2131], which is based on one-half of the remaining lease time.
The DEMARC MUST limit the number of retransmissions to five or fewer for the DHCPDISCOVER and
DHCPREQUEST messages.
[RFC 3203] describes an extension to DHCPv4 that allows a DHCP server to send a FORCERENEW message
forcing a client to renew its DHCPv4 lease. The DEMARC MUST ignore all received FORCERENEW messages.
8.3.5.2 DHCPv4 Fields Used by the DEMARC4

The following fields MUST be present in the DHCPDISCOVER and DHCPREQUEST messages transmitted by the
DEMARC:
• The hardware type (htype) must be set to 1;
• The hardware length (hlen) must be set to 6;
• The client hardware address (chaddr) must be set equal to the DEMARC chassis MAC address.
• The DEMARC MUST have a chassis MAC address that is reachable via the DAC-Path.
• The DEMARC MUST have a chassis MAC address that is globally unique as specified in [802].
• The client identifier option must be included, using the format defined in [RFC 4361];
• The parameter request list option must be included. The following option codes (defined in [RFC2132] and
[RFC 4361]) must be included in the list:
• Option code 1 (Subnet Mask)
• Option code 2 (Time Offset)
• Option code 3 (Router Option)
• Option code 7 (Log Server Option)
• Option code 60 (Vendor Class Identifier) — the following ASCII-encoded string must be present in Option
code 60: ”demarc1.0”
4

• Option code 125 (DHCPv4 Vendor- Identifying Vendor Specific Information Options for DOCSIS 3.0
defined in [CANN DHCP-Reg] - and include the following sub-options:
• Sub-option code 1, the DHCPv4 Option Request option. The following option code must be included
in the DHCPv4 Option Request option:
• Sub-option code 2, DHCPv4 TFTP Servers Option.
• Option code 43 (Vendor Specific Information) with the following sub-options defined in [CANN-DHCP-
Reg]:
• Sub-option 2: Device Type – the following ASCII-encoded string must be present in sub-option 2:
“demarc”
• Sub-option 5: Hardware version
• Sub-option 4: Device Serial Number
• Sub-option 6: Software version
• Sub-option 7: Boot ROM version
• Sub-option 9: Model number
• Sub-option 10: Vendor name
The following fields are expected in the DHCPOFFER and DHCPACK messages returned to the DEMARC. The
DEMARC MUST configure itself with the listed fields from the DHCPACK:
• The IP address to be used by the DEMARC (yiaddr) (critical).
• The IP addresses of the TFTP servers for use in the next phase of the boot process (DHCPv4 TFTP Servers
option defined in [CANN DHCP-Reg] or siaddr) (critical).
• The name of the DEMARC configuration file to be read from the TFTP server by the DEMARC (file)
(critical).
• The subnet mask to be used by the DEMARC (Subnet Mask, option 1) (non-critical).
• The time offset of the DEMARC from UTC (Time Offset, option 2). This is used by the DEMARC to calculate
the reference time used in error logs (non-critical).
• A list of addresses of one or more routers to be used for forwarding IP traffic originating from the DEMARC's
IP stack (Router Option, option 3). The DEMARC is not required to use more than one router IP address for
forwarding (non-critical).
• A list of NTP servers from which the current time may be obtained (NTP Servers Option, option 42)
(noncritical).
• A list of syslog servers to which logging information may be sent (Log Server Option, option 7).
If a critical field is missing in the DHCPACK message or a field contains an invalid value, the DEMARC MUST:
1. Log an error;
2. Proceed as if the acquisition of the IPv4 address through DHCPv4 has failed and transition to the PRE_DAC
state; reference Figure 8.
If a non-critical field is missing in the DHCPACK message or a field contains an invalid, the DEMARC MUST log
a warning, ignore the field and continue the IPv4 provisioning process.
8.3.6 CONFIG State

Once the DEMARC completes the DHCP state, the DEMARC transitions to the CONFIG state.

In the CONFIG state the DEMARC continues operating per the rules configured in the PRE_DAC state. The
DEMARC also attempts to download a new configuration file identified by the set of DHCP options obtained in the
DHCP state. The DEMARC executes this procedure over the DAC-Path using the TFTP file transfer method.
If the file transfer experiences a timeout, the DEMARC retries per the rules specified by the file transfer protocol. If
the DEMARC exhausts its retry attempts the DEMARC transitions back to the PRE_DAC state. If the file download
process fails due to an explicit protocol error (file not found, failed authentication, etc.), the DEMARC transitions
back to the PRE_DAC state.
The CONFIG state is considered complete when the DEMARC successfully downloads the configuration file and
validates it. If the downloaded configuration file is invalid, the DEMARC returns to the PRE_DAC state. The
procedures for validating the configuration file are not specified in DPoE specifications.
The contents of the DEMARC configuration file downloaded by the DEMARC, and the process for generating the
configuration file, are outside the scope of DPoE specifications.
8.3.6.1 Establish Time of Day

The DEMARC acquires time of day for the purpose of time stamping warning and error logs and messages, and may
also acquire it for the correct operation of other services. The successful acquisition of time is not required for a
successful completion of the DAC process.
If NTP server option is provided in the DHCPOFFER or DHCPACK messages, the DEMARC MUST attempt to
obtain the current time of day by using the Network Time Protocol [RFC 5905].
The DEMARC MUST use its DHCP-provided IP address for exchange of messages with the NTP Server. The
DEMARC MUST transmit the request using UDP [RFC 768]. The DEMARC MUST listen for the response on the
same UDP port as is used to transmit the request. The DEMARC MUST combine the time retrieved from the server
(which is UTC) with the time offset received from the DHCP server to create a notional "local" time.
The DHCP server may return multiple IP addresses of NTP servers. The DEMARC MUST attempt to obtain time of
day from all the servers listed until it receives a valid response from any of the servers. The DEMARC MUST
contact the servers in batches of tries, with each batch consisting of one try per server and each successive try within
a batch at most one second later than the previous try and in the order listed by the DHCP message. If the DEMARC
fails to acquire time after any batch of tries, it MUST retry a similar batch using a truncated randomized binary
exponential backoff with an initial backoff of 1 second and a maximum backoff of 256 seconds.
If a DEMARC is unable to establish time of day using NTP for any reason the DEMARC MUST do the following:
• Log the failure in the local log and, if configured for it, to syslog and SNMP trap servers.
• Use the DEMARC internal clock time, if available, to set time of day
• If synchronization with time servers is unsuccessful and an internal clock is not available, the DEMARC
initializes the current time to Jan 1, 1970, 0h00.
If the DEMARC acquires the time of day from an NTP server, the DEMARC MUST continue NTP operation with
only the selected NTP server, unless any of its NTP related parameters (such as time offset or server address) are
modified. If the DEMARC’s NTP related parameters are modified, the DEMARC MAY reinitialize NTP operation
as described above. Note that other external specifications could require the DEMARC to perform this optional
function.
8.3.6.2 File Transfer Requirements

Independent of successful synchronization with an NTP server, DEMARC MUST attempt to download the
configuration file using the Trivial File Transfer Protocol (TFTP) ([RFC 1350]).
If there are one or more addresses in the DHCPv4 TFTP Servers option in the DHCPACK message, the DEMARC
MUST utilize addresses listed in this option sequentially to obtain a configuration file. If there are one or more
addresses in the DHCPv4 TFTP Servers option field, the DEMARC ignores the siaddr field. If there are no
addresses provided in the DHCPv4 TFTP Servers option in the DHCPACK, the DEMARC MUST use the address

in siaddr to obtain a configuration file. The DEMARC MUST use the bootfile field of the DHCPACK message to
identify the configuration file name to be downloaded.
The DEMARC observes the following guidelines below in order to obtain a configuration file from the TFTP server:
• The DEMARC MUST include the TFTP Blocksize option [RFC 2348] when requesting the configuration file.
• The DEMARC MUST request a blocksize of 1448 if using TFTP over IPv4.
• The DEMARC MUST initiate a configuration file download by sending a TFTP Read Request message for the
configuration file using the TFTP Server address(es) obtained in the TFTP Servers Option or siaddr, thus
establishing a connection with the server [RFC 1350]. When multiple TFTP Servers are present in the TFTP
Servers Option, the DEMARC progresses sequentially through the list of server IP addresses, attempting to
successfully download a configuration file from each IP address until the number of retries and backoffs are
exhausted for each of the server IP addresses.
• If the DEMARC receives no response to the TFTP Read Request message from the given TFTP server, the
DEMARC MUST resend the TFTP Read Request up to TFTP Request Retries limit as defined in Annex E.
• The DEMARC MUST use an adaptive timeout between retries based on a binary exponential backoff with an
initial backoff value of TFTP Backoff Start and final backoff value of TFTP Backoff End as defined in Annex
E.
• The DEMARC MUST log an event in the local log for each failed attempt.
• If the DEMARC receives no response to the TFTP Read Request after all of the TFTP Request Retries are
exhausted (see Annex E), the DEMARC MUST restart the configuration file download process on the next
server included in the list of servers.
• The DEMARC MUST attempt to download a configuration file from the first entry in the DHCPv4 TFTP
Servers option list and exhaust all backoffs and retries before moving to the next entry in the list until successful
reception of a configuration file.
• If the DEMARC receives an ICMP Destination Unreachable message for the current TFTP server at any time
during the configuration file download process, the DEMARC MUST terminate the configuration file download
from the particular TFTP server whose address is included in the ICMP Destination Unreachable message
without performing the TFTP Read Request Retries or the TFTP Download Retries (see Annex E). The
DEMARC MUST restart the configuration file download process on the next server included in the list of
servers.
• If the DEMARC reaches the end of the TFTP Server Addresses option list without a successful download of a
configuration file, the DEMARC MUST declare that IP Connectivity has failed and log an event.
When the DEMARC successfully downloads the configuration file, and the DEMARC validates the configuration
file using a vendor-specific validation method, the DEMARC transitions to the OPERATIONAL state.
8.3.7 OPERATIONAL State

In the OPERATIONAL state the DEMARC applies the downloaded configuration file to its current running
configuration. This results in a new running configuration.
In the OPERATIONAL state the DEMARC operates according to the rules specified by the downloaded
configuration file. If an authorized third party modifies the executing configuration, the DEMARC MUST operate
under the rules specified by the authorized third party.
The DEMARC MUST ignore any portion of the downloaded configuration file or subsequent configuration updates
by third parties that attempts to disable or alter operation of the DAC-Path.
8.3.7.1 DHCP Operation in the OPERATIONAL State

If the yiaddr field is missing or invalid in the DHCPACK message received during a renew or rebind operation, the
DEMARC MUST log an error and return to the DAC_PATH state with a DEMARC Initialization Reason of
BAD_DHCP_ACK.

If any other critical or non-critical field is missing or is invalid in the DHCPACK message received during a renew
or rebind operation, the DEMARC MUST log a warning, ignore the field if it is invalid, and remain operational.
8.3.7.1.1 Use of T1 and T2 Timers
The DEMARC MUST initiate the lease renewal process when timer DHCP-T1 expires.
The DEMARC MUST initiate the lease rebinding process when timer DHCP-T2 expires.
Timers DHCP-T1 and DHCP-T2 are called T1 and T2, respectively, in the DHCP specifications.
If the DHCP server sends a value for DHCP-T1 to the DEMARC in a DHCP message option, the DEMARC MUST
use that value. If the DHCP server does not send a value for DHCP-T1, the DEMARC MUST set DHCP-T1 to one
half of the duration of the lease [RFC 2131].
If the DHCP server sends a value for DHCP-T2 to the DEMARC in a DHCP message option, the DEMARC MUST
use that value. If the DHCP server does not send a value for DHCP-T2, the DEMARC MUST set DHCP-T2 to
seven-eighths of the duration of the lease [RFC 2131].
8.3.7.1.2 DHCPv4 Renew Fields Used by the DEMARC
It is possible during the DHCPv4 renew operation that the DEMARC will receive updated fields in the DHCPACK
message.
If any of the IP address (yiaddr), the Subnet Mask, or the Next Hop Router (router option) are different in the newly
received DHCPACK message than the values used currently by the DEMARC, the DEMARC MUST either:
• Change to using the new values without reinitializing itself, or
• Discontinue use of the IP parameters and transition to the DAC_PATH state
If the bootfile field or the SYSLOG server address are different in the newly received DHCPACK message than the
values currently used by the DEMARC, the DEMARC MUST ignore values in the new fields.
If the Time Offset value is different in the newly received DHCPACK message than the value used currently by the
DEMARC, the DEMARC MUST update its internal representation of time based on the new Time Offset value.
If the NTP Server address is different in the DHCPACK than the current value used by the DEMARC, the
DEMARC MUST update the NTP server address with the new value. This will cause the DEMARC to use the new
address(es) on future NTP requests (if any).
8.3.7.1.3 Post-registration Failures to Renew IP Addresses
If a DEMARC fails to renew its IP address, the DEMARC MUST log the event in the Local Event Log. A failure to
renew the IP address is a critical event. After logging the failure in the Local Event Log, the DEMARC MUST
discontinue the use of the IP parameters and transition to the DAC_PATH state.
8.3.8 Global transitions

The DAC state diagram in Figure 8 does not show a number of global transitions between states. A global transition
is a transition into one of the states under the set of specific conditions occurring when the DEMARC is in any of
the states shown in Figure 8. Such global transitions are described in more detail below:
• Transition to the POWER_OFF state: This global transition takes place from any other state, when power is
removed from the DEMARC.
• Transition to the INIT state: This global transition takes place from any other state except for the POWER_OFF
state, when the DEMARC is rebooted or reset in a commanded or uncommanded fashion.
• Transition to the DAC_PATH state: This global transition takes place from CONFIG, DAC_PATH, DHCP, and
OPERATIONAL states, when the DEMARC receives a DAC-Path VLAN set via [802.1AB] LLDP containing
parameters different than those previously received and stored at the DEMARC. The DEMARC continues
running the currently executing configuration.

8.3.9 General DEMARC Requirements

After transitioning to the DAC_PATH state and in all succeeding states, the DEMARC MUST NOT transmit a
DHCPDISCOVER message, DHCPREQUEST message, TFTP-RRQ message, HTTP Request message, or Time
Protocol Request message to any interface other than that associated with the DAC-Path.
Similarly, the DEMARC MUST NOT accept a DHCPOFFER message, DHCPREQUEST message, TFTP-DATA
message, HTTP Response message, or Time Protocol Response message from any interface other than that
associated with the DAC-Path. The DEMARC MUST provide the capability to disable DAC through the local
configuration.
When in any state, if an authorized third party makes changes to the DEMARC configuration, which they intend to
be in effect should the DEMARC reboot, it is up to the third party to ensure that the changes are stored in the DAC
configuration file for download upon DEMARC reboot.
8.4 DPoE ONU Detailed Description

Normal operation for a D-ONU involves registration with the DPoE System followed by the processing of a set of
extended OAM messages to configure functionality such as frame classification, allocation of LLID resources, and
frame encapsulation. The D-ONU then becomes operational - receiving frames on one or more S interfaces and
forwarding those frames upstream using the appropriate LLID, and also receiving frames on the PON port and
forwarding out the correct S interface. This register-configure-forward process is not unique to DAC but is followed
by all D-ONUs.
To support DAC the D-ONU also receives the relevant configuration file DAC TLVs from the DPoE System, and
then communicates the respective DAC-Path VLAN set to the DEMARC using the [802.1AB] LLDP. The D-ONU
MUST support the eOAM messages defined in Annex C of this specification to receive the DAC parameters from
the DPoE System. The DAC parameters received by the D-ONU from the DPoE System include the DAC-Path
VLAN set used to identify any management frames exchanged over the DAC-Path.
Using the object context mechanism, as described in [DPoE-OAMv1.0], the DAC parameters are configured on the
specific D-ONU S interface connected to the DEMARC. Once the D-ONU receives the DAC parameters and the
process is enabled for a particular S interface using the DAC Configuration Enable/Disable eOAM attribute, the D-
ONU communicates the DAC parameters to the connected DEMARC via the [802.1AB] LLDP.
The LLDP is defined in [802.1AB]. LLDP is a link-layer only protocol used by devices to advertise their capabilities
and identities to neighboring devices. [802.1AB] defines a method to define Organization-Specific Extensions for
the LLDP. This method allows any organization with a valid organizationally unique identifier (OUI) to design and
deploy organization-specific extensions, thereby expanding the original scope of the LLDP protocol. This
specification leverages the extensibility of the LLDP protocol by using the CableLabs OUI to expand the LLDP
message set to include DAC parameters and deliver them to the DEMARC. The specific LLDP extensions to
support the exchange of DAC parameters are defined in Annex A of this specification.
D-ONUs MUST implement both the receiver agent and transmitter agent as defined in [802.1AB] to allow for
bidirectional communication with the DEMARC. The D-ONU MUST transmit LLDPDUs with a destination MAC
address equal to the Nearest Bridge multicast MAC address 01-80-C2-00-00-0E.
The D-ONU LLDPDU transmission is an LLDPDU as defined in [802.1AB], section 9.1.2. The D-ONU LLDPDU
MUST include the [802.1AB] mandatory TLVs required in [802.1AB], section 8.2. The D-ONU MUST transmit
TLV with type value of 0x7F in the LLDPDU as specified in Annex A, on all MI interfaces configured to support
DAC. The D-ONU MUST ensure the interval between PDU transmissions complies with section 9.1.1 in
[802.1AB]. The D-ONU LLDPDU MUST be in a direct-encoded LLDP format. The D-ONU LLDPDU frame
header MUST NOT contain any [802.1Q], or [802.1AE] headers or tags as specified in [802.1AB]. The D-ONU
LLDPDU MUST NOT be encrypted or encapsulated in any way.
Once the D-ONU is configured with the DAC parameters the D-ONU begins sending LLDPDUs on any S interface
enabled for DAC operation by the DPoE System, presumably connected to a DEMARC. Each S interface enabled
for DAC operation communicates DAC configuration parameters separate and independent from any other S
interface. The advertisement of DAC parameters via LLDP on a DAC-enabled S interface is a continuous process.
As long as DAC is enabled on a particular S interface, the D-ONU MUST continue transmitting the required

LLDPDUs on the S interface connected to the DEMARC at least once every two (2) seconds. This continuous
transmission provides an indication to the DEMARC that the D-ONU is operational, and also provides LLDP
configuration information if the DEMARC reboots.
A DEMARC that supports DAC receives the LLDPDUs, retrieves the DAC-Path VLAN set from the LLDPDUs,
and configures itself as described elsewhere in this specification. It is expected that only a single DEMARC is
connected to any one S interface.
Independent of the D-ONU receiving the DAC parameters from the DPoE System for the purpose of transmitting
them to the DEMARC, the D-ONU is configured by the DPoE System to classify DEMARC management frames
and forward to the appropriate LLID resource. In other words, the D-ONU does not automatically configure itself to
bi-directionally forward DEMARC management frames. Rather, the DPoE System is responsible for configuring the
D-ONU with classifiers and LLID resources just like any other service configuration on a D-ONU using the
message contained in [DPoE-OAMv1.0].
8.5 DPoE System Detailed Description

When a D-ONU registers with a DPoE System an associated vCM is created that acts as a proxy for the D-ONU.
The vCM executes a series of provisioning steps including DHCP exchange followed by a download and parsing of
a CM configuration file and ending with the configuration of the D-ONU using the extended OAM messages
defined in [DPoE-OAMv1.0]. This process is followed for every D-ONU that is registered to the DPoE Network and
this process is unrelated to DAC support.
If the CM configuration file contains the DAC Encoding TLVs as listed in Annex B of this specification, the DPoE
System performs its role in the DAC process.
For each S interface of a D-ONU indicated for DAC support, the DPoE System dynamically generates a unique
DAC-Path VLAN set. The S-Tag is comprised of an S-VID selected from an operator-configured set of S-VIDs
referred to as the DAC Serving Group (DAC-SG). The DAC-SG may consist of one or more S-VIDs. The C-Tag is
comprised of a C-VID in the range 2-4094 selected such that each DAC-Path VLAN set uniquely identifies the
given DEMARC. The specific DAC-Path VLAN set selected by the DPoE System is ultimately delivered to the
DEMARC, which then tags all management frames exchanged over the DAC-Path with this specific DAC-Path
VLAN set. LLDPDUs are not considered as management frames and therefore are not tagged.
Once the DAC-Path VLAN set is selected by the DPoE System, the vCM configures the D-ONU to perform two
DAC-specific operations, as described in the following paragraphs.
From the perspective of the D-ONU, the DEMARC management frames resemble Metro Ethernet service frames
with service delimiting information equal to the DAC-Path VLAN set. This is because the DEMARC uses the
supplied DAC-Path VLAN set to tag all management frames destined for the service provider’s OSS. Therefore, the
vCM MUST configure the D-ONU with LLID resources, hereafter referred to as the DEMARC management LLID,
to classify and forward the DEMARC management frames. The vCM MUST also configure the D-ONU with
classifiers matching the corresponding DAC-Path VLAN set and forward matching frames to the aforementioned
DEMARC management LLID for transmission to the DPoE System. Similarly, the DPoE System MUST add the
appropriate DAC-Path VLAN set to management frames destined for a DEMARC and forward to the D-ONU
connected to the DEMARC using the corresponding DEMARC management LLID. This is equivalent to the vCM
configuring the D-ONU interface connected to the DEMARC to transport the frames belonging to the DEMARC
management VLAN. Extended OAM messages to support this configuration are defined in [DPoE-OAMv1.0].
The vCM MUST also configure the D-ONU with the DAC parameters for the purpose of transmitting these
parameters to the DEMARC. The parameters, including the DAC-Path VLAN set to be used by the DEMARC to tag
management frames exchanged over the DAC-Path, are provided to the D-ONU, along with identification of the S
interface on which DAC is intended to operate. Once the DAC parameters are provided to the D-ONU, the vCM
enables DAC for the D-ONU S interface on which DAC is intended to operate. The DPoE System MUST support
the eOAM messages defined in Annex Cof this specification to configure the D-ONU with DAC parameters.
When DAC is enabled on multiple S interfaces on a single D-ONU, the DPoE System MUST configure the D-ONU
to use the DEMARC management LLID to forward DAC-Path frames from all DEMARCs attached to the D-ONU.

In other words, a single DEMARC management LLID is used for all DEMARC DAC-Paths configured on the D-
ONU.
Once the DAC-Path is established between the DEMARC and the DPoE System, the DEMARC will execute the
DHCP process, as described elsewhere in this specification.
8.5.1 DPoE System DAC DHCP Relay Requirements

The DPoE System MUST provide a DHCP Relay Agent to relay DHCPDISCOVER and DHCPREQUEST
messages received from a DEMARC to a DHCP server. The DPoE System MUST insert the CMTS DOCSIS
Version Number option and DPoE System Version Number option as described in [CANN-DHCP-Reg] into all
DEMARC DHCP messages relayed from the DEMARC to the DHCP servers. These are the same option code TLVs
used for a vCM and defined in [CANN-DHCP-Reg].
In order to assist the DHCP server in differentiating between a DHCPDISCOVER message sent from a DEMARC
and a DHCPDISCOVER message sent from a CPE:
• The DPoE System DHCPv4 relay agent MUST support the DHCP Relay Agent Information Option (RAIO)
[RFC 3046]. Specifically, the DPoE System DHCPv4 relay agent MUST add an RAIO to the
DHCPDISCOVER message before relaying the message to a DHCP server. The RAIO MUST include in the
agent remote ID sub-option field [RFC 3046] the 48 bit MAC address of the D-ONU through which the
DHCPDISCOVER was bridged.
• The DPoE System DHCPv4 relay agent MUST use a giaddr field to differentiate between DEMARC and CPE
clients if they are to be provisioned in different IP subnets.
• DHCPv4 Relay Agent CMTS Capabilities option, containing the value "3.0" for the CMTS DOCSIS Version
Number [CANN-DHCP-Reg].
The DPoE System DHCPv4 relay agent MAY support the DHCP Relay Agent Service Class Information sub option
[CANN-DHCP-Reg].
The DPoE System MUST provide means to configure multiple DHCP servers specifically for the DAC DHCP
Relay Agent.
8.6 DAC Messaging Sequence

The diagram in Figure 9 provides a high level view of messaging that occurs during the DAC process.

Backend OSS
DPoE System DPoE ONU DEMARC
Systems
DPoE ONU Link Registration and
Critical OAM
vCM DHCP
TFTP Read Request for vCM Config File
DPoE OAM:
Based on vCM Configuration File Settings
Allocate S+C tags from

S-VID pool for DAC Serving Group
Configure D-ONU with classifiers
for DAC Management Path
Send DAC parameters and
Enable/Disable
DPoE OAM:
DAC Configuration Parameters (0xD7/0x800)
DAC Configuration Enable/Disable (0xD7/0x0803)
Based on OAM, start sending

LLDP on specified UNI
LLDP:
DPoE Version (Type 127/1)
DPoE Bridge Configuration (Type 127/2)
...
Based on Bridge Config, send

DHCP request using S+C tags
DEMARC DHCP
DHCP Relay
Send TFTP requests

using S+C tags
TFTP Read Request for DEMARC Config File
LLDP:
DPoE Version (Type 127/1)
DPoE Bridge Configuration (Type 127/2)
...
Figure 9 - High level DAC messaging sequence.

Annex A DPoE Extensions for LLDP

The D-ONU MUST transmit an LLDPDU with:
CableLabs OUI (0x001000)
TLV type value of 0x7F
TLV Length is variable depending on which optional fields are included.
Length = 4 bytes + X where X is the length of the 'information string' field
The 'information string' field carries the DPoE-specific parameters.
TLV type = 127 TLV size = 4+X OUI = 0x001000 Subtype = 0x01 Information string
7 bits 9 bits 3 bytes 1 byte X bytes
Figure 10 - DPoE-specific LLDPDU Structure
Table 4 indicates the required and optional values for the D-ONU and DEMARC LLDPDU for DPoE. Other
Subtype values are reserved for future use.
Table 4 - LLDPDU Vendor-specific (TLV 127) for DPoE with OUI (0x00-10-00)
Name Type Subtype Length Value Value Range

(bytes) (Int)
LLDP DPoE Version 127 1 2 See below na
DPoE Version (major) 1 1 0...15
DPoE Version (minor) 1 0 0…15
LLDP DPoE Bridge 127 2 9 See below See below
Configuration
Bridge Sub-Type 1 0 = [802.1ad]
S-Tag 4 DPoE System assigned S-Tag for in-band

DEMARC management from DPoE System
through D-ONU to DEMARC
C-Tag 4 DPoE System assigned C-Tag for in-band
DEMARC management from DPoE System
through D-ONU to DEMARC

Annex B CM Configuration File TLVs for DAC

B.1 DAC Disable/Enable Configuration 5
This parameter defines the DAC administrative configuration of the D-ONU port (s) associated with the MEF
service. For the D-ONU port associated with the MEF EPL service, this parameter controls the DAC for the given
port.
This TLV can be configured with value 0 or 1, where 0 is for Disabling the DAC, and 1 is for Enabling the DAC.
Without specifying this TLV, the DAC is disabled by default.
SubType Length Value
43.12.1 1 1 or 0
B.2 CM Interface Mask (CMIM) Encoding

The CM Interface Mask Encoding provides a bit mask representing the interfaces of the D-ONU for which DAC
applies. Each bit of the CM Interface Mask corresponds to an interface, logical or physical. By convention, bit
position 0 corresponds to the CM’s IP stack, even though it is not an actual interface. For each bit set in the CMIM
encoding, an instance of LLDP will execute, providing DAC-Path VLAN set information to a DEMARC.
For example, a CMIM intended to match all of the CPE ports (i.e., external interfaces) of a D-ONU has a CMIM
value setting bits 1 and 5-15, i.e., an encoding of either 0x47FF or 0x47FF0000. Either value is valid.
43.12.2 N BITS -Encoded bit map with bit position K representing
CM interface index value K. Bit position 0 is the most
significant bit of the most significant octet. Refer to
[eDOCSIS] for latest logical interface index assignments
for eCMs.
Bit 0 (0x80): CM’s IP stack
Bit 1 (0x40): primary CPE Interface (also ePS or
eRouter)
Bit 2 (0x20) RF interface
Bits 3,4 reserved
Bits 5..15 (0x07 FF) Other CPE Ports
Bits 16-31, embedded logical interfaces. Currently
defined interfaces include:
Bit 16 (0x00 00 80) PacketCable-eMTA
Bit 17 (0x00 00 40) eSTB-IP
Bit 18 (0x00 00 20) reserved
Bits 19..31 (0x00 00 1F FF) Other eSAFE interfaces
5

B.3 Upstream Service Class Name

The value of the field refers to a predefined DPoE System service configuration to be used for the upstream Service
Flow related to the DAC-Path. The Upstream Service Class Name used in a DAC Encoding indicates that all the
QoS Parameters for the related Service Flows need to be provided by the DPoE System. It is up to the operator to
synchronize the definition of Service Class Names in the DPoE System with the desired QoS.
43.12.3 2 TO 16 Zero-terminated string of ASCII characters.
NOTE: The length includes the terminating zero.
B.4 Downstream Service Class Name

The value of the field refers to a predefined DPoE System service configuration to be used for the downstream
Service Flow related to the DAC-Path. The Downstream Service Class Name used in a DAC Encoding indicates that
all the QoS Parameters for the related Service Flows need to be provided by the DPoE System. It is up to the
operator to synchronize the definition of Service Class Names in the DPoE System with the desired QoS.
43.12.4 2 TO 16 Zero-terminated string of ASCII characters.
NOTE: The length includes the terminating zero.
B.5 Examples of CM Configuration Files 6

This subclause provides two examples of CM configuration files with DAC enabled for different configurations, i.e.,
(a) where DEMARC is connected to the SFP-ONU – see Section B.5.1, and (b) where two DEMARCs are
connected to different ports on the S-ONU – see Section B.5.2. The examples show the structure of CM
configuration file TLV 43.12 and its sub-TLVs relative to the root of the CM configuration file, regardless of other
included CM configuration file TLVs.
B.5.1 A Single DEMARC Connected to the SFP-ONU

The CM configuration file for SFP-ONU connected to a DEMARC contains a single root-level TLV 43, which
contains a number of sub-TLVs, including a single instance of 43.12 TLV, with the DAC-specific sub-TLVs. Since
the SFP-ONU contains only a single S interface connected to the DEMARC, the CMIM value of 0x40-00-00-00 is
used. The DAC Service Class Names (SCN) of US-DAC-SCM for upstream and DS-DAC-SCM are used to
reference to SCN definitions assumed to be already configured on the DPoE System and containing QoS parameters
for DAC-Path.
│ Root of CM configuration file
// other TLVs and sub-TLVs
└TLV 43 (General Extension Information)
// other 43.x sub-TLVs
└TLV 43.12 (DAC Configuration)
├TLV 43.12.1 (DAC Disable/Enable Configuration), value “1”
├TLV 43.12.2 (CM Interface Mask (CMIM) Encoding), value “40 00 00 00”
├TLV 43.12.3 (Upstream Service Class Name), value “US-DAC-SCM”
└TLV 43.12.4 (Downstream Service Class Name), value “DS-DAC-SCM”
6

B.5.2 Two DEMARCs connected to the S-ONU

The CM configuration file for the S-ONU connected to two DEMARCs contains a single root-level TLV 43, which
contains a number of sub-TLVs, including a single instance of 43.12 TLV, with the DAC-specific sub-TLVs. Since
the S-ONU contains at least two S interfaces connected to two different DEMARCs, the CMIM value of 0x44-00-
00-00 is used, under the assumption that the first and second CPE interfaces on the S-ONU are connected to
DEMARCs. The DAC Service Class Names (SCN) of US-DAC-SCM for upstream and DS-DAC-SCM are used to
reference to SCN definitions assumed to be already configured on the DPoE System and containing QoS parameters
for DAC-Path. Note that both DAC-Paths share the same SCN configuration.
│ Root of CM configuration file
// other TLVs and sub-TLVs
└TLV 43 (General Extension Information)
// other 43.x sub-TLVs
└TLV 43.12 (DAC Configuration)
├TLV 43.12.1 (DAC Disable/Enable Configuration), value “1”
├TLV 43.12.2 (CM Interface Mask (CMIM) Encoding), value “44 00 00 00”
├TLV 43.12.3 (Upstream Service Class Name), value “US-DAC-SCM”
└TLV 43.12.4 (Downstream Service Class Name), value “DS-DAC-SCM”

Annex C L-OAMPDUs for LLDP

This annex contains attributes to support DEMARC devices subtended from a D-ONU.
C.1 DAC Configuration Parameters (0xD7/0x0800)

Objects: User Port
This attribute represents a set of DAC-related configuration parameters associated with the LLDP transmitter and
receiver agent operating on the given UNI port. This attribute must be associated with the User Port Object.
Table 5 - DAC Configuration Parameters
Size Name Description

4 S-Tag S-Tag value for DAC management traffic
4 C-Tag C-Tag value for DAC management traffic
C.2 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.
This attribute must be associated with the User Port Object.
Table 6 - DAC Configuration Enable / Disable
Size Description Units Default Min Max

1 LLDP instance status Boolean 0 0 1

Annex D IP Network Element Configuration Example

D.1 Example IP-SG Configuration for DAC
This informative section is based on the IP-SG and service class concepts described in [DPoE-IPNEv1.0].
interface tu0
bundle 1
!
interface tul
bundle 1
!
interface
tuN
bundle 1
!
interface bundle 1
description TU0-N
!
interface bundle 1.1
Description “[Example bundle configuration for DEMARC Auto Config (DAC)]”
s-vlan [1003]
bundle-type [dac]
ip address [x.x.x.x/y]
ip access-group [DACv4] inbound
ip access-group [DACv4] outbound
ipv6 address [FF00::X:X:X/Y]
ipv6 access-group [DACv6] inbound
ipv6 access-group [DACv6] outbound
dhcp server x.x.x.x
dhcp server y.y.y.y
!
D.2 DAC DHCP Relay Requirements

The DOCSIS service class configuration objects below are examples and are referenced from the DOCSIS config
file TLVs [43.12.3] and [43.12.4].
docsis service class 100

direction [upstream]
name “[DAC-upstream]”
polling-type [RTPS]
Max Sustained Traffic Rate [1mbps]
Max Traffic Burst [128KB]
!
docsis service class 101
direction [downstream]
name “[DAC-downstream]”
polling-type [RTPS]
Max Sustained Traffic Rate [1mbps]
Max Traffic Burst [128KB]
!

Annex E Parameters and Constants

System Name Parameter Description Minimum Default Maximum
Value Value Value
DEMARC TFTP Backoff Start Initial value for TFTP backoff 1 sec
DEMARC TFTP Backoff End Last value for TFTP backoff 16 sec
DEMARC TFTP Request Retries Number of retries on TFTP request 4
DEMARC TFTP Download Retries Number of retries on entire TFTP 3
downloads
DEMARC TFTP Wait The wait between TFTP retry sequences 3 min

Appendix I Acknowledgements
On behalf of our industry, we would like to thank the following individuals for their contributions to the
development of this specification.
Contributor Company Affiliation
John Dickinson, Edwin Mallette Bright House Networks
Paul Gray, Victor Hou Broadcom
Curtis Knittle CableLabs
Jimmy Hu Ciena
Tim Brophy Cisco Systems
Mehmet Toy, Shamim Akhtar Comcast
Mike Holmes, Wen Li, Jianhui Zhou, Fulin Pan Finisar
Victor Blake Independent Consultant
Robert Harris, Kevin A. Noll, Armin Sepehri Time Warner Cable
Marek Hajduczenia, Nevin Jones ZTE

Appendix II Revision History

II.1 Engineering Change for DPoE-SP-DEMARCv1.0-I02-130614
The following Engineering Change was incorporated into DPoE-SP-DEMARCv1.0-I02-130614:
ECN Date Accepted Summary Author
DEMARCv1.0-N-13.0084-1 06/06/2013 DEMARCv1.0 Overhaul Curtis Knittle

The following Engineering Changes were incorporated into DPoE-SP-DEMARCv1.0-I03-131114:
DEMARCv1.0-N-13.0100-1 8/15/2013 Add Serial Number to Vendor Specific Information Sent Kevin Noll
By DEMARC
DEMARCv1.0-N-13.0103-1 9/26/2013 Subtype formatting in B.1 in DPoE-SP-DEMARCv1 I02 Marek Hajduczenia
DEMARCv1.0-N-13.0107-2 10/3/2013 Examples of config files for DPoE-SP-DEMARCv1 I02 Marek Hajduczenia

The following Engineering Change was incorporated into DPoE-SP-DEMARCv1.0-I04-140807:
DEMARCv1.0-N-14.0167-1 7/10/2014 Alignment and cleanup of 802.3 references Marek Hajduczenia
__________________________


DPoE SP DEMARCv1.0 C01 160830 1

Uploaded by

Copyright:

Available Formats

DPoE SP DEMARCv1.0 C01 160830 1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

DPoE SP DEMARCv1.0 C01 160830 1

Uploaded by

Copyright:

Available Formats

DOCSIS® Provisioning of EPON Specifications

DPoE Demarcation Device Specification

This DPoE™ specification is the result of a cooperative effort

This document may contain references to other documents not owned

Document Status Sheet

Document Control Number: DPoE-SP-DEMARCv1.0-C01-160830

Document Title: DPoE Demarcation Device Specification

Revision History: I01 – Released 04/10/12

Date: August 30, 2016

Status: Work in Draft Issued Closed

Distribution Restrictions: Author CL/Member CL/ Member/ Public

Key to Document Status Codes

Draft A document in specification format considered largely complete, but lacking

B.1 DAC Disable/Enable Configuration ............................................................................................................ 40

1.1 Demarcation Device (DEMARC) Introduction

1.5 DPoE Version 1.0 Specifications

1.6 History of the DEMARC Specification

1.7 Reference Architecture

Figure 1 - DPoEv1.0 Reference Architecture

1.8 DPoE Interfaces and Reference Points

Figure 2 - DPoEv1.0 Interfaces and Reference Points

Table 2 - DPoEv1.0 Interface and Reference Point Descriptions

Interface or Interface or Reference Point Description

Interface or Interface or Reference Point Description

2.2 Informative References

2.3 Reference Acquisition

3 TERMS AND DEFINITIONS

Logical Used for DPoE Specifications

Used for DPoE Specifications

May be used for DPoE

Logical DPoE Elements

BP-ONU Bridge Pluggable ONUs

Figure 3 - D-ONU Types

Figure 4 - DPoE Network Elements

3.2 Other Terms1

1G-EPON EPON as first defined in [802.3ah], now part of [802.3].

4 ABBREVIATIONS AND ACRONYMS

BOOTP Bootstrap protocol

OLT Optical Line Termination

5 DEMARC IN THE DPOE NETWORK

5.2 DEMARC Interface Independence

6 DEMARC BASIC REQUIREMENTS

6.1 DPoE Metro Ethernet Service

6.2 IEEE Standards Requirements

6.3 Metro Ethernet Forum Standards

6.4 IP Network Element Requirements

7 IP MANAGEMENT FOR A DEMARC

8 DEMARC AUTO-CONFIGURATION (DAC)

8.2 DAC Architecture and Overview

8.3 DAC DEMARC State Model

Figure 8 - DAC DEMARC State Diagram

8.3.1 POWER_OFF State

8.3.2 INIT State

8.3.3 PRE_DAC State

8.3.4 DAC_PATH State

8.3.5 DHCP State

8.3.5.1 DHCP Requirements

Backoff Number Minimum (sec.) Maximum (sec.)

8.3.5.2 DHCPv4 Fields Used by the DEMARC4