<pre>Internet Engineering Task Force (IETF)                     N. Bitar, Ed.
Request for Comments: 6934                                       Verizon
Category: Informational                                   S. Wadhwa, Ed.
ISSN: 2070-1721                                           Alcatel-Lucent
                                                                 T. Haag
                                                        Deutsche Telekom
                                                                   H. Li
                                                     Huawei Technologies
                                                               June 2013


         <span class="h1">Applicability of the Access Node Control Mechanism to</span>
      <span class="h1">Broadband Networks Based on Passive Optical Networks (PONs)</span>

Abstract

   The purpose of this document is to provide applicability of the
   Access Node Control Mechanism to broadband access based on Passive
   Optical Networks (PONs).  The need for an Access Node Control
   Mechanism between a Network Access Server (NAS) and an Access Node
   Complex, composed of a combination of Optical Line Termination (OLT)
   and Optical Network Termination (ONT) elements, is described in a
   multi-service reference architecture in order to perform QoS-related,
   service-related, and subscriber-related operations.  The Access Node
   Control Mechanism is also extended for interaction between components
   of the Access Node Complex (OLT and ONT).  The Access Node Control
   Mechanism will ensure that the transmission of information between
   the NAS and Access Node Complex (ANX) and between the OLT and ONT
   within an ANX does not need to go through distinct element managers
   but rather uses direct device-to-device communication and stays on
   net.  This allows for performing access-link-related operations
   within those network elements to meet performance objectives.

Status of This Memo

   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Not all documents
   approved by the IESG are a candidate for any level of Internet
   Standard; see <a href="./rfc5741#section-2">Section&nbsp;2 of RFC 5741</a>.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   <a href="http://www.rfc-editor.org/info/rfc6934">http://www.rfc-editor.org/info/rfc6934</a>.



