[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 RFC 6934

Network Working Group                                  Nabil Bitar
Internet Draft                                         Verizon
Category: Informational
Expiration Date: April 18, 2011                        Sanjay Wadhwa
                                                       Juniper Networks

                                                       October 18, 2010


             Applicability of Access Node Control Mechanism to
                       PON based Broadband Networks

                       draft-ietf-ancp-pon-00.txt

  Abstract

   The purpose of this document is to provide applicability of Access
   Node Control Mechanism, as described in [ANCP-FRAMEWORK], to PON
   based broadband access. The need for an Access Node Control Mechanism
   between a Network Access Server (NAS) and an Access Node Complex (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 the information does not need to
   go through distinct element managers but rather uses a direct device-
   device communication. This allows for performing access link related
   operations within those network elements to meet performance
   objectives.

  Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 18, 2011.

Bitar-Wadhwa            Expires April 18, 2011                 [Page 1]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

   Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) 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

   1  Specification Requirements ................................... 4

   2  Introduction ................................................. 4

      2.1   Terminology ............................................ 5
   3  Reference Architecture for PON Based Broadband Access Network  7

      3.1   Home Gateway ........................................... 8
      3.2   PON Access ............................................. 8
      3.3   Access Node Complex .................................... 8
      3.4   Access Node Complex Uplink to the BNG .................. 8
      3.5   Aggregation Network .................................... 9
      3.6   Network Access Server .................................. 9

Bitar-Wadhwa            Expires April 18, 2011                 [Page 2]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

      3.7   Regional Network ....................................... 9
   4  Motivation for explicit extension of ANCP to FTTP PON ........ 9

   5  Concept of Access Node Control Mechanism for PON based access 10

   6  Multicast  .................................................. 12

      6.1   Multicast Conditional Access .......................... 12
      6.2   Multicast Admission Control ........................... 15
      6.3   Multicast Accounting .................................. 26
   7  Remote Connectivity Check ................................... 27

   8  Access Topology Discovery ................................... 28

   9  Security Considerations ..................................... 28

   10 Differences in ANCP applicability between DSL and PON ....... 29

   11 ANCP versus OMCI between the OLT and ONT .................... 30

   12 IANA Considerations ......................................... 31

   13 Acknowledgements ............................................ 31

   14 References .................................................. 31

      14.1  Normative References .................................. 31
      14.2  Informative References ................................ 31
   Author's Addresses ............................................. 32
























Bitar-Wadhwa            Expires April 18, 2011                 [Page 3]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

1  Specification Requirements


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
   in this document are to be interpreted as described in RFC 2119.

2  Introduction

   Passive Optical Networks (PONs) based on BPON and GPON are being
   deployed across carrier networks. There are two models for PON
   deployment: Fiber to the curb (FTTC), and Fiber to the Premise
   (FTTP). In the FTTC deployment, the last mile connectivity is
   provided over the local loop using Very High Speed DSL. In the FTTP
   case, PON extends to the premise. In addition, there are three main
   PON technologies: (1) Broadband PON (BPON), (2) Gigabit PON (GPON),
   and (3) Ethernet PON (EPON). The focus in the document will be on
   BPON and GPON in the context of FTTP deployment.

   BPON and GPON 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 Mbps
   per PON while GPON provides 2.4 Gbps. 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 homes per
   PON.

   The motive behind BPON and GPON deployment is providing triple-play
   services over IP: voice, video and data. Voice is generally low
   bandwidth but has low-delay, low-jitter, and low packet-loss
   requirements. 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
   Mbps per stream while High definition content using MPEG2 encoding
   requires on the order of 15-19 Mbps 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 liner programming
   content). While linear programming content can be provided over
   Layer1 on the PON, the focus in this document is on delivering linear
   programming content over IP to the home, using IP multicast. Video on
   demand is also considered for delivery over IP using a unicast
   session model.


Bitar-Wadhwa            Expires April 18, 2011                 [Page 4]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

   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 the video content (unicast and
   multicast) delivered to the user does not exceed the bandwidth
   allocated to the user 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 PON environment, this implies enabling IP
   multicast on the Access Node (AN) complex composed of the ONT and
   OLT, as applicable. This is as opposed to DSL deployments where
   multicast is enabled on the 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 PON environments
   between the AN complex and the NAS, specifically focusing on
   bandwidth dedicated for multicast and shared bandwidth between
   multicast and unicast.

   [ANCP-FRAMEWORK] provides the framework and requirements for
   coordinated admission control between a NAS and an AN with special
   focus on DSL deployments. This document proposes the extension of
   that framework and the related requirements to explicitly address
   BPON and GPON deployments.

2.1 Terminology

   o PON (Passive Optical Network): a point-to-multipoint fiber to the
     premises 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 Termination (OLT) at the Service Provider's CO
     and a number of Optical Network Units or Terminals (ONU/ONT) 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.

   o Access Node Complex (ANX): The Access Node is decomposed by two
     geographical functions, performed by OLT and ONU/ONT. The general
     term Access Node (ANX) will be used when describing a
     functionality which does not depend on the physical location but
     rather on the "black box" behaviour of OLT and ONU/ONT.



Bitar-Wadhwa            Expires April 18, 2011                 [Page 5]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

        o Optical Line Terminal (OLT): is located in the Service
          provider's central office. It terminates and aggregates
          multiple PONs (providing fiber access to multiple premises or
          neighborhoods) on the user side, and interfaces with the
          service element (NAS) providing subscriber management.

        o Optical Network Terminal (ONT): terminates PON on the network
          side and provides PON adaptation. The user side interface and
          the location of the ONT is dictated by the type of network
          deployment. For a Fiber-to-the-Premise (FTTP) deployment
          (with Fiber all the way to the apartment or living unit), ONT
          has Ethernet (FE/GE/MoCA) connectivity with the Home Gateway
          (HGW)/Customer Premise Equipment (CPE). In case of an MDU
          (multi-dwelling or multi-tenant unit), a multi-subscriber ONU
          typically resides in the basement or a wiring closet, and has
          FE/GE/Ethernet over VDSL connectivity with each CPE. In the
          case where fiber is terminated outside the premise
          (neighborhood or curb side) on an ONT/ONU, the last-leg-
          premise connections could be via existing or new Copper, with
          xDSL physical layer (typically VDSL). In this case, the
          Access Node (OLT & ONT together) effectively is a "PON fed
          DSLAM".

   o Network Access Server (NAS): Network element which 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).

   o Home Gateway (HGW): Network element that connects subscriber
     devices to the AN or ANX and the access network. In case of DSL,
     the Home Gateway is a DSL network termination that could either
     operate as a Layer 2 bridge or as a Layer 3 router. In the latter
     case, such a device is also referred to as a Routing Gateway (RG).
     In the case of PON, it is often a Layer3 routing device with the
     ONT performing PON termination.

   o PON-Customer-ID: This is an identifier which uniquely identifies
     the ANX and the access loop logical port on the ANX to the
     customer premise, 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 directly connected to the NAS), the PON port on the
     OLT, the ONT, and the port on the ONT connecting to the customer
     HGW. When acting as a DHCP relay agent, the OLT can encode PON-
     Customer-ID in the "Agent-Circuit-Identifier" Sub-option in
     Option-82 of the DHCP messages.








Bitar-Wadhwa            Expires April 18, 2011                 [Page 6]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