<span class="grey">Bitar, et al.                 Informational                     [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


Copyright Notice

   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   <a href="#section-1">1</a>. Introduction ....................................................<a href="#page-3">3</a>
   <a href="#section-2">2</a>. Terminology .....................................................<a href="#page-4">4</a>
   <a href="#section-3">3</a>. Motivation for Explicit Extension of ANCP to FTTx PON ...........<a href="#page-6">6</a>
   <a href="#section-4">4</a>. Reference Model for PON-Based Broadband Access Network ..........<a href="#page-7">7</a>
      <a href="#section-4.1">4.1</a>. Functional Blocks ..........................................<a href="#page-9">9</a>
           <a href="#section-4.1.1">4.1.1</a>. Home Gateway ........................................<a href="#page-9">9</a>
           <a href="#section-4.1.2">4.1.2</a>. PON Access ..........................................<a href="#page-9">9</a>
           <a href="#section-4.1.3">4.1.3</a>. Access Node Complex ................................<a href="#page-10">10</a>
           <a href="#section-4.1.4">4.1.4</a>. Access Node Complex Uplink to the NAS ..............<a href="#page-10">10</a>
           <a href="#section-4.1.5">4.1.5</a>. Aggregation Network ................................<a href="#page-10">10</a>
           <a href="#section-4.1.6">4.1.6</a>. Network Access Server ..............................<a href="#page-10">10</a>
           <a href="#section-4.1.7">4.1.7</a>. Regional Network ...................................<a href="#page-10">10</a>
      4.2. Access Node Complex Control Reference Architecture
           Options ...................................................<a href="#page-11">11</a>
           <a href="#section-4.2.1">4.2.1</a>. ANCP+OMCI ANX Control ..............................<a href="#page-11">11</a>
           <a href="#section-4.2.2">4.2.2</a>. All-ANCP ANX Control ...............................<a href="#page-12">12</a>
   <a href="#section-5">5</a>. Concept of Access Node Control Mechanism for PON-Based Access ..13
   <a href="#section-6">6</a>. Multicast ......................................................<a href="#page-16">16</a>
      <a href="#section-6.1">6.1</a>. Multicast Conditional Access ..............................<a href="#page-16">16</a>
      <a href="#section-6.2">6.2</a>. Multicast Admission Control ...............................<a href="#page-18">18</a>
      <a href="#section-6.3">6.3</a>. Multicast Accounting ......................................<a href="#page-30">30</a>
   <a href="#section-7">7</a>. Remote Connectivity Check ......................................<a href="#page-31">31</a>
   <a href="#section-8">8</a>. Access Topology Discovery ......................................<a href="#page-32">32</a>
   <a href="#section-9">9</a>. Access Loop Configuration ......................................<a href="#page-34">34</a>
   <a href="#section-10">10</a>. Security Considerations .......................................<a href="#page-34">34</a>
   <a href="#section-11">11</a>. Differences in ANCP Applicability between DSL and PON .........<a href="#page-35">35</a>
   <a href="#section-12">12</a>. ANCP versus OMCI between the OLT and ONT/ONU ..................<a href="#page-36">36</a>
   <a href="#section-13">13</a>. Acknowledgements ..............................................<a href="#page-37">37</a>
   <a href="#section-14">14</a>. References ....................................................<a href="#page-37">37</a>
      <a href="#section-14.1">14.1</a>. Normative References .....................................<a href="#page-37">37</a>
      <a href="#section-14.2">14.2</a>. Informative References ...................................<a href="#page-38">38</a>



<span class="grey">Bitar, et al.                 Informational                     [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>.  Introduction</span>

   Passive Optical Networks (PONs) based on Broadband PON (BPON)
   [<a href="#ref-G.983.1" title="&quot;Broadband optical access systems based on Passive Optical Networks (PON)&quot;">G.983.1</a>] and Gigabit PON (GPON) [<a href="#ref-G.984.1" title="&quot;Gigabit-capable Passive Optical Networks (GPON): General characteristics&quot;">G.984.1</a>] are being deployed across
   carrier networks.  There are two models for PON deployment: Fiber to
   the Building/Curb (FTTB/FTTC) and Fiber to the Premises (FTTP).  In
   the FTTB/C deployment, the last-mile connectivity to the subscriber
   premises is provided over the local copper loop, often using Very
   High Speed Digital Subscriber Line (VDSL).  In the FTTP case, PON
   extends to the premises of the subscriber.  In addition, there are
   four main PON technologies: (1) BPON, (2) GPON, (3) 10-Gigabit PON
   (XG-PON), and (4) Ethernet PON (EPON).  This document describes the
   applicability of the Access Node Control Protocol (ANCP) in the
   context of FTTB/C and FTTP deployments, focusing on BPON, GPON, and
   XG-PON.  Architectural considerations lead to different ANCP
   compositions.  Therefore, the composition of ANCP communication
   between Access Nodes (ANs) and Network Access Servers (NASs) is
   described using different models.

   BPON, GPON, and XG-PON in FTTP deployments provide large bandwidth in
   the first mile, bandwidth that is an order of magnitude larger than
   that provided by xDSL.  In the downstream direction, BPON provides
   622 Mbit/s per PON, GPON provides 2.4 Gbit/s, and XG-PON provides 10
   Gbit/s.

   In residential deployments, the number of homes sharing the same PON
   is limited by the technology and the network engineering rules.
   Typical deployments have 32-64 homes per PON.

   The motive behind BPON, GPON, and XG-PON deployment is to provide
   triple-play services over IP: voice, video, and data.  Voice is
   generally low bandwidth but has requirements for low delay, low
   jitter, and low packet loss.  Data services (e.g., Internet services)
   often require high throughput and can tolerate medium latency.  Data
   services may include multimedia content download such as video.
   However, in that case, the video content is not required to be real-
   time, and/or it is low-quality video.  Video services, on the other
   hand, are targeted to deliver Standard Definition or High Definition
   video content in real time or near real time, depending on the
   service model.  Standard Definition content using MPEG2 encoding
   requires on the order of 3.75 Mbit/s per stream while High Definition
   content using MPEG2 encoding requires 15-19 Mbit/s depending on the
   level of compression used.  Video services require low jitter and low
   packet loss with low start-time latency.  There are two types of
   video services: on demand and broadcast (known also as linear
   programming content).  While linear programming content can be
   provided over Layer 1 on the PON, the focus in this document is on




<span class="grey">Bitar, et al.                 Informational                     [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   delivering linear programming content over IP to the subscriber using
   IP multicast.  Video on Demand (VoD) is also considered for delivery
   to the subscriber over IP using a unicast session model.

   Providing simultaneous triple-play services over IP with unicast
   video and multicast video, VoIP, and data requires an architecture
   that preserves the quality of service of each service.  Fundamental
   to this architecture is ensuring that the video content (unicast and
   multicast) delivered to the subscriber does not exceed the bandwidth
   allocated to the subscriber for video services.  Architecture models
   often ensure that data is guaranteed a minimum bandwidth and that
   VoIP is guaranteed its own bandwidth.  In addition, QoS control
   across services is often performed at a Network Access Server (NAS),
   often referred to as Broadband Network Gateway (BNG) for subscriber
   management, per subscriber and shared link resources.  Efficient
   multicast video services require enabling multicast services in the
   access network between the subscriber and the subscriber management
   platform.  In the FTTP/B/C PON environment, this implies enabling IP
   multicast on the ANX composed of the Optical Network Terminal (ONT)
   or Unit (ONU) and Optical Line Terminal (OLT), as applicable.  This
   is as opposed to Digital Subscriber Line (DSL) deployments where
   multicast is enabled on the DSL Access Multiplexer (DSLAM) only.  The
   focus in this document will be on the ANCP requirements needed for
   coordinated admission control of unicast and multicast video in
   FTTP/B/C PON environments between the ANX and the NAS, specifically
   focusing on bandwidth dedicated for multicast and shared bandwidth
   between multicast and unicast.

   [<a id="ref-RFC5851">RFC5851</a>] provides the framework and requirements for coordinated
   admission control between a NAS and an AN with special focus on DSL
   deployments.  This document extends that framework and the related
   requirements to explicitly address PON deployments.

<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>.  Terminology</span>

   -  PON (Passive Optical Network) [<a href="#ref-G.983.1" title="&quot;Broadband optical access systems based on Passive Optical Networks (PON)&quot;">G.983.1</a>][G.984.1]: a point-to-
      multipoint FTTP network architecture in which unpowered splitters
      are used to enable the splitting of an optical signal from a
      central office on a single optical fiber to multiple premises.  Up
      to 32-128 may be supported on the same PON.  A PON configuration
      consists of an Optical Line Terminal (OLT) at the service
      provider's central office (CO) and a number of Optical Network
      Units or Terminals (ONUs/ONTs) near end users, with an Optical
      Distribution Network (ODN) composed of fibers and splitters
      between them.  A PON configuration reduces the amount of fiber and
      CO equipment required compared with point-to-point architectures.





<span class="grey">Bitar, et al.                 Informational                     [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   -  Access Node Complex (ANX): composed of two geographically
      separated functional elements -- OLT and ONU/ONT.  The general
      term Access Node Complex (ANX) will be used when describing a
      functionality that does not depend on the physical location but
      rather on the "black box" behavior of OLT and ONU/ONT.

   -  Optical Line Terminal (OLT): is located in the service provider's
      central office (CO).  It terminates and aggregates multiple PONs
      (providing fiber access to multiple premises or neighborhoods) on
      the subscriber side and interfaces with the Network Access Server
      (NAS) that provides subscriber management.

   -  Optical Network Terminal (ONT): terminates PON on the network side
      and provides PON adaptation.  The subscriber side interface and
      the location of the ONT are dictated by the type of network
      deployment.  For an FTTP deployment (with fiber all the way to the
      apartment or living unit), ONT has Ethernet (Fast Ethernet (FE) /
      Gigabit Ethernet (GE) / Multimedia over Coax Alliance (MoCA))
      connectivity with the Home Gateway (HGW) / Customer Premises
      Equipment (CPE).  In certain cases, one ONT may provide
      connections to more than one Home Gateway at the same time.

   -  Optical Network Unit (ONU): a generic term denoting a device that
      terminates any one of the distributed (leaf) endpoints of an
      Optical Distribution Network (ODN), implements a PON protocol, and
      adapts PON PDUs to subscriber service interfaces.  In the case of
      a multi-dwelling unit (MDU) or multi-tenant unit (MTU), a multi-
      subscriber ONU typically resides in the basement or a wiring
      closet (FTTB case) and has FE/GE/Ethernet over native Ethernet
      link or over xDSL (typically VDSL) connectivity with each CPE at
      the subscriber premises.  In the case where fiber is terminated
      outside the premises (neighborhood or curb side) on an ONT/ONU,
      the last-leg-premises connections could be via existing or new
      copper, with xDSL physical layer (typically VDSL).  In this case,
      the ONU effectively is a "PON-fed DSLAM".

   -  Network Access Server (NAS): network element that aggregates
      subscriber traffic from a number of ANs or ANXs.  The NAS is often
      an injection point for policy management and IP QoS in the access
      network.  It is also referred to as Broadband Network Gateway
      (BNG) or Broadband Remote Access Server (BRAS).

   -  Home Gateway (HGW): network element that connects subscriber
      devices to the AN or ANX and the access network.  In the case of
      xDSL, the Home Gateway is an xDSL network termination that could
      either operate as a Layer 2 bridge or as a Layer 3 router.  In the





<span class="grey">Bitar, et al.                 Informational                     [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


      latter case, such a device is also referred to as a Routing
      Gateway (RG).  In the case of PON, it is often a Layer 3 routing
      device with the ONT performing PON termination.

   -  PON-Customer-ID: identifier that uniquely identifies the ANX and
      the access loop logical port on the ANX to the subscriber
      (customer) premises and is used in any interaction between NAS and
      ANX that relates to access loops.  Logically, it is composed of
      information containing identification of the OLT (the OLT may be
      physically and directly connected to the NAS), the PON port on the
      OLT, the ONT/ONU, and the port on the ONT/ONU connecting to the
      subscriber HGW.  When acting as a DHCP relay agent, the OLT can
      encode PON-Customer-ID in the "Agent Circuit ID" sub-option in
      Option 82 of the DHCP messages [<a href="./rfc3046" title="&quot;DHCP Relay Agent Information Option&quot;">RFC3046</a>].

<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>.  Motivation for Explicit Extension of ANCP to FTTx PON</span>

   The fundamental difference between PON and DSL is that a PON is an
   optical broadcast network by definition.  That is, at the PON level,
   every ONT on the same PON sees the same signal.  However, the ONT
   filters only those PON frames addressed to it.  Encryption is used on
   the PON to prevent eavesdropping.

   The broadcast PON capability is very suitable for delivering
   multicast content to connected premises, maximizing bandwidth usage
   efficiency on the PON.  Similar to DSL deployments, enabling
   multicast on the Access Node Complex (ANX) provides for bandwidth use
   efficiency on the path between the Access Node and the NAS as well as
   improves the scalability of the NAS by reducing the amount of
   multicast traffic being replicated at the NAS.  However, the
   broadcast capability on the PON enables the AN (OLT) to send one copy
   on the PON as opposed to one copy to each receiver on the PON.  The
   PON multicast capability can be leveraged in the case of GPON and
   BPON as discussed in this document.

   Fundamental to leveraging the broadcast capability on the PON for
   multicast delivery is the ability to assign no key, a single
   encryption key for all PON frames carrying all multicast channels, or
   a key per set of multicast channels that correspond to a service
   package.  When supporting encryption for multicast channels, the
   encryption key is generated by the OLT and sent by the OLT to each
   targeted ONT via the ONT Management and Control Interface (OMCI) as
   described in <a href="#section-15.5.2">Section 15.5.2</a> of ITU-T G.987.3 [<a href="#ref-G.987.3" title="&quot;10-Gigabit-capable passive optical networks(XG-PON): Transmission convergence (TC) layer specification&quot;">G.987.3</a>] for XG-PON.
   It should be noted that the ONT can be a multi-dwelling unit (MDU)
   ONT with multiple Ethernet ports, each connected to a living unit.
   Thus, the ONT must not only be able to receive a multicast frame but
   must also be able to forward that frame only to the Ethernet port
   with receivers for the corresponding channel.



<span class="grey">Bitar, et al.                 Informational                     [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   In order to implement triple-play service delivery with necessary
   "quality-of-experience", including end-to-end bandwidth optimized
   multicast video delivery, there needs to be tight coordination
   between the NAS and the ANX.  This interaction needs to be near real-
   time as services are requested via application- or network-level
   signaling by broadband subscribers.  ANCP, as defined in [<a href="./rfc5851" title="&quot;Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks&quot;">RFC5851</a>]
   for DSL based networks, is very suitable to realize a control
   protocol (with transactional exchange capabilities) between the PON-
   enabled ANX and the NAS and also between the components comprising
   the ANX, i.e., between the OLT and the ONT.  Typical use cases for
   ANCP in the PON environment include the following:

   -  Access topology discovery
   -  Access loop configuration
   -  Multicast
      -  Optimized multicast delivery
      -  Unified video resource control
      -  NAS-based provisioning of ANX
   -  Remote connectivity check

<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>.  Reference Model for PON-Based Broadband Access Network</span>

   An overall end-to-end reference architecture of a PON access network
   is depicted in Figures 1 and 2 with ONT serving a single HGW, and
   ONT/ONU serving multiples HGWs, respectively.  An OLT may provide
   FTTP and FTTB/C access at the same time but most likely not on the
   same PON port.  Specifically, the following PON cases are addressed
   in the context of this reference architecture:

   -  BPON with Ethernet uplink to the NAS and ATM on the PON side
   -  GPON/XG-PON with Ethernet uplink to the NAS and Ethernet on the
      PON side

   In the case of an Ethernet aggregation network that supports new QoS-
   enabled IP services (including Ethernet multicast replication), the
   architecture builds on the reference architecture specified in the
   Broadband Forum (BBF) [<a href="#ref-TR-101" title="&quot;Migration to Ethernet-Based DSL Aggregation&quot;">TR-101</a>].  The Ethernet aggregation network
   between a NAS and an OLT may be degenerated to one or more direct
   physical Ethernet links.

   Given the industry move towards Ethernet as the new access and
   aggregation technology for triple-play services, the primary focus
   throughout this document is on GPON/XG-PON and BPON with Ethernet
   between the NAS and the OLT.







<span class="grey">Bitar, et al.                 Informational                     [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


                                          Access           Customer
                              &lt;---------Aggregation-------&gt;&lt;-Prem-&gt;
                                          Network           Network

                                       +------------------+
                                       |  Access Node     |
                                       |  Complex (ANX)   |
         +---------+   +---+  +-----+  |+---+       +---+ |  +---+
         |         | +-|NAS|--|Eth  |--||OLT|-&lt;PON&gt;-|ONT|-|--|HGW|
   NSP---+Regional | | +---+  |Agg  |  |+---+       +---+ |  +---+
         |Broadband| | +---+  +-----+  +------------------+
         |Network  |-+-|NAS|                  |
   ASP---+         | | +---+                  |
         |         | | +---+                  |
         +---------+ +-|NAS|                  |       +---+  +---+
                       +---|                  +-&lt;PON&gt;-|ONT|--|HGW|
                                                  |   +---+  +---+
                                                  |
                                                  |   +---+  +---+
                                                  +---|ONT|--|HGW|
                                                      +---+  +---+
         HGW      : Home Gateway
         NAS      : Network Access Server
         PON      : Passive Optical Network
         OLT      : Optical Line Terminal
         ONT      : Optical Network Terminal

                     Figure 1:  Access Network with PON























<span class="grey">Bitar, et al.                 Informational                     [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


                                                         FE/GE/VDSL
                                                         +---+ +---+
                                +----------------+       |   |-|HGW|
         +---------+   +-----+  | +-----+  +----+|       |   | +---+
         |         | +-|NAS  |--| |Eth  |--|OLT||-&lt;PON&gt;- |   |
   NSP---+Regional | | +-----+  | |Agg  |  |    ||     | |ONT| +---+
         |Broadband| |          | |     |  |    ||     | | or|-|HGW|
         |Network  | | +-----+  | +-----+  +----+|     | |ONU| +---+
         |         |-+-|NAS  |  +----------------+     | |   |
   ASP---+         | | +-----+                         | |   | +---+
         |         | | +-----+                         | |   |-|HGW|
         +---------+ +-|NAS  |                         | +---+ +---+
                       +-----+                         |
                                                       | +---+ +---+
                                                       +-|ONT|-|HGW|
                                                         +---+ +---+

   Figure 2: FTTP/FTTB/C with Multi-Subscriber ONT/ONU Serving MTUs/MDUs

   The following sections describe the functional blocks and network
   segments in the PON access reference architecture.

<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>.  Functional Blocks</span>

<span class="h4"><a class="selflink" id="section-4.1.1" href="#section-4.1.1">4.1.1</a>.  Home Gateway</span>

   The Home Gateway (HGW) connects the different CPEs to the ANX and the
   access network.  In the case of PON, the HGW is a Layer 3 router.  In
   this case, the HGW performs IP configuration of devices within the
   home via DHCP and performs Network Address and Port Translation
   (NAPT) between the LAN and WAN side.  In the case of FTTP/B/C, the
   HGW connects to the ONT/ONU over an Ethernet interface.  That
   Ethernet interface could be over an Ethernet physical port or over
   another medium.  In the case of FTTP, it is possible to have a single
   box GPON CPE solution where the ONT encompasses the HGW functionality
   as well as the GPON adaptation function.

<span class="h4"><a class="selflink" id="section-4.1.2" href="#section-4.1.2">4.1.2</a>.  PON Access</span>

   PON access is composed of the ONT/ONU and OLT.  PON ensures physical
   connectivity between the ONT/ONU at the customer premises and the
   OLT.  PON framing can be BPON or GPON.  The protocol encapsulation on
   BPON is based on multi-protocol encapsulation over ATM Adaptation
   Layer 5 (AAL5), defined in [<a href="./rfc2684" title="&quot;Multiprotocol Encapsulation over ATM Adaptation Layer 5&quot;">RFC2684</a>].  This covers PPP over Ethernet
   (PPPoE, defined in [<a href="./rfc2516" title="&quot;A Method for Transmitting PPP Over Ethernet (PPPoE)&quot;">RFC2516</a>]) or IP over Ethernet (IPoE).  The
   protocol encapsulation on GPON is always IPoE.  In all cases, the
   connection between the AN (OLT) and the NAS (or BNG) is assumed to be
   Ethernet in this document.



<span class="grey">Bitar, et al.                 Informational                     [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


<span class="h4"><a class="selflink" id="section-4.1.3" href="#section-4.1.3">4.1.3</a>.  Access Node Complex</span>

   The Access Node Complex (ANX) is composed of OLT and ONT/ONU and is
   defined in <a href="#section-2">Section 2</a>.

<span class="h4"><a class="selflink" id="section-4.1.4" href="#section-4.1.4">4.1.4</a>.  Access Node Complex Uplink to the NAS</span>

   The ANX uplink connects the OLT to the NAS.  The fundamental
   requirements for the ANX uplink are to provide traffic aggregation,
   Class of Service distinction, customer separation, and traceability.
   This can be achieved using an ATM or an Ethernet-based technology.
   As stated earlier, the focus in this document is on Ethernet.

<span class="h4"><a class="selflink" id="section-4.1.5" href="#section-4.1.5">4.1.5</a>.  Aggregation Network</span>

   The aggregation network provides traffic aggregation towards the NAS.
   The aggregation network is assumed to be Ethernet in this document.

<span class="h4"><a class="selflink" id="section-4.1.6" href="#section-4.1.6">4.1.6</a>.  Network Access Server</span>

   The NAS is a network device that aggregates multiplexed subscriber
   traffic from a number of ANXs.  The NAS plays a central role in per-
   subscriber policy enforcement and QoS.  It is often referred to as a
   Broadband Network Gateway (BNG) or Broadband Remote Access Server
   (BRAS).  A detailed definition of the NAS is given in [<a href="./rfc2881" title="&quot;Network Access Server Requirements Next Generation (NASREQNG) NAS Model&quot;">RFC2881</a>].  The
   NAS interfaces to the aggregation network by means of 802.1Q or 802.1
   Q-in-Q Ethernet interfaces and towards the Regional Network by means
   of transport interfaces (e.g., GigE, PPP over Synchronous Optical
   Network (SONET)).  The NAS functionality corresponds to the BNG
   functionality described in BBF TR-101 [<a href="#ref-TR-101" title="&quot;Migration to Ethernet-Based DSL Aggregation&quot;">TR-101</a>].  In addition, the NAS
   supports the Access Node Control functionality defined for the
   respective use cases in this document.

<span class="h4"><a class="selflink" id="section-4.1.7" href="#section-4.1.7">4.1.7</a>.  Regional Network</span>

   The Regional Network connects one or more NASs and associated access
   networks to Network Service Providers (NSPs) and Application Service
   Providers (ASPs).  The NSP authenticates access and provides and
   manages the IP address to subscribers.  It is responsible for overall
   service assurance and includes Internet Service Providers (ISPs).
   The ASP provides application services to the application subscriber
   (gaming, video, content on demand, IP telephony, etc.).  The NAS can
   be part of the NSP network.  Similarly, the NSP can be the ASP.








<span class="grey">Bitar, et al.                 Informational                    [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>.  Access Node Complex Control Reference Architecture Options</span>

   <a href="#section-3">Section 3</a> details the differences between xDSL access and PON access
   and the implication of these differences on DSLAM control versus OLT
   and ONT/ONU (ANX) control.  The following sections describe two
   reference models: (1) ANCP+OMCI ANX control and (2) All-ANCP ANX
   control.  That is, the two models differ in the ONT/ONU control
   within the ANX.  Choosing which model to implement may be based on
   the ONT/ONU type and the capabilities of the ONT/ONU and OLT; this is
   an implementation-specific decision that is outside the scope of this
   document.  It is possible for an OLT or an OLT PON port to connect to
   ONTs/ONUs with different capabilities and for these two models to co-
   exist on the same OLT and same PON.  <a href="#section-12">Section 12</a> describes the
   differences between OMCI and ANCP in controlling the ONU/ONT.

   OMCI is designed as a protocol between the OLT and ONT/ONU.  It
   enables the OLT to configure and administer capabilities on the
   ONT/ONU in BPON, GPON, and XG-PON.  ANCP is designed as a protocol
   between the NAS and Access Node.  Among other functions, it enables
   the NAS to enforce dynamic policies on the Access Node and the Access
   Node to report events to the NAS.

<span class="h4"><a class="selflink" id="section-4.2.1" href="#section-4.2.1">4.2.1</a>.  ANCP+OMCI ANX Control</span>

   Figure 3 depicts the reference model for ANCP+OMCI ANX control.  In
   this model, ANCP is enabled between the NAS and a connected OLT, and
   OMCI is enabled between the OLT and an attached ONT/ONU.  NAS
   communicates with the ANX via ANCP.  The OLT acts as an ANCP/OMCI
   gateway for communicating necessary events and policies between the
   OLT and ONT/ONU within the ANX and for communicating relevant
   policies and events between the ONT/ONU and the NAS.  The
   functionality performed by the OLT as an ANCP/OMCI gateway will be
   application dependent (e.g., multicast control, topology discovery)
   and should be specified in a related specification.  It should be
   noted that some applications are expected to require ANCP and/or OMCI
   extensions to map messages between OMCI and ANCP.  OMCI extensions
   are likely to be defined by the ITU-T.  It should also be noted that
   in addition to configuration and administration, OMCI provides the
   capability to report status changes on an ONT/ONU with AVC (Attribute
   Value Change) notifications.  When the ONT/ONU's DSL or Ethernet
   User-Network Interface (UNI) attributes change, a related Management
   Entity will send a corresponding notification (AVC) to the OLT.  The
   OLT interworks such a notification into an ANCP report and sends it
   to the connected NAS via the ANCP session between the OLT and the
   NAS.  As the ANCP report contains information of ONT/ONU's UNI and
   OLT's PON port, NAS can obtain accurate information of access
   topology.




<span class="grey">Bitar, et al.                 Informational                    [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


                                     +----------------------+
                                     |         ANX          |
         +---------+   +---+  +---+  |+---+       +-------+ | +---+
         |         | +-|NAS|--|Eth|--||OLT|-&lt;PON&gt;-|ONU/ONT|-|-|HGW|
   NSP---+Regional | | +---+  |Agg|  |+---+       +-------+ | +---+
         |Broadband| | +---+  +---+  +----------------------+
         |Network  |-+-|NAS|               |
   ASP---+         | | +---+               |
         |         | | +---+               |
         +---------+ +-|NAS|               |       +-------+ +---+
                       +---|               +-&lt;PON&gt;-|ONU/ONT|-|HGW|
                                                |  +-------+ +---+
                                                |  +---+     +---+
                                                +--|ONT|-----|HGW|
                                                   +---+     +---+
                              ANCP                 OMCI
                     +&lt;---------------&gt;+&lt;-----------&gt;+

      HGW: Home Gateway
      NAS: Network Access Server
      PON: Passive Optical Network
      OLT: Optical Line Terminal
      ONT: Optical Network Terminal
      ONU: Optical Network Unit

     Figure 3: Access Network with Single ANCP+OMCI Control

<span class="h4"><a class="selflink" id="section-4.2.2" href="#section-4.2.2">4.2.2</a>.  All-ANCP ANX Control</span>

   Figure 4 depicts the All-ANCP ANX control reference model.  In this
   model, an ANCP session is enabled between a NAS and a connected OLT,
   and another ANCP session is enabled between the OLT and a connected
   ONT/ONU.  ANCP enables communication of policies and events between
   the OLT and the ANX.  The OLT acts as a gateway to relay policies and
   events between the NAS and ONT/ONU within the ANX in addition to
   communicating policies and events between the OLT and ONT/ONU.  It
   should be noted that in this model, OMCI (not shown) is expected to
   be simultaneously enabled between the ONT and OLT, supporting
   existing OMCI capabilities and applications on the PON, independent
   of ANCP or applications intended to be supported by ANCP.











<span class="grey">Bitar, et al.                 Informational                    [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


                                     +----------------------+
                                     | Access Node Complex  |
                                     |      (ANX)           |
         +---------+   +---+  +---+  |+---+       +-------+ |  +---+
         |         | +-|NAS|--|Eth|--||OLT|-&lt;PON&gt;-|ONU/ONT| |--|HGW|
   NSP---+Regional | | +---+  |Agg|  |+---+       +-------+ |  +---+
         |Broadband| | +---+  +---+  +----------------------+
         |Network  |-+-|NAS|                |
   ASP---+         | | +---+                |
         |         | | +---+                |
         +---------+ +-|NAS|                |       +-------+  +---+
                       +---|                +-&lt;PON&gt;-|ONU/ONT|--|HGW|
                                                |   +-------+  +---+
                                                |
                                                |   +-------+  +---+
                                                +---|ONU/ONT|--|HGW|
                                                    +-------+  +---+

                              ANCP               ANCP
                     +&lt;-----------------&gt;+&lt;----------&gt;+

       HGW: Home Gateway
       NAS: Network Access Server
       PON: Passive Optical Network
       OLT: Optical Line Terminal
       ONT: Optical Network Terminal
       ONU: Optical Network Unit

              Figure 4:  All-ANCP ANX Control Reference Model

<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>.  Concept of Access Node Control Mechanism for PON-Based Access</span>

   The high-level communication framework for an Access Node Control
   Mechanism is shown in Figure 5 for the All-ANCP ANX control model.
   The Access Node Control Mechanism defines a quasi-real-time, general-
   purpose method for multiple network scenarios with an extensible
   communication scheme, addressing the different use cases that are
   described in the sections that follow.  The Access Node Control
   Mechanism is also extended to run between OLT and ONT/ONU.  The
   mechanism consists of a controller function and a reporting and/or
   enforcement function.  The controller function is used to receive
   status information or admission requests from the reporting function.
   It is also used to trigger a certain behavior in the network element
   where the reporting and/or enforcement function resides.

   The reporting function is used to convey status information to the
   controller function that requires the information for executing local
   functions.  The enforcement function can be contacted by the



<span class="grey">Bitar, et al.                 Informational                    [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   controller function to enforce a specific policy or trigger a local
   action.  The messages shown in Figure 5 show the conceptual message
   flow.  The actual use of these flows, and the times or frequencies
   when these messages are generated, depend on the actual use cases,
   which are described in later sections.

     +--------+
     | Policy |                               +----+
     | Server |                    +--&lt;PON&gt;---|ONT |------- HGW
     +--------+                   +           +----+  +---+
          |                      +         +----------|ONT|----HGW
          |                     +          |          +---+
          |               +----------------|-------------+
       +----+             | +----+         |     +-----+ |    +---+
       |NAS |---------------|    |         |     |     |-|----|HGW|
       |    |&lt;-------------&gt;|    |         |     | ONU | |    +---+
       +----+     ANCP    | |OLT |------&lt;PON&gt;----|     | |
          |               | |    |               |     | |    +---+
          |               | |    |&lt;-------------&gt;|     |------|HGW|
          |               | +----+    ANCP       +-----+ |    +---+
          |               +------------------------------+
          |                    |    Access Node      |
          | Control Request    |                     |
          | ------------------&gt;| Control Request     |
          |                    |--------------------&gt;|
          |                    | Control Response    |
          | Control Response   |&lt;------------------- |
          |&lt;-------------------|                     |
          |                    |Admission Request    |
          | Admission Request  |&lt;--------------------|
          |&lt;-------------------|                     |
          |Admission Response  |                     |
          |-------------------&gt;|Admission Response   |
          |                    |--------------------&gt;|
          |Information Report  |                     |
          |&lt;-------------------|                     |
          Access Node Control     Access Node Control
              Mechanism                Mechanism
          &lt;--------------------&gt;&lt;--------------------&gt;
                                 PPP, DHCP, IP
          &lt;------------------------------------------------------&gt;

    Figure 5: Conceptual Message Flow for Access Node Control Mechanism
                       in All-ANCP ANX Control Model







<span class="grey">Bitar, et al.                 Informational                    [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   As discussed previously, in different PON deployment scenarios, ANCP
   may be used in variant ways and may interwork with other protocols,
   e.g., OMCI.  In the ANCP+OMCI control model described earlier, the
   NAS maintains ANCP adjacency with the OLT while the OLT controls the
   ONT/ONU via OMCI.  The messages shown in Figure 6 show the conceptual
   message flow for this model.  The actual use of these flows, and the
   times or frequencies when these messages are generated, depend on the
   actual use cases.

     +--------+
     | Policy |
     | Server |
     +--------+                                  +---+        +---+
          |                                +---- |ONT|--------|HGW|
          |                                |     +---+        +---+
          |               +--------------- |-------------+
       +----+             | +----+         |     +-----+ |    +---+
       |NAS |---------------|    |         |     |     |-|----|HGW|
       |    |&lt;-------------&gt;|    |         |     | ONU | |    +---+
       +----+     ANCP    | |OLT |------&lt;PON&gt;----|     | |
          |               | |    |               |     | |    +---+
          |               | |    |&lt;-------------&gt;|     |------|HGW|
          |               | +----+    OMCI       +-----+ |    +---+
          |               +-----------------------------+
          |                    |    Access Node      |
          | Control Request    |                     |
          | ------------------&gt;| Control Request     |
          |                    |--------------------&gt;|
          |                    | Control Response    |
          | Control Response   |&lt;------------------- |
          |&lt;-------------------|                     |
          |                    |Admission Request    |
          | Admission Request  |&lt;--------------------|
          |&lt;-------------------|                     |
          |Admission Response  |                     |
          |-------------------&gt;|Admission Response   |
          |                    |--------------------&gt;|
          |Information Report  |                     |
          |&lt;-------------------|                     |
          Access Node Control     Operating Maintenance
              Mechanism          Control Interface (OMCI)
          &lt;--------------------&gt;&lt;--------------------&gt;

                                 PPP, DHCP, IP
          &lt;-------------------------------------------------------&gt;

    Figure 6: Conceptual Message Flow for ANCP+OMCI ANX Control Model




<span class="grey">Bitar, et al.                 Informational                    [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>.  Multicast</span>

   With the rise of supporting IPTV services in a resource-efficient
   way, multicast services are becoming increasingly important.

   In order to gain bandwidth optimization with multicast, the
   replication of multicast content per access loop needs to be
   distributed to the ANX.  This can be done by ANX (OLT and ONT/ONU)
   becoming multicast aware by implementing an IGMP [<a href="./rfc3376" title="&quot;Internet Group Management Protocol, Version 3&quot;">RFC3376</a>] snooping
   and/or proxy function [<a href="./rfc4605" title="&quot;Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding (&quot;">RFC4605</a>].  The replication thus needs to be
   distributed between NAS, aggregation nodes, and ANX.  In the case of
   GPON and in the case of BPON with Ethernet uplink, this is very
   viable.  By introducing IGMP processing on the ANX and aggregation
   nodes, the multicast replication process is now divided between the
   NAS, the aggregation node(s), and ANX.  This is in contrast to the
   ATM-based model where NAS is the single element responsible for all
   multicast control and replication.  In order to ensure backward
   compatibility with the ATM-based model, the NAS, aggregation node,
   and ANX need to behave as a single logical device.  This logical
   device must have exactly the same functionality as the NAS in the ATM
   access/aggregation network.  The Access Node Control Mechanism can be
   used to make sure that this logical/functional equivalence is
   achieved by exchanging the necessary information between the ANX and
   the NAS.

   An alternative to multicast awareness in the ANX is for the
   subscriber to communicate the IGMP "join/leave" messages with the
   NAS, while the ANX is being transparent to these messages.  In this
   scenario, the NAS can use ANCP to create replication state in the ANX
   for efficient multicast replication.  The NAS sends a single copy of
   the multicast stream towards the ANX.  The NAS can perform network-
   based conditional access and multicast admission control on multicast
   joins and create replication state in the ANX if the request is
   admitted by the NAS.

   The following sections describe various use cases related to
   multicast.

<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>.  Multicast Conditional Access</span>

   In a broadband FTTP/B/C access scenario, service providers may want
   to dynamically control, at the network level, access to some
   multicast flows on a per user basis.  This may be used in order to
   differentiate among multiple Service Offers or to realize/reinforce
   conditional access based on customer subscription.  Note that, in
   some environments, application-layer conditional access by means of
   Digital Rights Management (DRM), for instance, may provide sufficient
   control so that network-based multicast conditional access may not be



<span class="grey">Bitar, et al.                 Informational                    [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   needed.  However, network-level access control may add to the service
   security by preventing the subscriber from receiving a non-subscribed
   channel.  In addition, it enhances network security by preventing a
   multicast stream from being sent on a link or a PON based on a non-
   subscriber request.

   Where network-based channel conditional access is desired, there are
   two approaches.  First, it can be done on the NAS along with
   bandwidth-based admission control.  The NAS can control the
   replication state on the ANX based on the outcome of access and
   bandwidth-based admission control.  This is covered in a later
   section.  A second approach is to provision the necessary conditional
   access information on the ANX (ONT/ONU and/or OLT) so the ANX can
   perform the conditional access decisions autonomously.  For these
   cases, the NAS can use ANCP to provision black and white lists as
   defined in [<a href="./rfc5851" title="&quot;Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks&quot;">RFC5851</a>] on the ANX so that the ANX can decide locally to
   honor a join or not.  It should be noted that in the PON case, the
   ANX is composed of the ONT/ONU and OLT.  Thus, this information can
   be programmed on the ONT/ONU and/or OLT.  Programming this
   information on the ONT/ONU prevents illegitimate joins from
   propagating further into the network.  A third approach, outside of
   the scope of this document, may be to program the HGW with the access
   list.  A white list associated with an Access Port identifies the
   multicast channels that are allowed to be replicated to that port.  A
   black list associated with an Access Port identifies the multicast
   channels that are not allowed to be replicated to that port.  It
   should be noted that the black list, if not explicitly programmed, is
   the complement of the white list and vice versa.

   If the ONT/ONU performs IGMP snooping and is programmed with a
   channel access list, the ONT/ONU will first check if the requested
   multicast channel is part of a white list or a black list associated
   with the Access Port on which the IGMP join is received.  If the
   channel is part of a white list, the ONT/ONU will pass the join
   request upstream towards the NAS.  The ONT/ONU must not start
   replicating the associated multicast stream to the Access Port if
   such a stream is received until it gets confirmation that it can do
   so from the upstream node (NAS or OLT).  Passing the channel access
   list is one of the admission control criteria whereas bandwidth-based
   admission control is another.  If the channel is part of a black
   list, the ONT/ONU can autonomously discard the message because the
   channel is not authorized for that subscriber.

   The ONT/ONU, in addition to forwarding the IGMP join, sends an ANCP
   admission request to the OLT identifying the channel to be joined and
   the premises.  Premises identification to the OLT can be based on a
   Customer-Port-ID that maps to the Access Port on the ONT/ONU and is
   known at the ONT/ONU and OLT.  If the ONT/ONU has a white list and/or



<span class="grey">Bitar, et al.                 Informational                    [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   a black list per premises, the OLT need not have such a list.  If the
   ONT/ONU does not have such a list, the OLT may be programmed with
   such a list for each premises.  In the latter case, the OLT would
   perform the actions described earlier on the ONT/ONU.  Once the
   outcome of admission control (conditional access and bandwidth-based
   admission control) is determined by the OLT (either by interacting
   with the NAS or locally), it is informed to the ONT/ONU.  OLT
   bandwidth-based admission control scenarios are defined in a later
   section.

   The white list and black list can contain entries allowing:

   -  An exact match for a (*,G) Any-Source Multicast (ASM) group (e.g.,
      &lt;G=g.h.i.l&gt;)

   -  An exact match for a (S,G) Source-Specific Multicast (SSM) channel
      (e.g., &lt;S=s.t.u.v,G=g.h.i.l&gt;)

   -  A mask-based range match for a (*,G) ASM group (e.g.,
      &lt;G=g.h.i.l/Mask&gt;)

   -  A mask-based range match for a (S,G) SSM channel (e.g.,
      &lt;S=s.t.u.v,G=g.h.i.l/Mask&gt;)

   The use of a white list and black list may be applicable, for
   instance, to regular IPTV services (i.e., Broadcast TV) offered by an
   Access Provider to broadband (e.g., FTTP) subscribers.  For this
   application, the IPTV subscription is typically bound to a specific
   FTTP home, and the multicast channels that are part of the
   subscription are well-known beforehand.  Furthermore, changes to the
   conditional access information are infrequent, since they are bound
   to the subscription.  Hence, the ANX can be provisioned with the
   conditional access information related to the IPTV service.

   Instead of including the channel list(s) at the ONT/ONU, the OLT or
   NAS can be programmed with these access lists.  Having these access
   lists on the ONT/ONU prevents forwarding of unauthorized joins to the
   OLT or NAS, reducing unnecessary control load on these network
   elements.  Similarly, performing the access control at the OLT
   instead of the NAS, if not performed on the ONT/ONU, will reduce
   unnecessary control load on the NAS.

<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>.  Multicast Admission Control</span>

   The successful delivery of triple-play broadband services is quickly
   becoming a big capacity-planning challenge for most of the service
   providers nowadays.  Solely increasing available bandwidth is not
   always practical, cost-economical, and/or sufficient to satisfy end-



<span class="grey">Bitar, et al.                 Informational                    [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   user experience given not only the strict QoS requirements of unicast
   applications like VoIP and Video on Demand but also the fast growth
   of multicast interactive applications such as "video conferencing",
   digital TV, and digital audio.  These applications typically require
   low delay, low jitter, low packet loss, and high bandwidth.  These
   applications are also typically "non-elastic", which means that they
   operate at a fixed bandwidth that cannot be dynamically adjusted to
   the currently available bandwidth.

   An Admission Control (AC) Mechanism covering admission of multicast
   traffic for the FTTP/B/C access is required in order to avoid over-
   subscribing the available bandwidth and negatively impacting the end-
   user experience.  Before honoring a user request to join a new
   multicast flow, the combination of ANX and NAS must ensure admission
   control is performed to validate that there is enough video bandwidth
   remaining on the PON and on the uplink between the OLT and NAS to
   carry the new flow (in addition to all other existing multicast and
   unicast video traffic) and that there is enough video bandwidth for
   the subscriber to carry that flow.  The solution needs to cope with
   multiple flows per premises and needs to allow bandwidth to be
   dynamically shared across multicast and unicast video traffic per
   subscriber, PON, and uplink (irrespective of whether unicast AC is
   performed by the NAS or by some off-path policy server).  It should
   be noted that the shared bandwidth between multicast and unicast
   video is under operator control.  That is, in addition to the shared
   bandwidth, some video bandwidth could be dedicated to Video on
   Demand, while other video bandwidth could be dedicated for multicast.

   The focus in this document is on multicast-allocated bandwidth
   including the shared unicast and multicast bandwidth.  Thus,
   supporting admission control requires some form of synchronization
   between the entities performing multicast AC (e.g., the ANX and/or
   NAS), the entity performing unicast AC (e.g., the NAS or a policy
   server), and the entity actually enforcing the multicast replication
   (i.e., the NAS and the ANX).  This synchronization can be achieved in
   a number of ways.

   One approach is for the NAS to perform bandwidth-based admission
   control on all multicast video traffic and unicast video traffic that
   requires using the shared bandwidth with multicast.  Based on the
   outcome of admission control, NAS then controls the replication state
   on the ANX.  The subscriber generates an IGMP join for the desired
   stream on its logical connection to the NAS.  The NAS terminates the
   IGMP message and performs conditional access and bandwidth-based
   admission control on the IGMP request.  The bandwidth admission
   control is performed against the following:





<span class="grey">Bitar, et al.                 Informational                    [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   1.  Available video bandwidth on the link to OLT

   2.  Available video bandwidth on the PON interface

   3.  Available video bandwidth on the last mile (Access Port on the
       ONT/ONU)

   The NAS can locally maintain and track video bandwidth it manages for
   all the three levels mentioned above.  The NAS can maintain
   identifiers corresponding to the PON interface and the last mile
   (customer interface).  It also maintains a channel map, associating
   every channel (or a group of channels sharing the same bandwidth
   requirement) with a data rate.  For instance, in the case of 1:1 VLAN
   representation of the premises, the outer tag (S-VLAN) could be
   inserted by the ANX to correspond to the PON interface on the OLT,
   and the inner-tag could be inserted by the ANX to correspond to the
   access-line towards the customer.  Bandwidth tracking and maintenance
   for the PON interface and the last mile could be done on these VLAN
   identifiers.  In the case of N:1 representation, the single VLAN
   inserted by ANX could correspond to the PON interface on the OLT.
   The access loop is represented via Customer-Port-ID received in the
   "Agent Circuit ID" sub-option in DHCP messages.

   The NAS can perform bandwidth accounting on received IGMP messages.
   The video bandwidth is also consumed by any unicast video being
   delivered to the CPE.  NAS can perform video bandwidth accounting and
   control on both IGMP messages and on requests for unicast video
   streams when either all unicast admission control is done by the NAS
   or an external policy server makes a request to the NAS for using
   shared bandwidth with multicast as described later in the document.

   This particular scenario assumes the NAS is aware of the bandwidth on
   the PON and can track the changes in available bandwidth on the PON
   under all conditions.  On receiving an IGMP join message, NAS will
   perform bandwidth check on the subscriber bandwidth.  If this passes
   and the stream is already being forwarded on the PON by the OLT
   (which also means that it is already forwarded by the NAS to the
   OLT), NAS will admit the join, update the available subscriber
   bandwidth, and transmit an ANCP message to the OLT and in turn to the
   ONT/ONU to start replication on the customer port.  If the stream is
   not already being replicated to the PON by the OLT, the NAS will also
   check the available bandwidth on the PON, and if it is not already
   being replicated to the OLT, it will check the bandwidth on the link
   towards the OLT.  If this passes, the available PON bandwidth and the
   bandwidth on the link towards the OLT are updated.  The NAS adds the
   OLT as a leaf to the multicast tree for that stream.  On receiving
   the message to start replication, the OLT will add the PON interface
   to its replication state if the stream is not already being forwarded



<span class="grey">Bitar, et al.                 Informational                    [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   on that PON.  Also, the OLT will send an ANCP message to direct the
   ONT/ONU to add or update its replication state with the customer port
   for that channel.  The interaction between ANX and NAS is shown in
   Figures 7 and 8.  For unicast video streams, application-level
   signaling from the CPE typically triggers an application server to
   request bandwidth-based admission control from a policy server.  The
   policy server can, in turn, interact with the NAS to request the
   bandwidth for the unicast video flow if it needs to use shared
   bandwidth with multicast.  If the bandwidth is available, NAS will
   reserve the bandwidth; update the bandwidth pools for subscriber
   bandwidth, the PON bandwidth, and the bandwidth on the link towards
   the OLT; and send a response to the policy server, which is
   propagated back to the application server to start streaming.
   Otherwise, the request is rejected.





































<span class="grey">Bitar, et al.                 Informational                    [Page 21]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-22" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


                                                    +----+
                                +---&lt;PON&gt;---------- |ONT |------ HGW
                               +                    +----+
                              +                     +----+
                             +           +--------- |ONT |------ HGW
     +----+               +----+        +           +----+
     |NAS |---------------|    |------&lt;PON&gt;
     |    |&lt;-------------&gt;|    |        +           +-----+
     +----+     ANCP      |OLT |         +--------- |     |----- HGW
       |                  |    |                    |     |
       |                  |    |&lt;------------------&gt;| ONU |------HGW
       |                  +----+    ANCP            |     |     +---+
       |                     |                      |     |-----|HGW|
       |                     |                      +-----+     +---+
       |           1.IGMP join (S/*,G)               |              |
       |&lt;---------------------------------------------------------- |
     2.|                     |                       |              |
     +=======================+                       |              |
     [Access Control &amp;       ]                       |              |
     [Subscriber B/W         ]                       |              |
     [PON B/W &amp; OLT link B/W ]                       |              |
     [based Admission Control]                       |              |
     +=======================+                       |              |
       |                     |                       |              |
       |-------------------&gt; |                       |              |
     3.ANCP Replication-Start|                       |              |
       (&lt;S/*,G&gt; or Multicast |                       |              |
       |MAC,Customer-Port-ID)| --------------------&gt; |              |
       |                     |4.ANCP Replication-Start              |
       |                  (&lt;S/*,G&gt; or Multicast MAC,Customer-Port-ID)
       |-------------------&gt; |                       |              |
       |5.Multicast Flow(S,G)|                       |              |
       |on Multicast VLAN    |---------------------&gt; |              |
       |                     |6.Multicast Flow (S,G) |              |
       |                     |forwarded on           |              |
       |                     |Unidirectional         |              |
       |                     |&lt;Multicast GEM-PORT&gt;   |              |
       |                     |on the PON by OLT      |-------------&gt;|
                                                     7.Multicast Flow
                                                    forwarded on    |
                                                    Customer-Port by|
                                                     |ONT/OLT.      |
                                                     |              |

     Figure 7: Interactions for NAS-Based Multicast Admission Control
       (No IGMP Processing on ANX and NAS Maintains Available Video
                   Bandwidth for PON) upon Channel Join




<span class="grey">Bitar, et al.                 Informational                    [Page 22]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-23" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


                                                    +----+
                                +---&lt;PON&gt;---------- |ONT |----- HGW
                               +                    +----+
                              +                     +----+
                             +           +--------- |ONT |----- HGW
     +----+               +----+        +           +----+
     |NAS |---------------|    |------&lt;PON&gt;
     |    |&lt;-------------&gt;|    |        +           +-----+
     +----+     ANCP      |OLT |         +--------- |     |---- HGW
       |                  |    |                    |     |
       |                  |    |&lt;------------------&gt;| ONU |-----HGW
       |                  +----+    ANCP            |     |     +---+
       |                     |                      |     |-----|HGW|
       |                     |                      +-----+     +---+
       |                     |                       |              |
       |            IGMP leave (S/*,G)               |              |
       |&lt;-----------------------------------------------------------|
       |                     |                       |              |
     +====================+  |                       |              |
     [Admission Control   ]  |                       |              |
     [&lt;Resource Released&gt; ]  |                       |              |
     +====================+  |                       |              |
       |                     |                       |              |
       |                     |                       |              |
       |                     |                       |              |
       |-------------------&gt; |                       |              |
      ANCP Replication-Stop  |                       |              |
       (&lt;S/*,G&gt; or Multicast MAC,Customer-Port-ID)   |              |
       |                     |                       |              |
       |                     |---------------------&gt; |              |
       |                     | ANCP Replication-Stop |              |
                         (&lt;S/*,G&gt; or Multicast MAC,Customer-Port-ID)

     Figure 8: Interactions for NAS-Based Multicast Admission Control
       (No IGMP Processing on ANX and NAS Maintains Available Video
                   Bandwidth for PON) upon Channel Leave

   An alternate approach is required if the NAS is not aware of the
   bandwidth on the PON.  In this case, the OLT does the PON bandwidth
   management and requests NAS to perform bandwidth admission control on
   subscriber bandwidth and the bandwidth on the link to the OLT.
   Following are operations of various elements:

   ANX operation:

   -  ONT/ONU can snoop IGMP messages.  If conditional access is
      configured and the channel is in the black list (or it is not on
      the white list), ONT will drop the IGMP join.  If the channel



<span class="grey">Bitar, et al.                 Informational                    [Page 23]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-24" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


      passes the conditional access check, the ONT will forward the IGMP
      join and will send a bandwidth admission control request to the
      OLT.  If the multicast stream is already being received on the
      PON, the ONT/ONU does not forward the stream to the Access Port
      where IGMP is received until it has received a positive admission
      control response from the OLT.

   -  OLT can snoop IGMP messages.  It also receives a bandwidth
      admission control request from the ONT/ONU for the requested
      channel.  It can be programmed with a channel bandwidth map.  If
      the multicast channel is already being streamed on the PON or the
      channel bandwidth is less than the available multicast bandwidth
      on the PON, the OLT forwards the IGMP request to the NAS and keeps
      track of the subscriber (identified by Customer-Port-ID) as a
      receiver.  If the channel is not already being streamed on the PON
      but the PON has sufficient bandwidth for that channel, the OLT
      reduces the PON multicast video bandwidth by the channel bandwidth
      and may optionally add the PON to the multicast tree without
      activation for that channel.  This is biased towards a forward
      expectation that the request will be accepted at the NAS.  The OLT
      forwards the IGMP join to the NAS.  It also sends a bandwidth
      admission request to the NAS identifying the channel and the
      premises for which the request is made.  It sets a timer for the
      subscriber multicast entry within which it expects to receive a
      request from the NAS that relates to this request.  If the
      available PON bandwidth is less than the bandwidth of the
      requested channel, the OLT sends an admission response (with a
      reject) to the ONT/ONU and does not forward the IGMP join to the
      NAS.

   NAS operation:

   The NAS receives the IGMP join from the subscriber on the subscriber
   connection.  When NAS receives the admission control request from ANX
   (also signifying the bandwidth on the PON is available), it performs
   admission control against the subscriber's available multicast
   bandwidth.  If this check passes, and the NAS is already transmitting
   that channel to the OLT, the request is accepted.  If the check
   passes and the NAS is not transmitting the channel to the OLT yet, it
   performs admission control against the available multicast video
   bandwidth (this includes the dedicated multicast bandwidth and the
   shared bandwidth between multicast and Video on Demand) on the
   link(s) to the OLT.  If the check passes, the request is accepted,
   the available video bandwidth for the subscriber and downlink to the
   OLT are reduced by the channel bandwidth, and the NAS sends an ANCP
   admission control response (indicating accept) to the OLT, requesting
   the addition of the subscriber to the multicast tree for that
   channel.  The OLT activates the corresponding multicast entry if not



<span class="grey">Bitar, et al.                 Informational                    [Page 24]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-25" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   active and maintains state of the subscriber in the list of receivers
   for that channel.  The OLT also sends an ANCP request to the ONT/ONU
   to enable reception of the multicast channel and forwarding to the
   subscriber Access Port.  Otherwise, if the request is rejected, the
   NAS will send an admission reject to the OLT, which, in turn, removes
   the subscriber as a receiver for that channel (if it was added) and
   credits back the channel bandwidth to the PON video bandwidth if
   there is no other receiver on the PON for that channel.  The
   interactions between ANX and NAS are shown in Figures 9 and 10.

   If the OLT does not receive a response from the NAS within a set
   timer, the OLT removes the subscriber from the potential list of
   receivers for the indicated channel.  It also returns the allocated
   bandwidth to the available PON bandwidth if there are no other
   receivers.  In this case, the NAS may send a response to the OLT with
   no matching entry as the entry has been deleted.  The OLT must
   perform admission control against the available PON bandwidth and may
   accept the request and send an ANCP request to the ONT/ONU to
   activate the corresponding multicast entry as described earlier.  If
   it does not accept the request, it will respond back to the NAS with
   a reject.  The NAS shall credit back the channel bandwidth to the
   subscriber.  It shall also stop sending the channel to the OLT if
   that subscriber was the last leaf on the multicast tree towards the
   OLT.

   On processing an IGMP leave, the OLT will send an ANCP request to NAS
   to release resources.  NAS will release the subscriber bandwidth.  If
   this leave causes the stream to be no longer required by the OLT, the
   NAS will update its replication state and release the bandwidth on
   the NAS to OLT link.

   If the subscriber makes a request for a unicast video stream (i.e.,
   Video on Demand), the request results in appropriate application-
   level signaling, which typically results in an application server
   requesting a policy server for bandwidth-based admission control for
   the VoD stream.  After authorizing the request, the policy server can
   send a request to the NAS for the required bandwidth if it needs to
   use bandwidth that is shared with multicast.  This request may be
   based on a protocol outside of the scope of this document.  The NAS
   checks if the available video bandwidth (accounting for both
   multicast and unicast) per subscriber and for the link to the OLT is
   sufficient for the request.  If it is, it temporarily reserves the
   bandwidth and sends an ANCP admission request to the OLT for the
   subscriber, indicating the desired VoD bandwidth.  If the OLT has
   sufficient bandwidth on the corresponding PON, it reserves that
   bandwidth and returns an accept response to the NAS.  If not, it
   returns a reject to the NAS.  If the NAS receives an accept, it
   returns an accept to the policy server, which, in turn, returns an



<span class="grey">Bitar, et al.                 Informational                    [Page 25]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-26" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   accept to the application server, and the video stream is streamed to
   the subscriber.  This interaction is shown in Figure 11.  If the NAS
   does not accept the request from the policy server, it returns a
   reject.  If the NAS receives a reject from the OLT, it returns the
   allocated bandwidth to the subscriber and the downlink to the OLT.

   It should be noted that similar functionality to that described in
   this section and depicted in Figures 9, 10, and 11 will be required
   when OMCI is enabled between the OLT and ONT/ONU in the ANCP+OMCI ANX
   control model.  In the latter case, the OLT will act as an ANCP-OMCI
   gateway.








































<span class="grey">Bitar, et al.                 Informational                    [Page 26]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-27" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


                                                   +----+
                                         +-------- |ONT |-------- HGW
     +----+               +----+         +         +----+
     |NAS |---------------|    |------&lt;PON&gt;
     |    |&lt;-------------&gt;|OLT |         +          +-----+
     +----+     ANCP      |    | ANCP    +--------- | ONU |------ HGW
       |                  +----+&lt;------------------&gt;+-----+-------HGW
       |                     |                        |             |
       |1.IGMP join(S/*,G) +=============+         +=============+  |
       |&lt;------------------[IGMP Snooping]---------[IGMP snooping]--|
       |                   +=============+         +=============+  |
       |                     |2.Admission-Request     |             |
       |                     |(Flow,Customer-Port-ID) |             |
       |                     |&lt;---------------------- |             |
       |                3.+===============+           |             |
       |                  [ Access Ctrl   ]           |             |
       |                  [ &amp; PON B/W     ]           |             |
       |                  [ Admission Ctrl]           |             |
       |                  +===============+ PASS      |             |
       |4.Admission-Request  |                        |             |
       | &lt;Flow,              |                        |             |
       |  Customer-Port-ID&gt;  |                        |             |
       |&lt;--------------------|                        |             |
     5.|                     |                        |             |
     +=================+     |                        |             |
     [Subscriber B/W   ]     |                        |             |
     [&amp; OLT link B/W   ]     |                        |             |
     [Admission Ctrl   ]     |                        |             |
     +=================+PASS |                        |             |
       |6.Admission-Reply-Pass                        |             |
       |&lt;Flow,Customer-Port-ID&gt;                       |             |
       |--------------------&gt;|                        |             |
       |            7.+========================+      |             |
       |              [Update Replication State]      |             |
       |              +========================+      |             |
       |                     | 8.Admission-Reply-Pass |             |
       |                     |(&lt;Flow,Cust-Port-ID&gt;    |             |
       |                     |----------------------&gt; |             |
       |                     |                 9.+============+     |
       |                     |                   [Update Repl.]     |
       |                     |                   [   State    ]     |
       |                     |                   +============+     |

      Figure 9: Interaction between NAS &amp; ANX for Multicast Bandwidth
     Admission Control in the All-ANCP ANX Control Model upon Success






<span class="grey">Bitar, et al.                 Informational                    [Page 27]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-28" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


                                                    +----+
                                         +--------- |ONT |------ HGW
     +----+               +----+        +           +----+
     |NAS |---------------|    |------&lt;PON&gt;
     |    |&lt;-------------&gt;|OLT |        +          +-----+
     +----+     ANCP      |    | ANCP   +----------| ONU |----- HGW
       |                  +----+&lt;-----------------&gt;+-----+------HGW
       |                     |                        |             |
       |1.IGMP join(S/*,G) +=============+        +=============+   |
       |&lt;------------------[IGMP Snooping]--------[IGMP snooping]-- |
       |                   +=============+        +=============+   |
       |                     |2.Admission-Request     |             |
       |                     |(Flow,Customer-Port-ID) |             |
       |                     |&lt;---------------------- |             |
       |                2.+===============+           |             |
       |                  [ Access Ctrl   ]           |             |
       |                  [ &amp; PON B/W     ]           |             |
       |                  [ Admission Ctrl]           |             |
       |                  +===============+ PASS      |             |
       |3.Admission-Request  |                        |             |
       | &lt;Flow,Customer-Port-ID&gt;                      |             |
       |&lt;--------------------|                        |             |
     4.|                     |                        |             |
     +==================+    |                        |             |
     [Subscriber B/W    ]    |                        |             |
     [&amp; OLT link B/W    ]    |                        |             |
     [Admission Ctrl    ]    |                        |             |
     +==================+FAIL                         |             |
       |                     |                        |             |
       |5.Admission-Reply-Fail                        |             |
       |&lt;Flow,Cust-Port-ID&gt;  |                        |             |
       |--------------------&gt;|                        |             |
       |            6.+==================+            |             |
       |              [Release PON B/W   ]            |             |
       |              [Remove Repl.State ]            |             |
       |              +==================+            |             |
       |                     | 7.Admission-Reply-Fail |             |
       |                     |&lt;Flow,Cust-Port-ID&gt;     |             |
       |                     |----------------------&gt; |             |
       |                     |                 8.+============+     |
       |                     |                   [Remove Repl.]     |
       |                     |                   [   State    ]     |
       |                     |                   +============+     |

    Figure 10: Interaction between NAS and ANX for Multicast Bandwidth
     Admission Control in the All-ANCP ANX Control Model upon Failure





<span class="grey">Bitar, et al.                 Informational                    [Page 28]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-29" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


     +------------+              1. VoD Request
     | App. Server|&lt;-----------------------------------------------
     | Server     |
     +------------+
       | 2. Admission-Request (VoD-Flow)
     +-------+
     |Policy |
     |Server |
     +-------+
      |  +
      |&lt;-|---3. Admission-Request
      |  |
      +  | 8. Admission-Reply
     +----+        +      +----+                  +-----+
     |NAS |---------------|OLT |------&lt;PON&gt;-------|ONT  |---HGW--CPE
     |    |&lt;-------------&gt;|    |                  +-----+    |
     +----+     ANCP      +----+                      |      |
       |                     |                        |      |
     4.|                     |                        |      |
     +=================+     |                        |      |
     [Subscriber B/W   ]     |                        |      |
     [&amp; OLT link B/W   ]     |                        |      |
     [Admission Ctrl   ]     |                        |      |
     +=================+PASS |                        |      |
       |                     |                        |      |
       | 5.Admission-Request |                        |      |
       |(Bandwidth,PON-Port-ID)                       |      |
       |-------------------&gt; |                        |      |
       |                     |                        |      |
       |                6.+===============+           |      |
       |                  [   PON B/W     ]           |      |
       |                  [ Admission Ctrl]           |      |
       |                  +===============+ PASS      |      |
       |7.Admission-Reply    |                        |      |
       | &lt;PON-Port-ID&gt;       |                        |      |
       |&lt;------------------- |                        |      |
       |                     |                        |      |

        Figure 11: Interactions for VoD Bandwidth Admission Control
                     in the All-ANCP ANX Control Model

   A third possible approach is where the ANX is assumed to have full
   knowledge to make an autonomous decision on admitting or rejecting a
   multicast and a unicast join.  With respect to the interaction
   between ONT/ONU and OLT, the procedure is similar to the first
   approach (i.e., NAS-controlled replication).  However, when the OLT
   receives an IGMP request from a subscriber, it performs admission
   control against that subscriber multicast video bandwidth (dedicated



<span class="grey">Bitar, et al.                 Informational                    [Page 29]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-30" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   and shared with Video on Demand), the PON, and uplink to the NAS.  It
   should be noted in this case that if there are multiple NAS-OLT
   links, either the link on which the multicast stream must be sent is
   pre-determined, needs to be selected by the OLT based on downstream
   bandwidth from NAS to OLT and the selection is communicated to the
   NAS, or the OLT has to be ready to receive the stream on any link.
   If the check passes, the OLT updates the available video bandwidth
   per PON and subscriber.  The OLT adds the subscriber to the list of
   receivers and the PON to the multicast tree if it is not already on
   it.  It also sends an ANCP request to the ONT/ONU to add the
   subscriber Access Port to that channel multicast tree and sends an
   ANCP message to the NAS informing it of the subscriber and link
   available video bandwidth and the channel the subscriber joined.  The
   NAS, upon receiving the ANCP information message, updates the
   necessary information, including the OLT to the multicast tree if it
   is not already on it.  It should be noted in this case that the ANCP
   message from the OLT to the NAS is being used to add the OLT to a
   multicast tree as opposed to an IGMP message.  The IGMP message can
   also be sent by the OLT with the OLT acting as an IGMP proxy at the
   expense of added messages.  In this option, the OLT acts as the
   network IGMP router for the subscriber.

   For unicast video streams, the policy server receiving an admission
   request from an application server, as described before, may query
   the OLT for admission control as it has all information.  If the OLT
   has sufficient bandwidth for the stream, it reserves that bandwidth
   for the subscriber, the PON, and OLT uplink to the NAS and returns an
   accept to the policy server.  It also updates the NAS (via an ANCP
   message) of the subscriber's available video bandwidth.  If the OLT
   rejects the policy server request, it will return a reject to the
   policy server.

   It should be noted that if the policy server adjacency is with the
   NAS, the policy server may make the admission request to the NAS.
   The NAS then sends an ANCP admission request to the OLT on behalf of
   the policy server.  The NAS returns an accept or reject to the policy
   server if it gets a reject or accept, respectively, from the OLT.

<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>.  Multicast Accounting</span>

   It may be desirable to perform accurate time- or volume-based
   accounting per user or per access loop.  If the ANX is performing the
   traffic replication process, it knows when replication of a multicast
   flow to a particular Access Port or user starts and stops.  Multicast
   accounting can be addressed in two ways:






<span class="grey">Bitar, et al.                 Informational                    [Page 30]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-31" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   -  ANX keeps track of when replication starts or stops and reports
      this information to the NAS for further processing.  In this case,
      ANCP can be used to send the information from the ANX to the NAS.
      This can be done with the Information Report message.  The NAS can
      then generate the appropriate time and/or volume accounting
      information per access loop and per multicast flow to be sent to
      the accounting system.  The ANCP requirements to support this
      approach are specified in [<a href="./rfc5851" title="&quot;Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks&quot;">RFC5851</a>].  If the replication function
      is distributed between the OLT and ONT/ONU, a query from the NAS
      will result in OLT generating a query to the ONT/ONU.

   -  ANX keeps track of when replication starts or stops and generates
      the time- and/or volume-based accounting information per access
      loop and per multicast flow, before sending it to a central
      accounting system for logging.  Since ANX communicates with this
      accounting system directly, the approach does not require the use
      of ANCP.  It is therefore beyond the scope of this document.  It
      may also be desirable for the NAS to have the capability to
      asynchronously query the ANX to obtain an instantaneous status
      report related to multicast flows currently replicated by the ANX.
      Such a reporting functionality could be useful for troubleshooting
      and monitoring purposes.  If the replication function in the ANX
      is distributed between the OLT and the ONT/ONU, then for some of
      the information required by the NAS (such as the list of Access
      Ports on which a flow is being forwarded or list of flows being
      forwarded on an Access Port), a query to the OLT from the NAS will
      result in a query from the OLT to the ONT/ONU.  The OLT responds
      back to the NAS when it receives the response from the ONT/ONU.
      Also, if the list of PONs on which replication is happening for a
      multicast channel or the list of channels being replicated on a
      PON is what is desired, the OLT can return this information.

<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>.  Remote Connectivity Check</span>

   In an end-to-end Ethernet aggregation network, end-to-end Ethernet
   Operations, Administration, and Maintenance (OAM), as specified in
   IEEE 802.1ag [<a href="#ref-802.1ag" title="&quot;Connectivity Fault Management&quot;">802.1ag</a>] and ITU-T Recommendation Y.1730/1731 [<a href="#ref-Y.1731" title="&quot;OAM functions and mechanisms for Ethernet based networks&quot;">Y.1731</a>],
   can provide access loop connectivity testing and fault isolation.
   However, most HGWs do not yet support these standard Ethernet OAM
   procedures.  Also, in a mixed Ethernet and ATM access network (e.g.,
   Ethernet-based aggregation upstream from the OLT and BPON
   downstream), interworking functions for end-to-end OAM are not yet
   standardized or widely available.  Until such mechanisms become
   standardized and widely available, the Access Node Control Mechanism
   between NAS and ANX can be used to provide a simple mechanism to test
   connectivity of an access loop from the NAS.





<span class="grey">Bitar, et al.                 Informational                    [Page 31]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-32" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   Triggered by a local management interface, the NAS can use the Access
   Node Control Mechanism (Control Request message) to initiate an
   access loop test between an Access Node and a HGW or ONT/ONU.  On
   reception of the ANCP message, the OLT can trigger native OAM
   procedures defined for BPON in [<a href="#ref-G.983.1" title="&quot;Broadband optical access systems based on Passive Optical Networks (PON)&quot;">G.983.1</a>] and for GPON in [<a href="#ref-G.984.1" title="&quot;Gigabit-capable Passive Optical Networks (GPON): General characteristics&quot;">G.984.1</a>].
   The Access Node can send the result of the test to the NAS via a
   Control Response message.

<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>.  Access Topology Discovery</span>

   In order to avoid congestion in the network, manage and utilize the
   network resources better, and ensure subscriber fairness, NAS
   performs hierarchical shaping and scheduling of the traffic by
   modeling different congestion points in the network (such as the last
   mile, Access Node uplink, and the access-facing port).

   Such mechanisms require that the NAS gains knowledge about the
   topology of the access network, the various links being used, and
   their respective rates.  Some of the information required is somewhat
   dynamic in nature (e.g., DSL line rate if the last mile is xDSL
   based, such as in the case of "PON-fed DSLAMs" for FTTC/FTTB
   scenarios) and hence cannot come from a provisioning and/or inventory
   management Operations Support System (OSS).  Some of the information
   varies less frequently (e.g., capacity of the OLT uplink) but
   nevertheless needs to be kept strictly in sync between the actual
   capacity of the uplink and the image the NAS has of it.

   OSSs are rarely able to enforce the consistency of such data in a
   reliable and scalable manner, notably across organizational
   boundaries under certain deployment scenarios.  The Access Topology
   Discovery function allows the NAS to perform these advanced functions
   without having to depend on an error-prone and possibly complex
   integration with an OSS.

   The rate of the access loop can be communicated via ANCP (Information
   Report message) from the ONT/ONU to the OLT in the All-ANCP ANX
   control model or via OMCI in the ANCP+OMCI ANX control model, and
   then from OLT to the NAS via ANCP.  Additionally, during the time the
   DSL NT is active, data rate changes can occur due to environmental
   conditions (the DSL access loop can get "out of sync" and can retrain
   to a lower value, or the DSL access loop could use Seamless Rate
   Adaptation to make the actual data rate fluctuate while the line is
   active).  In this case, ANX sends an additional Information Report to
   the NAS each time the access loop attributes change above a threshold
   value.  Existing DSL procedures are not applicable in this case
   because an adapted message flow and additional TLVs are needed.





<span class="grey">Bitar, et al.                 Informational                    [Page 32]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-33" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


     +--------+
     | Policy |
     | Server |
     +--------+                                        +---+   +---+
          |                                +-----------|ONT|---|HGW|
          |                                |           +---+   +---+
          |               +--------------- |-----------------+
       +----+             | +----+         |         +-----+ | +---+
       |NAS |------------ | |    |         |         |     |-|-|HGW|
       |    |&lt;----------&gt; | |    |         |         |ONT/ | | +---+
       +----+     ANCP    | |OLT |------&lt;PON&gt;--------|ONU  | |
          |               | |    |                   |     | | +---+
          |               | |    |&lt;-----------------&gt;|     |---|HGW|
          |               | +----+       OMCI        +-----+ | +---+
          |               +----------------------------------+
          |                    |      Access Node       |
          |                    |                        |
          |                    |------GPON Ranging------|
          | Port Status Message|      ONT Port UP       |
          |&lt;------------------ |&lt;-----------------------|
          |Port Configuration  GPON Line/Service Profile|
          |------------------&gt; |&lt;----------------------&gt;|
          |     ONT/ONI Port UP|                        |
          |&lt;------------------ |                        |
          |                    |                        |
          |      ANCP          |         OMCI           |
          &lt;-------------------&gt;&lt;-----------------------&gt;|
                                 PPP, DHCP, IP
          &lt;------------------------------------------------------&gt;

    Figure 12: Message Flow for the Use Case of Topology Discovery for
                        the ANCP+OMCI Control Model

   Figure 12 depicts a message flow for topology discovery when using
   the ANCP+OMCI control model.  Basically, when an ONT/ONU gets
   connected to a PON, the OLT detects a new device and a GPON Ranging
   process starts.  During this process, the ONT/ONU becomes authorized
   by the OLT and identified by ONT/ONU ID, PON Port ID, and max
   Bandwidth.  This port status is reported via ANCP to the NAS and then
   potentially the policy server via another mechanism that is out of
   scope of this document.  In a second step, after the GPON service
   profile is assigned from OLT to ONT/ONU, the OLT reports the final
   status to NAS with information about the service profile and other
   information such as the ONT/ONU port rate to the subscriber, for
   instance.






<span class="grey">Bitar, et al.                 Informational                    [Page 33]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-34" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>.  Access Loop Configuration</span>

   Topology Discovery provides Access Port Identification to the NAS
   when sending an Access Port Discovery message.  This informs NAS
   identification of a PON port on an Access Node.  Based on Access Port
   Identification and on customer identification, service-related
   parameters could be configured on an OLT and an ONU/ONT.

   Service-related parameters could be sent to OLT via ANCP before or
   after an ONU/ONT is up.  Sending of ANCP loop configuration messages
   from NAS can be triggered by a management system or by customer
   identification and authentication after Topology Discovery.  It may
   be used for first-time configuration (zero touch) or for
   updating/upgrading customer's profile like C-VLAN ID, S-VLAN ID, and
   service bandwidth.

   Parameters of the User-Network Interface (UNI), which is the
   subscriber interface to HGW/CPE of ONU/ONT, can also be configured
   via ANCP.  When the ONU/ONT supports ANCP, parameters of the UNI on
   ONU/ONT are sent to the ONU/ONT via ANCP.  If the ONU/ONT does not
   support ANCP but only OMCI, parameters have to be sent from the NAS
   to the OLT via ANCP first.  Then, the OLT translates such
   configuration into OMCI and sends it to the ONU/ONT.

<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>.  Security Considerations</span>

   [<a id="ref-RFC5713">RFC5713</a>] lists the ANCP-related security threats that could be
   encountered on the Access Node and the NAS.  It develops a threat
   model for ANCP security and lists the security functions that are
   required at the ANCP level.

   With multicast handling as described in this document, ANCP protocol
   activity between the ANX and the NAS is triggered by join/leave
   requests coming from the end-user equipment.  This could potentially
   be used for a denial-of-service attack against the ANX and/or the
   NAS.

   To mitigate this risk, the NAS and ANX may implement control plane
   protection mechanisms such as limiting the number of multicast flows
   a given user can simultaneously join or limiting the maximum rate of
   join/leave from a given user.

   Protection against invalid or unsubscribed flows can be deployed via
   provisioning black lists as close to the subscriber as possible
   (e.g., in the ONT).






<span class="grey">Bitar, et al.                 Informational                    [Page 34]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-35" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   User activity logging for accounting or tracking purposes could raise
   privacy concerns if not appropriately protected.  To protect such
   information, logging/accounting information can be exchanged with the
   corresponding server over a secure channel, and the information can
   be stored securely with policy-driven controlled access.

<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>.  Differences in ANCP Applicability between DSL and PON</span>

   As it currently stands, both ANCP framework [<a href="./rfc5851" title="&quot;Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks&quot;">RFC5851</a>] and protocol
   [<a href="./rfc6320" title="&quot;Protocol for Access Node Control Mechanism in Broadband Networks&quot;">RFC6320</a>] are defined in the context of DSL access.  Due to inherent
   differences between PON and DSL access technologies, ANCP needs a few
   extensions for supporting the use cases outlined in this document for
   PON-based access.  These specific differences and extensions are
   outlined below.

   -  In PON, the access-node functionality is split between OLT and
      ONT.  Therefore, ANCP interaction between NAS and AN translates to
      transactions between NAS and OLT and between OLT and ONT.  The
      processing of ANCP messages (e.g., for multicast replication
      control) on the OLT can trigger generation of ANCP messages from
      OLT to ONT.  Similarly, ANCP messages from ONT to the OLT can
      trigger ANCP exchange between the OLT and the NAS (e.g., admission
      request messages).  This is illustrated in the generic message
      flows in Figures 5 and 6 of <a href="#section-5">Section 5</a>.  In the case of DSL, the
      ANCP exchange is contained between two network elements (NAS and
      the DSLAM).

   -  The PON connection to the ONT is a shared medium between multiple
      ONTs on the same PON.  In the case of DSL, the local loop is
      point-to-point.  In the case of a DSL access network, the access-
      facing port on the NAS (i.e., port to the network between NAS and
      the DSLAM) and the access-facing ports on the DSLAM (i.e.,
      customer's local loop) are the two bandwidth constraint points
      that need to be considered for performing bandwidth-based
      admission control for multicast video and VoD delivered to the
      customer.  In the case of PON access, in addition to the bandwidth
      constraint on the NAS to OLT facing ports and the subscriber-
      allocated bandwidth for video services, the bandwidth available on
      the PON for video is an additional constraint that needs to be
      considered for bandwidth-based admission control.  If the
      bandwidth control is centralized in the NAS (as described in the
      first approach in <a href="#section-6.2">Section 6.2</a>), then the NAS needs to support
      additional logic to consider available PON bandwidth before
      admitting a multicast request or a VoD request by the user.
      Accordingly, ANCP needs to identify the customer Access Port and
      the PON on which the customer ONT is.  If the PON bandwidth
      control is performed on the OLT (as defined in the second approach
      in <a href="#section-6.2">Section 6.2</a>), then additional ANCP request and response



<span class="grey">Bitar, et al.                 Informational                    [Page 35]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-36" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


      messages are required for NAS to query the OLT to determine
      available PON bandwidth when a request to admit a VoD flow is
      received on the NAS (as shown in Figure 9 in <a href="#section-6.2">Section 6.2</a>) or for
      the OLT to inform the NAS what stream bandwidth is sent to the
      subscriber for the NAS to take appropriate action (e.g., bandwidth
      adjustment for various types of traffic).

   -  In PON, the multicast replication can potentially be performed on
      three different network elements: (1) on the NAS, (2) on the OLT
      for replication to multiple PON ports, and (3) on the ONT/ONU for
      replication to multiple customer ports.  In the case of DSL, the
      replication can potentially be performed on NAS and/or the DSLAM.
      <a href="#section-6.2">Section 6.2</a> defines options for multicast replication in the case
      of PON.  In the first option, the multicast replication is done on
      the AN but is controlled from NAS via ANCP (based on the reception
      of per-customer IGMP messages on the NAS).  In this option, the
      NAS needs to supply the OLT the set of PON-customer-IDs (as
      defined in <a href="#section-2">Section 2</a>) to which the multicast stream needs to be
      replicated.  The PON-customer-ID identifies the OLT and the PON
      ports on the OLT as well as the ONT and the Access Ports on the
      ONT where the multicast stream needs to be replicated.  Upon
      receiving the request to update its multicast replication state,
      the OLT must update its replication state with the indicated PON
      ports but may also need to interact with the ONT via ANCP to
      update the multicast replication state on the ONT with the set of
      Access Ports (as indicated by the NAS).  In the case of DSL, the
      DSLAM only needs to update its own replication state based on the
      set of Access Ports indicated by the NAS.

   -  For reporting purposes, ANCP must enable the NAS to query the OLT
      for channels replicated on a PON or a list of PONs and to specific
      Access Ports.  The latter should trigger the OLT to query the ONT
      for a list of channels being replicated on all Access Ports or on
      specific Access Ports to the premises.  In a DSL case, it is
      sufficient to query the DSLAM for a list of channels being
      replicated on an Access Port or a list of Access Ports.

<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>.  ANCP versus OMCI between the OLT and ONT/ONU</span>

   ONT Management and Control Interface (OMCI) [<a href="#ref-OMCI" title="&quot;Gigabit-capable passive optical networks (G-PON): ONT management and control interface specification&quot;">OMCI</a>] is specified for
   in-band ONT management via the OLT.  This includes configuring
   parameters on the ONT/ONU.  Such configuration can include adding an
   Access Port on the ONT to a multicast tree and the ONT to a multicast
   tree.  Thus, OMCI can be a potential replacement for ANCP between the
   OLT and ONT/ONU, albeit it may not be a suitable protocol for dynamic
   transactions as required for the multicast application.





<span class="grey">Bitar, et al.                 Informational                    [Page 36]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-37" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   If OMCI is selected to be enabled between the OLT and ONT/ONU to
   carry the same information elements that would be carried over ANCP,
   the OLT must perform the necessary translation between ANCP and OMCI
   for replication control messages received via ANCP.  OMCI is an
   already available control channel, while ANCP requires a TCP/IP stack
   on the ONT/ONU that can be used by an ANCP client, and accordingly,
   it requires that the ONT/ONU be IP addressable for ANCP.  Most
   ONTs/ONUs today have a TCP/IP stack used by certain applications
   (e.g., VoIP and IGMP snooping).  ANCP may use the same IP address
   that is often assigned for VoIP or, depending on the implementation,
   may require a different address.  Sharing the same IP address between
   VoIP and ANCP may have other network implications on how the VoIP
   agent is addressed and on traffic routing.  For instance, the VoIP
   traffic to/from the ONT is often encapsulated in a VLAN-tagged
   Ethernet frame and switched at Layer 2 through the OLT to the NAS
   where it is routed.  The VoIP agent in this case looks like another
   subscriber to the NAS.  On the other hand, the ANCP session between
   the ONT and OLT is terminated at the OLT.  Thus, the OLT must be able
   to receive/send IP traffic to/from the OLT, which will not work using
   this setting.  Using a separate IP address for the purpose of ONT/ONU
   management or ANCP specifically may often be required when supporting
   ANCP.  These considerations may favor OMCI in certain environments.
   However, OMCI will not allow some of the transactions required in
   approach 2, where the ONT/ONU sends unsolicited requests to the OLT
   rather than being queried or configured by OLT requests.

<span class="h2"><a class="selflink" id="section-13" href="#section-13">13</a>.  Acknowledgements</span>

   The authors thank Rajesh Yadav and Francois Le Faucheur for their
   valuable comments and discussions.

<span class="h2"><a class="selflink" id="section-14" href="#section-14">14</a>.  References</span>

<span class="h3"><a class="selflink" id="section-14.1" href="#section-14.1">14.1</a>.  Normative References</span>

   [<a id="ref-RFC2516">RFC2516</a>]  Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
              and R. Wheeler, "A Method for Transmitting PPP Over
              Ethernet (PPPoE)", <a href="./rfc2516">RFC 2516</a>, February 1999.

   [<a id="ref-RFC2684">RFC2684</a>]  Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
              over ATM Adaptation Layer 5", <a href="./rfc2684">RFC 2684</a>, September 1999.

   [<a id="ref-RFC3376">RFC3376</a>]  Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
              Thyagarajan, "Internet Group Management Protocol, Version
              3", <a href="./rfc3376">RFC 3376</a>, October 2002.






<span class="grey">Bitar, et al.                 Informational                    [Page 37]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-38" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   [<a id="ref-RFC4605">RFC4605</a>]  Fenner, B., He, H., Haberman, B., and H. Sandick,
              "Internet Group Management Protocol (IGMP) / Multicast
              Listener Discovery (MLD)-Based Multicast Forwarding
              ("IGMP/MLD Proxying")", <a href="./rfc4605">RFC 4605</a>, August 2006.

<span class="h3"><a class="selflink" id="section-14.2" href="#section-14.2">14.2</a>.  Informative References</span>

   [<a id="ref-802.1ag">802.1ag</a>]  IEEE 802.1ag, "Connectivity Fault Management", December
              2007.

   [<a id="ref-RFC2881">RFC2881</a>]  Mitton, D. and M. Beadles, "Network Access Server
              Requirements Next Generation (NASREQNG) NAS Model", <a href="./rfc2881">RFC</a>
              <a href="./rfc2881">2881</a>, July 2000.

   [<a id="ref-RFC5851">RFC5851</a>]  Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
              Wadhwa, "Framework and Requirements for an Access Node
              Control Mechanism in Broadband Multi-Service Networks",
              <a href="./rfc5851">RFC 5851</a>, May 2010.

   [<a id="ref-G.983.1">G.983.1</a>]  ITU-T G.983.1, "Broadband optical access systems based on
              Passive Optical Networks (PON)", January 2005.

   [<a id="ref-G.984.1">G.984.1</a>]  ITU-T G.984.1, "Gigabit-capable Passive Optical Networks
              (GPON): General characteristics", March 2008.

   [<a id="ref-RFC3046">RFC3046</a>]  Patrick, M., "DHCP Relay Agent Information Option", <a href="./rfc3046">RFC</a>
              <a href="./rfc3046">3046</a>, January 2001.

   [<a id="ref-TR-101">TR-101</a>]   Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL
              Aggregation", DSL Forum TR-101, May 2006.

   [<a id="ref-RFC5713">RFC5713</a>]  Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security
              Threats and Security Requirements for the Access Node
              Control Protocol (ANCP)", <a href="./rfc5713">RFC 5713</a>, January 2010.

   [<a id="ref-OMCI">OMCI</a>]     ITU-T G.984.4, "Gigabit-capable passive optical networks
              (G-PON): ONT management and control interface
              specification", February 2008.

   [<a id="ref-RFC6320">RFC6320</a>]  Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T.
              Taylor, Ed., "Protocol for Access Node Control Mechanism
              in Broadband Networks", <a href="./rfc6320">RFC 6320</a>, October 2011.

   [<a id="ref-G.987.3">G.987.3</a>]  ITU-T G.987.3, "10-Gigabit-capable passive optical
              networks(XG-PON): Transmission convergence (TC) layer
              specification", October 2010.





<span class="grey">Bitar, et al.                 Informational                    [Page 38]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-39" ></span>
<span class="grey"><a href="./rfc6934">RFC 6934</a>               ANCP in PON-Based Networks              June 2013</span>


   [<a id="ref-Y.1731">Y.1731</a>]   ITU-T Y.1731, "OAM functions and mechanisms for Ethernet
              based networks", May 2006.

Authors' Addresses

   Nabil Bitar (editor)
   Verizon
   60 Sylvan Road
   Waltham, MA 02451
   EMail: nabil.n.bitar@verizon.com

   Sanjay Wadhwa (editor)
   Alcatel-Lucent
   701 East Middlefield Road
   Mountain View, CA, 94043
   EMail: sanjay.wadhwa@alcatel-lucent.com

   Thomas Haag
   Deutsche Telekom
   EMail: HaagT@telekom.de

   Hongyu Li
   Huawei Technologies
   EMail: hongyu.lihongyu@huawei.com



























Bitar, et al.                 Informational                    [Page 39]
</pre>