3  Reference Architecture for PON Based Broadband Access Network

   The reference architecture used in this document is based on Ethernet
   aggregation for both of BPON and GPON. Specifically, the following
   cases are addressed:

     o BPON with Ethernet uplink to the BNG and ATM on the PON side.

     o GPON with Ethernet uplink to the BNG and Ethernet on the PON
        side.

     In 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
     DSL Forum [TR-101]. The Ethernet aggregation network between a NAS
     and an OLT may be degenerated to one or more direct physical
     Ethernet links.

     Given the industry's move towards Ethernet as the new access and
     aggregation technology for triple play services, the primary focus
     throughout this document is on GPON and BPON with Ethernet between
     the BNG and the OLT. Figures 1 and 2 depict an end-to-end
     broadband network with PON access.


                                               Access         Customer
                              <----------Aggregation---------><-Prem->
                                               Network        Network

                                       +----------------------+
                                       |    Access Node (ANX) |
         +---------+   +---+  +-----+  |+---+       +-------+ |  +---+
         |         | +-|NAS|--|Eth  |--||OLT|-<PON>-|ONT/ONU|-|--|HGW|
   NSP---+Regional | | +---+  |Agg  |  |+---+       +-------+ |  +---+
         |Broadband| | +---+  +-----+  +----------------------+
         |Network  |-+-|NAS|                  |
   ASP---+         | | +---+                  |
         |         | | +---+                  |
         +---------+ +-|NAS|                  |       +-------+  +---+
                       +---|                  +-<PON>-|ONT/ONU|--|HGW|
                                                  |   +-------+  +---+
                                                  .............
                                                  |   +-------+  +---+
                                                  +---|ONT/ONU|--|HGW|
                                                      +-------+  +---+
    HGW       : Home Gateway
    NAS      : Network Access Server
    PON      : Passive Optical Network
    OLT      : Optical Line Terminal
    ONT/ONU  : Optical Network Terminal/Unit

   Figure 1.  Access Network with PON


Bitar-Wadhwa            Expires April 18, 2011                 [Page 7]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010


                                                            FE/GE/VDSL
                                                          +----+  +---+
                                +-----------------+       |    |--|HGW|
         +---------+   +-----+  | +-----+  +----+ |       |    |  +---+
         |         | +-|NAS  |--| |Eth  |--| OLT| |-<PON>-|    |  +---+
   NSP---+Regional | | +-----+  | |Agg  |  |    | |   |   |ONT/|--|HGW|
         |Broadband| | +-----+  | +-----+  +----+ |   |   |ONU |  +---+
         |Network  |-+-|NAS  |  +-----------------+   |   |    |     .
   ASP---+         | | +-----+                        |   |    |  +---+
         |         | | +-----+                        |   |    |--|HGW|
         +---------+ +-|NAS  |                        |   +----+  +---+
                       +-----+                        |
                                                      |  +---+  +---+
                                                      +--|ONT|--|HGW|
                                                         +---+  +---+
    Figure 2. FTTP/FTTC with multi-subscriber ONU serving MTUs/MDUs

3.1 Home Gateway

   The Home Gateway (HGW) connects the different Customer Premises
   Equipment (CPE) to the ANX and the access network.  In case of PON,
   the HGW is a layer 3 router. In this case, the HGW performs DHCP
   assignment to devices within the home, and performs Network Address
   and Port Translation (NAPT) between the LAN and WAN side. In case of
   FTTP, the HGW connects to the ONT over an Ethernet interface. That
   Ethernet interface could be a physical port or over another medium.
   In 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.

3.2 PON Access

   PON access is composed of the ONT and OLT. PON ensures physical
   connectivity between the ONT at the customer premises and the OLT.
   PON framing can be BPON (in case of BPON) or GPON (in case of GPON).
   The protocol encapsulation on BPON is based on multi-protocol
   encapsulation over AAL5, defined in [RFC2684].  This covers PPP over
   Ethernet (PPPoE, defined in [RFC2516]), or bridged IP (IPoE). The
   protocol encapsulation on GPON is always IPoE. In all cases, the
   connection between the AN (OLT) and the NAS (BNG) is assumed to be
   Ethernet in this document.

3.3 Access Node Complex

   This is composed of OLT and ONT and is defined in section 2.1.

3.4 Access Node Complex Uplink to the BNG

   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 and customer separation and
   traceability. This can be achieved using an ATM or an Ethernet based


Bitar-Wadhwa            Expires April 18, 2011                 [Page 8]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

   technology. The focus in this document is on Ethernet as stated
   earlier.

3.5 Aggregation Network

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


3.6 Network Access Server

   The NAS is a network device which 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 [RFC2881]. 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 SONET). The NAS
   functionality corresponds to the BNG functionality described in DSL
   Forum TR-101. In addition to this, the NAS supports the Access Node
   Control functionality defined for the respective use cases in this
   document.


3.7 Regional Network

   The Regional Network connects one or more NAS 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.


4   Motivation for explicit extension of ANCP to FTTP PON

   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 to 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



Bitar-Wadhwa            Expires April 18, 2011                 [Page 9]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

   PON enables the AN (OLT) to send one copy on the PON as opposed to N
   copies of a multicast channel on the PON serving N premises being
   receivers. 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 a single encryption key
   for all PON frames carrying all multicast channels or a key per set
   of multicast channels that correspond to service packages, or none.
   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.


   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 [ANCP-
   FRAMEWORK] for DSL based networks is very suitable to realize a
   control protocol (with transactional exchange capabilities), between
   PON enabled ANX and the NAS, and also between the components
   comprising the ANX i.e. between OLT and the ONT. Typical use cases
   for ANCP in PON environment include the following:

     o Multicast

          o Optimized multicast delivery

          o Unified video resource control

          o NAS based provisioning of ANX

     o Access topology discovery

     o Remote connectivity check


5  Concept of Access Node Control Mechanism for PON based access

   The high-level communication framework for an Access Node Control
   Mechanism is shown in Figure 3. 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. The mechanism consists of control function, and
   reporting and/or enforcement function. 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


Bitar-Wadhwa            Expires April 18, 2011                [Page 10]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

   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
   controller function to enforce a specific policy or trigger a local
   action. The messages shown in Figure 3 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 |                    +--<PON>---|ONT |------- HGW
+--------+                   +           +----+  +---+
     |                      +         +----------|ONT|------ HGW
     |                     +          |          +---+
     |               +----------------|-------------+
  +----+             | +----+         |     +-----+ |      +---+
  |NAS |---------------|    |         |     |     |-|------|HGW|
  |    |<------------->|    |         |     | ONT | |      +---+
  +----+     ANCP    | |OLT |------<PON>----|     | |
     |               | |    |               |     | |       +---+
     |               | |    |<------------->|     |-------- |HGW|
     |               | +----+    ANCP       +-----+ |       +---+
     |               +-----------------------------+
     |                    |    Access Node      |
     | Control Request    |                     |
     | ------------------>| Control Request     |
     |                    |-------------------->|
     |                    | Control Response    |
     | Control Response   |<------------------- |
     |<-------------------|                     |
     |                    |Admission Request    |
     | Admission Request  |<--------------------|
     |<-------------------|                     |
     |Admission Response  |                     |
     |------------------->|Admission Response   |
     |                    |-------------------->|
     |Information Report  |                     |
     |<-------------------|                     |
     Access Node Control     Access Node Control
         Mechanism                Mechanism
     <--------------------><-------------------->

                            PPP, DHCP, IP
     <----------------------------------------------------------->

  Figure 3. Conceptual Message Flow for Access Node Control Mechanism



Bitar-Wadhwa            Expires April 18, 2011                [Page 11]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

6  Multicast

   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)
   becoming multicast aware by implementing an IGMP snooping and/or
   proxy function. The replication thus needs to be distributed between
   NAS, aggregation nodes, and ANX. In case of GPON, and in 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.



6.1 Multicast Conditional Access

    In a Broadband FTTP 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


Bitar-Wadhwa            Expires April 18, 2011                [Page 12]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

    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 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. 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 later in section 3.4. The other approach is
    to provision the necessary conditional access information on the ANX
    (ONT 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 [ANCP-FRAMEWORK], 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 and OLT. Thus, this information can be programmed on the ONT
    and/or OLT. Programming this information on the ONT prevents
    illegitimate joins from propagating further into the network. A
    third approach, outside of the scope, 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 performs IGMP snooping and it is programmed with a
    channel access list, the ONT 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 will pass the join request
    upstream towards the NAS. The ONT 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




Bitar-Wadhwa            Expires April 18, 2011                [Page 13]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

    can autonomously discard the message because the channel is not
    authorized for that subscriber.

    The ONT, in addition to forwarding the IGMP join, sends an ANCP
    admission request to the OLT identifying the channel to be joined
    and the premise. Premise identification to the OLT can be based on a
    Customer-Port-ID that maps to the access port on the ONT and known
    at the ONT and OLT. If the ONT has a white list and/or a black list
    per premise, the OLT need not have such a list. If the ONT does not
    have such a list, the OLT may be programmed with such a list for
    each premise. In this latter case, the OLT would perform the actions
    described earlier on the ONT. 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. OLT Bandwidth based admission
    control scenarios are defined in section 3.4.

   The White List and Black List can contain entries allowing:

   o  An exact match for a (*,G) ASM group (e.g. <G=g.h.i.l>);

   o  An exact match for a (S,G) SSM channel (e.g.
      <S=s.t.u.v,G=g.h.i.l>);

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

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

   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, the OLT or NAS
   can be programmed with these access lists. Having these access lists
   on the ONT 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, will reduce unnecessary control
   load on the NAS.





Bitar-Wadhwa            Expires April 18, 2011                [Page 14]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

6.2 Multicast Admission Control

   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-
   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, which cannot be dynamically adjusted to
   the currently available bandwidth.

   An Admission Control (AC) mechanism covering admission of multicast
   traffic for the FTTP 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 premise 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 will be 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
     shr. 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,
     performs conditional access, and bandwidth based admission control
     on the IGMP request. The bandwidth admission control is performed
     against the following:


Bitar-Wadhwa            Expires April 18, 2011                [Page 15]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

     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 case of 1:1 VLAN
     representation of the premise, 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 case if 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 "Agent Circuit Identifier" 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 under all conditions can track the changes in
     available bandwidth on the PON. 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 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 is 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 on that PON. Also, the OLT will send an ANCP
     message to direct the ONT to add or update its replication state
     with the customer port for that channel. The interaction between

Bitar-Wadhwa            Expires April 18, 2011                [Page 16]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

     ANX and NAS is shown in Figures 4 and 5.
     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.












































Bitar-Wadhwa            Expires April 18, 2011                [Page 17]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010





                                               +----+
                           +---<PON>-----------|ONT |-------- HGW
                          +                    +----+
                         +                     +----+
                        +           +--------- |ONT |-------- HGW
+----+               +----+        +           +----+
|NAS |---------------|    |------<PON>
|    |<------------->|    |        +           +-----+
+----+     ANCP      |OLT |         +--------- |     |------- HGW
  |                  |    |                    |     |
  |                  |    |<------------------>| ONU |--------HGW
  |                  +----+    ANCP            |     |       +---+
  |                     |                      |     |-------|HGW|
  |                     |                      +-----+       +---+
  |           1.IGMP JOIN(S/*,G)                |                |
  |<-------------------------------------------------------------|
2.|                     |                       |                |
+=======================+                       |                |
[Access Control &       ]                       |                |
[Subscriber B/W         ]                       |                |
[PON B/W & OLT link B/W ]                       |                |
[based Admission Control]                       |                |
+=======================+                       |                |
  |                     |                       |                |
  |                     |                       |                |
  |-------------------->|                       |                |
3.ANCP Replication-Start|                       |                |
  (<S/*,G> or Multicast MAC,Customer-Port-ID>                    |
  |                     |                       |                |
  |                     | --------------------->|                |
  |                     |4.ANCP Replication-Start                |
  |                     |(<S/*,G> or Multicast MAC,Customer-Port-ID)
  |-------------------->|                       |                |
  |5.Multicast Flow(S,G)|                       |                |
  |On Multicast VLAN    |---------------------->|                |
  |                     |6.Multicast Flow (S,G) |                |
  |                     |forwarded on           |                |
  |                     |Unidirectional         |                |
  |                     |<Multicast GEM-PORT>   |                |
  |                     |on the PON by OLT      |--------------->|
                                                |7. Multicast Flow
                                                |forwarded on    |
                                                |Customer-Port by|
                                                |ONT/OLT.        |
                                                |                |
Figure 4. Interactions for NAS based Multicast Admission Control (no
IGMP processing on ANX, and NAS maintains available video bandwidth for
PON).



Bitar-Wadhwa            Expires April 18, 2011                [Page 18]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

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

Figure 5. Interactions for NAS based Multicast Admission Control (no
IGMP processing on ANX, and NAS maintains available video bandwidth for
PON).


Bitar-Wadhwa            Expires April 18, 2011                [Page 19]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

  . 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.

     ANX operation:

     o ONT 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 passes the
        conditional access check, the ONT will forward the IGMP Join,
        and will send a bandwidth admission control request to the OLT.
        In case the multicast stream is already being received on the
        PON, the ONT does not forward the stream to the access port
        where IGMP is received, till it has received a positive
        admission control response from the OLT.

     o OLT can snoop IGMP messages.  It also receives a bandwidth
        admission control request from the ONT 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 multicast available
        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 premise 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 PON available bandwidth is
        less than the bandwidth of the requested channel, the OLT sends
        an admission response (with a reject) to the ONT, 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
     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
     multicast video available bandwidth (this includes the dedicated


Bitar-Wadhwa            Expires April 18, 2011                [Page 20]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

     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 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 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 turns removes the
     subscriber as a receiver for that channel (it it were 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 show in Figures 6 and 7.

     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 PON available 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 PON available bandwidth and
     may accept the request and send an ANCP request to the ONT 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), it 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. The policy server after authorizing the
     request, 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


Bitar-Wadhwa            Expires April 18, 2011                [Page 21]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

     PON, it reserves that bandwidth and returns an admission 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 accept to the application server, and the video
     stream is streamed to the subscriber. This interaction is shown in
     Figure 8. 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 pool to the subscriber and
     the downlink to the OLT.














































Bitar-Wadhwa            Expires April 18, 2011                [Page 22]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010






                                               +----+
                                    +----------|ONT |-------- HGW
+----+               +----+        +           +----+
|NAS |---------------|    |------<PON>
|    |<------------->|    |        +           +-----+
+----+     ANCP      |OLT |         +--------- |     |--------- HGW
  |                  |    |    ANCP            |     |
  |                  |    |<------------------>| ONU |----------HGW
  |                  +----+                    +-----+
  |                     |                        |               |
  |1.IGMP Join(s/*,G) +=============+         +=============+    |
  |<------------------[IGMP Snooping]---------[IGMP snooping]--- |
  |                   +=============+         +=============+    |
  |                     |2.Admission-Request     |
                         (Flow, Customer-Port-ID)|
  |                     |<-----------------------|
  |                3.+===============+           |               |
  |                  [ Access Ctrl   ]           |               |
  |                  [ & PON B/W     ]           |               |
  |                  [ Admission Ctrl]           |               |
  |                  +===============+ PASS      |               |
  |4.Admission-Request  |                        |               |
  | <Flow,              |                        |               |
  |  Customer-Port-ID>  |                        |               |
  |<--------------------|                        |               |
5.|                     |                        |               |
+=================+     |                        |               |
[Subscriber B/W   ]     |                        |               |
[& OLT link B/W   ]     |                        |               |
[Admission Ctrl   ]     |                        |               |
+=================+PASS |                        |               |
  |                     |                        |               |
  |6.Admission-Reply-Pass                        |               |
  |<Flow,Customer-Port-ID>                       |               |
  |-------------------->|                        |               |
  |            7.+========================+      |               |
  |              [Update Replication State]      |               |
  |              +========================+      |               |
  |                     | 8.Admission-Reply-Pass |               |
  |                     |(<Flow,Cust-Port-ID>    |               |
  |                     |----------------------->|               |
  |                     |                 9.+============+       |
  |                     |                   [Update Repl.]       |
  |                     |                   [   State    ]       |
  |                     |                   +============+       |
Figure 6. Interaction between NAS & ANX for Multicast B/W Admission
Control


Bitar-Wadhwa            Expires April 18, 2011                [Page 23]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

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

Figure 7. Interaction between NAS and ANX for Multicast B/W Admission
Control





Bitar-Wadhwa            Expires April 18, 2011                [Page 24]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010



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


Figure 8. Interactions for VoD Bandwidth Admission Control

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


Bitar-Wadhwa            Expires April 18, 2011                [Page 25]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

     the GWR. 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 video
     available 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 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, 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 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.

6.3 Multicast Accounting

   It may be desirable to perform accurate per-user or per Access Loop
   time or volume based accounting.  In case 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:

     o 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 [ANCP-FRAMEWORK. If


Bitar-Wadhwa            Expires April 18, 2011                [Page 26]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

        the replication function is distributed between the OLT and ONT
        a query from the NAS will result in OLT generating a query to
        the ONT.

     o 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, 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 OLT to ONT. The OLT responds back to the NAS when it
   receives the response from the ONT. 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.

7  Remote Connectivity Check

   In an end-to-end Ethernet aggregation network, end-to-end Ethernet
   OAM as specified in IEEE 802.1ag and ITU-T Recommendation Y.1730/1731
   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 and widely available. Until such mechanisms become
   standardized and widely available, 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.

   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 Access Node and HGW. On reception of the
   ANCP message, the OLT can trigger native OAM procedures defined for
   BPON in [G.983.1] and for GPON in [G.984.1]. The Access Node can send
   the result of the test to the NAS via a Control Response message.








Bitar-Wadhwa            Expires April 18, 2011                [Page 27]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

8  Access Topology Discovery

   In order to avoid congestion in the network, and 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 in case the last mile is xDSL
   based e.g. in case of "PON fed DSLAMs" for FTTC/FTTN scenarios),
   hence cannot come from a provisioning and/or inventory management OSS
   system.  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.

   OSS systems are rarely able to enforce in a reliable and scalable
   manner the consistency of such data, 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 system.

   The rate of the access-loop can be communicated via ANCP (Information
   Report Message) from the ONT to the OLT, and from OLT to the NAS.
   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 making 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.

9  Security Considerations

   [ANCP-SECURITY] 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 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.


Bitar-Wadhwa            Expires April 18, 2011                [Page 28]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010


   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).

10 Differences in ANCP applicability between DSL and PON

   As it currently stands, both ANCP framework [ANCP-FRAMEWORK] and
   protocol [ANCP-PROTOCOL] are defined in 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.

   o 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 ONT and the NAS (e.g. admission-request
   messages).This is illustrated in the generic message flow in Figure 3
   of section 5. In case of DSL, the ANCP exchange is contained between
   two network elements (NAS and the DSLAM).

   o The PON connection to the ONT is a shared medium between multiple
   ONTs on the same PON. The local-loop in case of DSL is point-to-
   point. In case of 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 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 NAS (as described in option 1 of
   section 6.2), 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 second
   option in section 6.2), then additional ANCP request and response
   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 8 in section 6.2) 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).

   o In PON, the multicast replication can potentially be performed on
   three different network elements: (1) on the NAS (2) on the OLT for


Bitar-Wadhwa            Expires April 18, 2011                [Page 29]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

   replication to multiple PON ports and (3) on the ONT/ONU for
   replication to multiple customer ports. In case of DSL, the
   replication can potentially be performed on NAS and/or the DSLAM.
   Section 6.2 defines options for multicast replication in 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 to the OLT the set of PON-customer-IDs (as defined in section
   2.1) 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
   case of DSL, the DSLAM only needs to update its own replication state
   based on the set of access-ports indicated by the NAS.

   o 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 premise. In 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.

11 ANCP versus OMCI between the OLT and ONT

   ONT Management and Control Interface (OMCI) [OMCI] is specified for
   in-band ONT management via the OLT. This includes configuring
   parameters on the ONT. 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, albeit it may not be suitable protocol for dynamic
   transactions as required for the multicast application.

   If OMCI is selected to be enabled between the OLT and ONT 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 that can be used by an ANCP client and accordingly it requires
   that the ONT be IP addressable for ANCP. Most ONTs today have a
   TCP/IP stack used by certain applications (e.g., VoIP, IGMP
   snooping). ANCP may use the same IP address that is often assigned to
   SIP or depending on the implementation may require a different
   address. Sharing the same IP address between SIP and ANCP may have
   other network implications on traffic routing. Using a separate IP
   address for the purpose of ONT 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 sends
   unsolicited requests to the OLT rather than being queried or

Bitar-Wadhwa            Expires April 18, 2011                [Page 30]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010


    configured by OLT requests.

12 IANA Considerations

   This document does not require actions by IANA.

13 Acknowledgements

14 References

14.1 Normative References

   [RFC2516]  Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
   and R. Wheeler, "A Method for Transmitting PPP Over
   Ethernet (PPPoE)", RFC 2516, February 1999.

   [RFC2684]  Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
   over ATM Adaptation Layer 5", RFC 2684, September 1999.

14.2 Informative References

   [RFC2881] Mitton, D. and M. Beadles, "Network Access Server
   Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, Jul
   2000.

   [ANCP-FRAMEWORK] Ooghe, S., et al., "Framework and Requirements
   for Access Node Control Mechanism in Broadband Networks", RFC 5851,
   May 2010.

   [G.983.1] ITU-T recommendation G.983.1, Broadband optical access
   systems based on Passive Optical Networks (PON).

   [G.984.1] ITU-T recommendation G.984.1 Gigabit-capable Passive
   Optical Networks (G-PON): General characteristics

   [TR-101] Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL
   Aggregation", DSL Forum TR-101, May 2006.

   [ANCP-SECURITY] Moustafa, H., Tschofenig, H., and S. De Cnodder,
   "Security Threats and Security Requirements for the Access Node
   Control Protocol (ANCP)", RFC 5713, January 2010.

   [OMCI] ITU-T recommendation G.984.4 GPON ONT Management and Control
   Interface (OMCI) Specifications.

   [ANCP-PROTOCOL] Wadhwa, S et al, "Protocol for Access Node Control
   Mechanism in Broadband Networks", draft-ietf-ancp-protocol-12.txt,
   August 2010, work in progress.





Bitar-Wadhwa            Expires April 18, 2011                [Page 31]


Internet-Draft            draft-ietf-ancp-pon-00    October 2010

Author's Addresses

   Nabil Bitar
   Verizon
   117 West Street
   Waltham, MA 02451

   Email: nabil.n.bitar@verizon.com

   Sanjay Wadhwa
   Juniper Networks
   10 Technology Park Drive
   Westford, MA 01886

   Email: swadhwa@juniper.net








































Bitar-Wadhwa            Expires April 18, 2011               [Page 32]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/