draft-ietf-ancp-pon-00.txt   draft-ietf-ancp-pon-01.txt 
Network Working Group Nabil Bitar Network Working Group Nabil Bitar(ed.)
Internet Draft Verizon Verizon
Category: Informational Internet Draft
Expiration Date: April 18, 2011 Sanjay Wadhwa Intended Status: Informational Sanjay Wadhwa (ed.)
Juniper Networks Alcatel-Lucent
Expires: January 11, 2012
Thomas Haag
Deutsche Telekom
October 18, 2010 Hongyu Li
HuaweiTechnologies
Applicability of Access Node Control Mechanism to July 11, 2011
PON based Broadband Networks
draft-ietf-ancp-pon-00.txt Applicability of Access Node Control Mechanism to
PON based Broadband Networks
draft-ietf-ancp-pon-01.txt
Abstract Abstract
The purpose of this document is to provide applicability of Access The purpose of this document is to provide applicability of the
Node Control Mechanism, as described in [ANCP-FRAMEWORK], to PON Access Node Control Mechanism, as described in [ANCP-FRAMEWORK],
based broadband access. The need for an Access Node Control Mechanism to PON based broadband access. The need for an Access Node Control
between a Network Access Server (NAS) and an Access Node Complex (a Mechanism between a Network Access Server (NAS) and an Access Node
combination of Optical Line Termination (OLT) and Optical Network Complex (a combination of Optical Line Termination (OLT) and
Termination (ONT) elements), is described in a multi-service Optical Network Termination (ONT) elements) is described in a
reference architecture in order to perform QoS-related, service- multi-service reference architecture in order to perform QoS-
related and Subscriber-related operations. The Access Node Control related, service-related and Subscriber-related operations. The
Mechanism is also extended for interaction between components of the Access Node Control Mechanism is also extended for interaction
Access Node Complex (OLT and ONT). The Access Node Control mechanism between components of the Access Node Complex (OLT and ONT). The
will ensure that the transmission of the information does not need to Access Node Control mechanism will ensure that the transmission of
go through distinct element managers but rather uses a direct device- information between the NAS and Access Node Complex (ANX) and
device communication. This allows for performing access link related between the OLT and ONT within an ANX does not need to go through
operations within those network elements to meet performance distinct element managers but rather uses a direct device-to-
objectives. 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 Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. 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 Internet-Drafts are working documents of the Internet Engineering
and may be updated, replaced, or obsoleted by other documents at any Task Force (IETF), its areas, and its working groups. Note that
time. It is inappropriate to use Internet-Drafts as reference other groups may also distribute working documents as Internet-
material or to cite them other than as "work in progress." Drafts.
The list of current Internet-Drafts can be accessed at Internet-Drafts are draft documents valid for a maximum of six
http://www.ietf.org/1id-abstracts.html. 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 Internet-Draft Shadow Directories can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/1id-abstracts.html.
This Internet-Draft will expire on April 18, 2011. The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice This Internet-Draft will expire on January 11, 2012.
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright Notice
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Copyright (c) 2011 IETF Trust and the persons identified as the
Provisions Relating to IETF Documents document authors. All rights reserved.
(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 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.
1 Specification Requirements ................................... 4 Table of Contents
1. Specification Requirements ................................. 3
2. Introduction................................................ 3
3. Terminology ................................................ 5
4. Motivation for explicit extension of ANCP to FTTx PON ...... 6
5. Reference Model for PON Based Broadband Access Network.......7
5.1. Functional Blocks ....................................... 9
5.1.1. Home Gateway ........................................... 9
5.1.2. PON Access ........................................... 9
5.1.3. Access Node Complex .................................... 9
5.1.4. Access Node Complex Uplink to the NAS .................. 9
5.1.5. Aggregation Network .................................... 9
5.1.6. Network Access Server .................................. 10
5.1.7. Regional Network ................................... ....10
5.2. Access Node Complex Control Reference Architecture Options 10
5.2.1. ANCP+OMCI ANX control ................................ 10
5.2.2. All-ANCP ANX Control.................................... 12
6. Concept of Access Node Control Mechanism for PON based access12
7. Multicast ...................................................14
7.1. Multicast Conditional Access.............................. 15
7.2. Multicast Admission Control .............................. 17
7.3. Multicast Accounting .................................... 27
8. Remote Connectivity Check .................................. 28
9. Access Topology Discovery .................................. 29
10. Access Loop Configuration ................................. 30
11. ANCP versus OMCI between the OLT and ONT/ONU .............. 33
12. IANA Considerations ....................................... 33
13. Acknowledgements .......................................... 33
14. References ................................................ 34
14.1. Normative References .................................... 34
14.2. Informative References .................................. 34
2 Introduction ................................................. 4 1. Specification Requirements
2.1 Terminology ............................................ 5 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
3 Reference Architecture for PON Based Broadband Access Network 7 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
3.1 Home Gateway ........................................... 8 2. Introduction
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
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 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 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) Broadband PON
(BPON), (2) Gigabit PON (GPON), (3) 10-Gigabit PON (XGPON), and (4)
Ethernet PON (EPON). This document describes the applicability of
Access Node Control Protocol (ANCP) in the context of FTTB/C and FTTP
deployments, focusing on BPON, GPON and XPON. Architectural
considerations lead to different ANCP compositions. Therefore, the
composition of ANCP communication between Access Nodes and Network
Access Server (NAS) is described using different models.
6 Multicast .................................................. 12 BPON, GPON and XPON 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, and XPON provides 10 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.
6.1 Multicast Conditional Access .......................... 12 The motive behind BPON, GPON and XPON deployment is providing triple-
6.2 Multicast Admission Control ........................... 15 play services over IP: voice, video and data. Voice is generally low
6.3 Multicast Accounting .................................. 26 bandwidth but has low-delay, low-jitter, and low packet-loss
7 Remote Connectivity Check ................................... 27 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 subscriber, using IP multicast.
Video on demand is also considered for delivery to the subscriber
over IP using a unicast session model.
8 Access Topology Discovery ................................... 28 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 Access Node (AN) complex 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 AN complex
(ANX) and the NAS, specifically focusing on bandwidth dedicated for
multicast and shared bandwidth between multicast and unicast.
9 Security Considerations ..................................... 28 [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 extends that framework and
the related requirements to explicitly address PON deployments.
10 Differences in ANCP applicability between DSL and PON ....... 29 3. Terminology
11 ANCP versus OMCI between the OLT and ONT .................... 30 - 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 Terminal (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.
12 IANA Considerations ......................................... 31 - Access Node Complex (ANX): The Access Node Complex is 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 which does not depend on the physical location but
rather on the "black box" behavior of OLT and ONU/ONT.
13 Acknowledgements ............................................ 31 -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.
14 References .................................................. 31 - 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 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 certain cases, one ONT may provide connections to more than
one Home Gateway at the same time.
14.1 Normative References .................................. 31 -Optical Network Unit (ONU): A generic term denoting a device that
14.2 Informative References ................................ 31 terminates any one of the distributed (leaf) endpoints of an Optical
Author's Addresses ............................................. 32 Distribution Node (ODN), implements a PON protocol, and adapts PON
PDUs to subscriber service interfaces. In case of an MDU multi-
dwelling or multi-tenant unit), 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".
1 Specification Requirements -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).
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL -Home Gateway (HGW): Network element that connects subscriber devices
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to the AN or ANX and the access network. In case of xDSL, the Home
in this document are to be interpreted as described in RFC 2119. Gateway is an xDSL 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.
2 Introduction -PON-Customer-ID: This is an identifier which 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 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-Identifier" Sub-option in Option-82
of the DHCP messages.
Passive Optical Networks (PONs) based on BPON and GPON are being 4. Motivation for explicit extension of ANCP to FTTx PON
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 The fundamental difference between PON and DSL is that a PON is an
first mile, bandwidth that is an order of magnitude larger than that optical broadcast network by definition. That is, at the PON level,
provided by xDSL. In the downstream direction BPON provides 622 Mbps every ONT on the same PON sees the same signal. However, the ONT
per PON while GPON provides 2.4 Gbps. In residential deployments, the filters only those PON frames addressed to it. Encryption is used on
number of homes sharing the same PON is limited by the technology and the PON to prevent eavesdropping.
the network engineering rules. Typical deployments have 32 homes per
PON.
The motive behind BPON and GPON deployment is providing triple-play The broadcast PON capability is very suitable to delivering multicast
services over IP: voice, video and data. Voice is generally low content to connected premises, maximizing bandwidth usage efficiency
bandwidth but has low-delay, low-jitter, and low packet-loss on the PON. Similar to DSL deployments, enabling multicast on the
requirements. Data services (e.g., Internet services) often require Access Node Complex (ANX) provides for bandwidth use efficiency on
high throughput and can tolerate medium latency. Data services may the path between the Access Node and the NAS as well as improves the
include multimedia content download such as video. However, in that scalability of the NAS by reducing the amount of multicast traffic
case, the video content is not required to be real-time and/or it is being replicated at the NAS. However, the broadcast capability on the
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.
Providing simultaneous triple-play services over IP with unicast PON enables the AN (OLT) to send one copy on the PON as opposed to N
video and multicast video, VoIP and data requires an architecture copies of a multicast channel on the PON serving N premises being
that preserves the quality of service of each service. Fundamental to receivers. The PON multicast capability can be leveraged in the case
this architecture is ensuring the video content (unicast and of GPON and BPON as discussed in this document.
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 Fundamental to leveraging the broadcast capability on the PON for
coordinated admission control between a NAS and an AN with special multicast delivery is the ability to assign a single encryption key
focus on DSL deployments. This document proposes the extension of for all PON frames carrying all multicast channels or a key per set
that framework and the related requirements to explicitly address of multicast channels that correspond to service packages, or none.
BPON and GPON deployments. 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.
2.1 Terminology 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 PON (Passive Optical Network): a point-to-multipoint fiber to the - Access topology discovery
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 - Access Loop Configuration
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.
o Optical Line Terminal (OLT): is located in the Service - Multicast
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 - Optimized multicast delivery
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 - Unified video resource control
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 - NAS based provisioning of ANX
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 - Remote connectivity check
the ANX and the access loop logical port on the ANX to the 5. Reference Model for PON Based Broadband Access Network
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.
3 Reference Architecture for PON Based Broadband Access Network An overall end-to-end reference architecture of a PON access network
is depicted in Figure 1 and Figure 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:
The reference architecture used in this document is based on Ethernet - BPON with Ethernet uplink to the NAS and ATM on the PON side.
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. - GPON/XPON with Ethernet uplink to the NAS and Ethernet on the
PON
side
o GPON with Ethernet uplink to the BNG and Ethernet on the PON In case of an Ethernet aggregation network that supports new QoS-
side. enabled IP services (including Ethernet multicast replication), the
architecture builds on the reference architecture specified in the
Broadband Forum (BBF) [TR-101]. The Ethernet aggregation network
between a NAS and an OLT may be degenerated to one or more direct
physical Ethernet links.
In case of an Ethernet aggregation network that supports new QoS- Given the industry move towards Ethernet as the new access and
enabled IP services (including Ethernet multicast replication), aggregation technology for triple play services, the primary focus
the architecture builds on the reference architecture specified in throughout this document is on GPON/XPON and BPON with Ethernet
DSL Forum [TR-101]. The Ethernet aggregation network between a NAS between the NAS and the OLT.
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 Access Customer
aggregation technology for triple play services, the primary focus <----------Aggregation-------><-Prem->
throughout this document is on GPON and BPON with Ethernet between Network Network
the BNG and the OLT. Figures 1 and 2 depict an end-to-end
broadband network with PON access.
Access Customer +------------------+
<----------Aggregation---------><-Prem-> | Access Node |
Network Network | Complex (ANX) |
+---------+ +---+ +-----+ |+---+ +---+ | +---+
| | +-|NAS|--|Eth |--||OLT|-<PON>-|ONT|-|--|HGW|
NSP---+Regional | | +---+ |Agg | |+---+ +---+ | +---+
|Broadband| | +---+ +-----+ +------------------+
|Network |-+-|NAS| |
ASP---+ | | +---+ |
| | | +---+ |
+---------+ +-|NAS| | +---+ +---+
+---| +-<PON>-|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
| 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
FE/GE/VDSL FE/GE/VDSL
+----+ +---+ +---+ +---+
+-----------------+ | |--|HGW| +----------------+ | |-|HGW|
+---------+ +-----+ | +-----+ +----+ | | | +---+ +---------+ +-----+ | +-----+ +----+| | | +---+
| | +-|NAS |--| |Eth |--| OLT| |-<PON>-| | +---+ | | +-|NAS |--| |Eth |--|OLT||-<PON>- | |
NSP---+Regional | | +-----+ | |Agg | | | | | |ONT/|--|HGW| NSP---+Regional | | +-----+ | |Agg | | || | |ONT| +---+
|Broadband| | +-----+ | +-----+ +----+ | | |ONU | +---+ | | | | | | | || | | or|-|HGW|
|Network |-+-|NAS | +-----------------+ | | | . |Broadband| | +-----+ | +-----+ +----+| | |ONU| +---+
ASP---+ | | +-----+ | | | +---+ |Network |-+-|NAS | +----------------+ | | |
| | | +-----+ | | |--|HGW| ASP---+ | | +-----+ | | | +---+
+---------+ +-|NAS | | +----+ +---+ | | | +-----+ | | |-|HGW|
+-----+ | +---------+ +-|NAS | | +---+ +---+
| +---+ +---+ +-----+ |
+--|ONT|--|HGW| | +---+ +---+
+---+ +---+ +--|ONT|--|HGW|
Figure 2. FTTP/FTTC with multi-subscriber ONU serving MTUs/MDUs +---+ +---+
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.
3.1 Home Gateway 5.1. Functional Blocks
The Home Gateway (HGW) connects the different Customer Premises 5.1.1. Home Gateway
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 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 IP
configuration of devices within the home via DHCP, and performs
Network Address and Port Translation (NAPT) between the LAN and WAN
side. In 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 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.
PON access is composed of the ONT and OLT. PON ensures physical 5.1.2. PON Access
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 PON access is composed of the ONT/ONU and OLT. PON ensures physical
connectivity between the ONT/ONU at the customer 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 (or BNG) is assumed to be Ethernet in this
document.
This is composed of OLT and ONT and is defined in section 2.1. 5.1.3. Access Node Complex
3.4 Access Node Complex Uplink to the BNG This is composed of OLT and ONT/ONU and is defined in section 3.
The ANX uplink connects the OLT to the NAS. The fundamental 5.1.4. Access Node Complex Uplink to the NAS
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
technology. The focus in this document is on Ethernet as stated
earlier.
3.5 Aggregation Network 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
technology. The focus in this document is on Ethernet as stated
earlier.
The aggregation network provides traffic aggregation towards the NAS. 5.1.5. Aggregation Network
The Aggregation network is assumed to be Ethernet in this document.
3.6 Network Access Server The aggregation network provides traffic aggregation towards the NAS.
The Aggregation network is assumed to be Ethernet in this document.
The NAS is a network device which aggregates multiplexed Subscriber 5.1.6. Network Access Server
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 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
BroadBand Forum (BBF) TR-101 [TR-101]. In addition, the NAS supports
the Access Node Control functionality defined for the respective use
cases in this document.
The Regional Network connects one or more NAS and associated Access 5.1.7. Regional Network
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 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.
The fundamental difference between PON and DSL is that a PON is an 5.2. Access Node Complex Control Reference Architecture Options
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 Section 4 details the differences between xDSL access and PON access
content to connected premises, maximizing bandwidth usage efficiency and the implication of these differences on DSLAM control vs. OLT and
on the PON. Similar to DSL deployments, enabling multicast on the ONT/ONU (access node complex (ANX)) control. The following sections
Access Node Complex (ANX) provides for bandwidth use efficiency on describe two reference models: (1) ANCP+OMCI ANX control, and (2)
the path between the Access Node and the NAS as well as improves the all-ANCP ANX control. That is, the two models differ in the ONT/ONU
scalability of the NAS by reducing the amount of multicast traffic control within the ANX. Implementations, out of the scope of this
being replicated at the NAS. However, the broadcast capability on the document, may choose to implement one or the other based on the
PON enables the AN (OLT) to send one copy on the PON as opposed to N ONT/ONU type and the capabilities of the ONT/ONU and OLT. It is
copies of a multicast channel on the PON serving N premises being possible for an OLT or an OLT PON port to connect to ONTs/ONUs with
receivers. The PON multicast capability can be leveraged in the case different capabilities and for these two models to co-exist on the
of GPON and BPON as discussed in this document. same OLT and same PON. Section 11 describes the differences between
OMCI and ANCP in controlling the ONU/ONT.
Fundamental to leveraging the broadcast capability on the PON for OMCI is designed as a protocol between the OLT and ONT/ONU. It
multicast delivery is the ability to assign a single encryption key enables the OLT to configure and administer capabilities on the
for all PON frames carrying all multicast channels or a key per set ONT/ONU in BPON, GPON and XPON. ANCP is designed as a protocol
of multicast channels that correspond to service packages, or none. between the NAS and access node. It enables the NAS to enforce
It should be noted that the ONT can be a multi-Dwelling Unit (MDU) dynamic policies on the access node, and the access node to report
ONT with multiple Ethernet ports, each connected to a living unit. events to the NAS among other functions.
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 5.2.1. ANCP+OMCI ANX control
"quality-of-experience", including end-to-end bandwidth optimized Figure 3 depicts the reference model for ANCP+OMCI ANX control. In
multicast video delivery, there needs to be tight coordination this model, ANCP is enabled between the NAS and a connected OLT, and
between the NAS and the ANX. This interaction needs to be near real- OMCI is enabled between the OLT and an attached ONT/ONU. NAS
time as services are requested via application or network level communicates with the ANX via ANCP. The OLT acts as an ANCP/OMCI
signaling by broadband subscribers. ANCP as defined in [ANCP- gateway for communicating necessary events and policies between the
FRAMEWORK] for DSL based networks is very suitable to realize a OLT and ONT/ONU within the ANX and for communicating relevant
control protocol (with transactional exchange capabilities), between policies and events between the ONT/ONU and the NAS. The
PON enabled ANX and the NAS, and also between the components functionality performed by the OLT as ANCP/OMCI gateway will be
comprising the ANX i.e. between OLT and the ONT. Typical use cases application dependent (e.g., multicast control, topology discovery)
for ANCP in PON environment include the following: and should be specified in a related specification. It should be
noted that some applications are expected to require extensions. Such
extensions are expected to outside of ANCP scope, and may need to be
defined by the ITU-T. It should be noted that OMCI, in addition to
configuration and administration, provides the capability to report
status changes on an ONT/ONU with AVC (Attribute Value Change)
notifications. When ONT/ONU's DSL or Ethernet UNI attributes change,
a related ME (management Entity) will send a corresponding
notification (AVC) to the OLT. The OLT interworks such 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.
o Multicast +----------------------+
| ANX |
+---------+ +---+ +-----+ |+---+ +-------+ | +---+
| | +-|NAS|--|Eth |--||OLT|-<PON>-|ONU/ONT|-|-|HGW|
NSP---+Regional | | +---+ |Agg | |+---+ +-------+ | +---+
|Broadband| | +---+ +-----+ +----------------------+
|Network |-+-|NAS| |
ASP---+ | | +---+ |
| | | +---+ |
+---------+ +-|NAS| | +-------+ +---+
+---| +-<PON>-|ONU/ONT|-|HGW|
| +-------+ +---+
.............
| +---+ +---+
+-----|ONT|-|HGW|
+---+ +---+
ANCP OMCI
+<-------------->+<------------------->+
o Optimized multicast delivery 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 access control
o Unified video resource control 5.2.2. All-ANCP ANX Control
o NAS based provisioning of ANX 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.
o Access topology discovery +----------------------+
| Access Node Complex |
| (ANX) |
+---------+ +---+ +-----+ |+---+ +-------+ | +---+
| | +-|NAS|--|Eth |--||OLT|-<PON>-|ONU/ONT| |--|HGW|
NSP---+Regional | | +---+ |Agg | |+---+ +-------+ | +---+
|Broadband| | +---+ +-----+ +----------------------+
|Network |-+-|NAS| |
ASP---+ | | +---+ |
| | | +---+ |
+---------+ +-|NAS| | +-------+ +---+
+---| +-<PON>-|ONU/ONT|--|HGW|
| +-------+ +---+
.............
| +-------+ +---+
+---|ONU/ONT|--|HGW|
+-------+ +---+
o Remote connectivity check ANCP ANCP
+<----------------->+<----------->+
5 Concept of Access Node Control Mechanism for PON based access HGW: Home Gateway
NAS: Network Access Server
PON: Passive Optical Network
OLT: Optical Line Terminal
ONT: Optical Network Terminal
ONU: Optical Network Unit
The high-level communication framework for an Access Node Control Figure 4: All-ANCP ANX Reference Model
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
network element where the reporting and/or enforcement function
resides.
The reporting function is used to convey status information to the 6. Concept of Access Node Control Mechanism for PON based access
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.
+--------+ The high-level communication framework for an Access Node Control
| Policy | +----+ Mechanism is shown in Figure 5 for the ALL-ANCP ANX control model.
| Server | +--<PON>---|ONT |------- HGW The Access Node Control Mechanism defines a quasi real-time, general-
+--------+ + +----+ +---+ purpose method for multiple network scenarios with an extensible
| + +----------|ONT|------ HGW 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 control function, and reporting and/or
|NAS |---------------| | | | |-|------|HGW| enforcement function. Controller function is used to receive status
| |<------------->| | | | ONT | | +---+ information or admission requests from the reporting function. It is
+----+ ANCP | |OLT |------<PON>----| | | also used to trigger a certain behavior in the network element where
| | | | | | | +---+ the reporting and/or enforcement function resides.
| | | |<------------->| |-------- |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 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 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.
Figure 3. Conceptual Message Flow for Access Node Control Mechanism +--------+
| Policy | +----+
| Server | +--<PON>---|ONT |------- HGW
+--------+ + +----+ +---+
| + +----------|ONT|------ HGW
| + | +---+
| +----------------|-------------+
+----+ | +----+ | +-----+ | +---+
|NAS |---------------| | | | |-|------|HGW|
| |<------------->| | | | ONU | | +---+
+----+ 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
<--------------------><-------------------->
6 Multicast PPP, DHCP, IP
<----------------------------------------------------------->
With the rise of supporting IPTV services in a resource-efficient Figure 5. Conceptual Message Flow for Access Node Control Mechanism
way, multicast services are becoming increasingly important. in all-ANCP ANX control model
In order to gain bandwidth optimization with multicast, the As discussed previously, in different PON deployment scenarios, ANCP
replication of multicast content per access-loop needs to be may be used in variant ways and may interwork with other protocols,
distributed to the ANX. This can be done by ANX (OLT and ONT) e.g. OMCI. In the ANCP+OMCI model described earlier, the NAS
becoming multicast aware by implementing an IGMP snooping and/or maintains ANCP adjacency with the OLT while the OLT controls the
proxy function. The replication thus needs to be distributed between ONT/ONU via OMCI. The messages shown in Figure 6 show the conceptual
NAS, aggregation nodes, and ANX. In case of GPON, and in case of message flow for this model. The actual use of these flows, and the
BPON with Ethernet uplink, this is very viable. By introducing IGMP times or frequencies when these messages are generated depend on the
processing on the ANX and aggregation nodes, the multicast actual use cases.
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 | Policy |
NAS, while the ANX is being transparent to these messages. In this | Server |
scenario, the NAS can use ANCP to create replication state in the ANX +--------+ +---+ +---+
for efficient multicast replication. The NAS sends a single copy of | +---- |ONT|----------|HGW|
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. |NAS |---------------| | | | |-|------|HGW|
| |<------------->| | | | ONU | | +---+
+----+ ANCP | |OLT |------<PON>----| | |
| | | | | | | +---+
| | | |<------------->| |--------|HGW|
| | +----+ OMCI +-----+ | +---+
| +-----------------------------+
| | Access Node |
| Control Request | |
| ------------------>| Control Request |
| |-------------------->|
| | Control Response |
| Control Response |<------------------- |
|<-------------------| |
| |Admission Request |
| Admission Request |<--------------------|
|<-------------------| |
|Admission Response | |
|------------------->|Admission Response |
| |-------------------->|
|Information Report | |
|<-------------------| |
Access Node Control Operating Maintenance
Mechanism Control Interface (OMCI)
<--------------------><-------------------->
The following sections describe various use cases related to PPP, DHCP, IP
multicast. <--------------------------------------------------------->
6.1 Multicast Conditional Access Figure 6: Conceptual Message Flow for ANCP+OMCI ANX control model
In a Broadband FTTP access scenario, Service Providers may want to 7. Multicast
dynamically control, at the network level, access to some multicast With the rise of supporting IPTV services in a resource-efficient
flows on a per user basis. This may be used in order to way, multicast services are becoming increasingly important.
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 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 In order to gain bandwidth optimization with multicast, the
two approaches. It can be done on the NAS along with bandwidth based replication of multicast content per access-loop needs to be
admission control. The NAS can control the replication state on the distributed to the ANX. This can be done by ANX (OLT and ONT/ONU)
ANX based on the outcome of access and bandwidth based admission becoming multicast aware by implementing an IGMP snooping and/or
control. This is covered later in section 3.4. The other approach is proxy function. The replication thus needs to be distributed between
to provision the necessary conditional access information on the ANX NAS, aggregation nodes, and ANX. In case of GPON, and in case of BPON
(ONT and/or OLT) so the ANX can perform the conditional access with Ethernet uplink, this is very viable. By introducing IGMP
decisions autonomously. For these cases, the NAS can use ANCP to processing on the ANX and aggregation nodes, the multicast
provision black and white lists as defined in [ANCP-FRAMEWORK], on replication process is now divided between the NAS, the aggregation
the ANX so that the ANX can decide locally to honor a join or not. node(s) and ANX. This is in contrast to the ATM-based model, where
It should be noted that in the PON case, the ANX is composed of the NAS is the single element responsible for all multicast control and
ONT and OLT. Thus, this information can be programmed on the ONT replication. In order to ensure backward compatibility with the ATM-
and/or OLT. Programming this information on the ONT prevents based model, the NAS, aggregation node and ANX need to behave as a
illegitimate joins from propagating further into the network. A single logical device. This logical device must have exactly the same
third approach, outside of the scope, may be to program the HGW with functionality as the NAS in the ATM access/aggregation network. The
the access list. 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.
A White list associated with an Access Port identifies the multicast An alternative to multicast awareness in the ANX is for the
channels that are allowed to be replicated to that port. A Black subscriber to communicate the IGMP "join/leave" messages with the
list NAS, while the ANX is being transparent to these messages. In this
associated with an Access Port identifies the multicast channels scenario, the NAS can use ANCP to create replication state in the ANX
that for efficient multicast replication. The NAS sends a single copy of
are not allowed to be replicated to that port. It should be noted the multicast stream towards the ANX. The NAS can perform network-
that the black list if not explicitly programmed is the complement based conditional access and multicast admission control on multicast
of the white list and vice versa. joins, and create replication state in the ANX if the request is
admitted by the NAS.
If the ONT performs IGMP snooping and it is programmed with a The following sections describe various use cases related to
channel access list, the ONT will first check if the requested multicast.
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
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 7.1. Multicast Conditional Access
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: 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 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.
o An exact match for a (*,G) ASM group (e.g. <G=g.h.i.l>); 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 a later section. The other 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 [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/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, 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.
o An exact match for a (S,G) SSM channel (e.g. If the ONT/ONU performs IGMP snooping and it is programmed with a
<S=s.t.u.v,G=g.h.i.l>); 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.
o A mask-based range match for a (*,G) ASM group (e.g. <G=g.h.i.l/ The ONT/ONU, in addition to forwarding the IGMP join, sends an ANCP
Mask>); 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
known at the ONT/ONU and OLT. If the ONT/ONU has a white list and/or
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 this 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.
o A mask-based range match for a (S,G) SSM channel (e.g. The White List and Black List can contain entries allowing:
<S=s.t.u.v,G=g.h.i.l/Mask>);
The use of a White list and Black list may be applicable, for - An exact match for a (*,G) (Any Source Multicast (ASM) group
instance, to regular IPTV services (i.e. Broadcast TV) offered by an (e.g. <G=g.h.i.l>);
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 - An exact match for a (S,G) Source Specific Multicast (SSM)
can be programmed with these access lists. Having these access lists channel (e.g.
on the ONT prevents forwarding of unauthorized joins to the OLT or <S=s.t.u.v,G=g.h.i.l>);
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.
6.2 Multicast Admission Control - A mask-based range match for a (*,G) ASM group (e.g.
<G=g.h.i.l/
Mask>);
The successful delivery of Triple Play Broadband services is quickly - A mask-based range match for a (S,G) SSM channel (e.g.
becoming a big capacity planning challenge for most of the Service <S=s.t.u.v,G=g.h.i.l/Mask>);
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 The use of a White list and Black list may be applicable, for
traffic for the FTTP access is required, in order to avoid over- instance, to regular IPTV services (i.e. Broadcast TV) offered by an
subscribing the available bandwidth and negatively impacting the end- Access Provider to broadband (e.g., FTTP) subscribers. For this
user experience. Before honoring a user request to join a new application, the IPTV subscription is typically bound to a specific
multicast flow, the combination of ANX and NAS MUST ensure admission FTTP home, and the multicast channels that are part of the
control is performed to validate that there is enough video bandwidth subscription are well-known beforehand. Furthermore, changes to the
remaining on the PON, and on the uplink between the OLT and NAS to conditional access information are infrequent, since they are bound
carry the new flow (in addition to all other existing multicast and to the subscription. Hence the ANX can be provisioned with the
unicast video traffic) and that there is enough video bandwidth for conditional access information related to the IPTV service.
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 Instead of including the channel list(s) at the ONT/ONU, the OLT or
admission control on all multicast video traffic and unicast video NAS can be programmed with these access lists. Having these access
traffic that requires using the shared bandwidth with multicast lists on the ONT/ONU prevents forwarding of unauthorized joins to the
shr. Based on the outcome of admission control, NAS then controls OLT or NAS, reducing unnecessary control load on these network
the replication state on the ANX. 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.
The subscriber generates an IGMP join for the desired stream on its 7.2. Multicast Admission Control
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:
1. Available video bandwidth on the link to OLT 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.
2. Available video bandwidth on the PON interface 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 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:
3. Available video bandwidth on the last mile (access-port on the - One approach is for the NAS to perform bandwidth based
ONT/ONU). 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, performs conditional access, and
bandwidth based admission control on the IGMP request. The
bandwidth admission control is performed against the following:
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 The NAS can locally maintain and track video bandwidth it manages
for all the three levels mentioned above. The NAS can maintain for all the three levels mentioned above. The NAS can maintain
identifiers corresponding to the PON interface and the last mile identifiers corresponding to the PON interface and the last mile
(customer interface). It also maintains a channel map, associating (customer interface). It also maintains a channel map, associating
every channel (or a group of channels sharing the same bandwidth every channel (or a group of channels sharing the same bandwidth
requirement) with a data rate. For instance, in case of 1:1 VLAN requirement) with a data rate. For instance, in case of 1:1 VLAN
representation of the premise, the outer tag (S-VLAN) could be representation of the premises, the outer tag (S-VLAN) could be
inserted by the ANX to correspond to the PON interface on the OLT, 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 and the inner-tag could be inserted by the ANX to correspond to the
access-line towards the customer. Bandwidth tracking and access-line towards the customer. Bandwidth tracking and maintenance
maintenance for the PON interface and the last-mile could be done for the PON interface and the last-mile could be done on these VLAN
on these VLAN identifiers. In case if N:1 representation, the identifiers. In case of N:1 representation, the single VLAN inserted
single VLAN inserted by ANX could correspond to the PON interface by ANX could correspond to the PON interface on the OLT. The access
on the OLT. The access loop is represented via Customer-Port-ID loop is represented via Customer-Port-ID received in "Agent Circuit
received in "Agent Circuit Identifier" sub-option in DHCP messages. Identifier" sub-option in DHCP messages.
The NAS can perform bandwidth accounting on received IGMP messages. The NAS can perform bandwidth accounting on received IGMP
The video bandwidth is also consumed by any unicast video being messages. The video bandwidth is also consumed by any unicast video
delivered to the CPE. NAS can perform video bandwidth accounting being delivered to the CPE. NAS can perform video bandwidth
and control on both IGMP messages and on requests for unicast video accounting and control on both IGMP messages and on requests for
streams when either all unicast admission control is done by the unicast video streams when either all unicast admission control is
NAS or an external policy server makes a request to the NAS for done by the NAS or an external policy server makes a request to the
using shared bandwidth with multicast as described later in the NAS for using shared bandwidth with multicast as described later in
document. the document.
This particular scenario assumes the NAS is aware of the bandwidth This particular scenario assumes the NAS is aware of the bandwidth
on the PON, and under all conditions can track the changes in on the PON, and under all conditions can track the changes in
available bandwidth on the PON. On receiving an IGMP Join message, available bandwidth on the PON. On receiving an IGMP Join message,
NAS will perform bandwidth check on the subscriber bandwidth. If NAS will perform bandwidth check on the subscriber bandwidth. If this
this passes, and the stream is already being forwarded on the PON passes, and the stream is already being forwarded on the PON by the
by the OLT (which also means that it is already forwarded by the OLT (which also means that it is already forwarded by the NAS to the
NAS to the OLT), NAS will admit the JOIN, update the available OLT), NAS will admit the JOIN, update the available subscriber
subscriber bandwidth, and transmit an ANCP message to the OLT and bandwidth, and transmit an ANCP message to the OLT and in turn to the
in turn to the ONT to start replication on the customer port. If ONT/ONU to start replication on the customer port. If the stream is
the stream is not already being replicated to the PON by the OLT, not already being replicated to the PON by the OLT, the NAS will also
the NAS will also check the available bandwidth on the PON, and if check the available bandwidth on the PON, and if it is not already
it is not already being replicated to the OLT it will check the being replicated to the OLT it will check the bandwidth on the link
bandwidth on the link towards the OLT. If this passes, the towards the OLT. If this passes, the available PON bandwidth and the
available PON bandwidth and the bandwidth on the link towards the bandwidth on the link towards the OLT is updated. The NAS adds the
OLT is updated. The NAS adds the OLT as a leaf to the multicast OLT as a leaf to the multicast tree for that stream.
tree for that stream.
On receiving the message to start replication, the OLT will add the On receiving the message to start replication, the OLT will add
PON interface to its replication state if the stream is not already the PON interface to its replication state if the stream is not
being forwarded on that PON. Also, the OLT will send an ANCP 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 message to direct the ONT/ONU to add or update its replication state
with the customer port for that channel. The interaction between with the customer port for that channel. The interaction between ANX
ANX and NAS is shown in Figures 4 and 5. and NAS is shown in Figures 7 and 8. For unicast video streams,
For unicast video streams, application level signaling from the CPE application level signaling from the CPE typically triggers an
typically triggers an application server to request bandwidth based application server to request bandwidth based admission control from
admission control from a policy server. The policy server can in a policy server. The policy server can in turn interact with the NAS
turn interact with the NAS to request the bandwidth for the unicast to request the bandwidth for the unicast video flow if it needs to
video flow if it needs to use shared bandwidth with multicast. If use shared bandwidth with multicast. If the bandwidth is available,
the bandwidth is available, NAS will reserve the bandwidth, update NAS will reserve the bandwidth, update the bandwidth pools for
the bandwidth pools for subscriber bandwidth, the PON bandwidth, subscriber bandwidth, the PON bandwidth, and the bandwidth on the
and the bandwidth on the link towards the OLT, and send a response link towards the OLT, and send a response to the policy server, which
to the policy server, which is propagated back to the application is propagated back to the application server to start streaming.
server to start streaming. Otherwise, the request is rejected. Otherwise, the request is rejected.
+----+ +----+
+---<PON>-----------|ONT |-------- HGW +---<PON>---------- |ONT |-------- HGW
+ +----+ + +----+
+ +----+ + +----+
+ +--------- |ONT |-------- HGW + +--------- |ONT |-------- HGW
+----+ +----+ + +----+ +----+ +----+ + +----+
|NAS |---------------| |------<PON> |NAS |---------------| |------<PON>
| |<------------->| | + +-----+ | |<------------->| | + +-----+
+----+ ANCP |OLT | +--------- | |------- HGW +----+ ANCP |OLT | +--------- | |------- HGW
| | | | | | | | | |
| | |<------------------>| ONU |--------HGW | | |<------------------>| ONU |--------HGW
| +----+ ANCP | | +---+ | +----+ ANCP | | +---+
| | | |-------|HGW| | | | |-------|HGW|
| | +-----+ +---+ | | +-----+ +---+
| 1.IGMP JOIN(S/*,G) | | | 1.IGMP JOIN(S/*,G) | |
|<-------------------------------------------------------------| |<------------------------------------------------------------ |
2.| | | | 2.| | | |
+=======================+ | | +=======================+ | |
[Access Control & ] | | [Access Control & ] | |
[Subscriber B/W ] | | [Subscriber B/W ] | |
[PON B/W & OLT link B/W ] | | [PON B/W & OLT link B/W ] | |
[based Admission Control] | | [based Admission Control] | |
+=======================+ | | +=======================+ | |
| | | | | | | |
| | | | |-------------------> | | |
|-------------------->| | | 3.ANCP Replication-Start| | |
3.ANCP Replication-Start| | | (<S/*,G> or Multicast | | |
(<S/*,G> or Multicast MAC,Customer-Port-ID> | |MAC,Customer-Port-ID>| --------------------> | |
| | | | | |4.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 |---------------------> | |
|5.Multicast Flow(S,G)| | | | |6.Multicast Flow (S,G) | |
|On Multicast VLAN |---------------------->| | | |forwarded on | |
| |6.Multicast Flow (S,G) | | | |Unidirectional | |
| |forwarded on | | | |<Multicast GEM-PORT> | |
| |Unidirectional | | | |on the PON by OLT |--------------> |
| |<Multicast GEM-PORT> | | |7. Multicast Flow
| |on the PON by OLT |--------------->| |forwarded on |
|7. Multicast Flow |Customer-Port by|
|forwarded on | |ONT/OLT. |
|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
Figure 4. Interactions for NAS based Multicast Admission Control (no for PON).
IGMP processing on ANX, and NAS maintains available video bandwidth for
PON).
+----+ +----+
+---<PON>-----------|ONT |-------- HGW +---<PON>---------- |ONT |-------- HGW
+ +----+ + +----+
+ +----+ + +----+
+ +--------- |ONT |-------- HGW + +--------- |ONT |-------- HGW
+----+ +----+ + +----+ +----+ +----+ + +----+
|NAS |---------------| |------<PON> |NAS |---------------| |------<PON>
| |<------------->| | + +-----+ | |<------------->| | + +-----+
+----+ ANCP |OLT | +--------- | |------- HGW +----+ ANCP |OLT | +--------- | |------- HGW
| | | | | | | | | |
| | |<------------------>| ONU |--------HGW | | |<------------------>| ONU |--------HGW
| +----+ ANCP | | +---+ | +----+ ANCP | | +---+
| | | |--------|HGW| | | | |--------|HGW|
| | +-----+ +---+ | | +-----+ +---+
| | | | | | | |
| IGMP LEAVE(S/*,G) | | | IGMP LEAVE(S/*,G) | |
|<-------------------------------------------------------------| |<------------------------------------------------------------ |
| | | | | | | |
+====================+ | | | +====================+ | | |
[Admission Control ] | | | [Admission Control ] | | |
[<Resource Released> ] | | | [<Resource Released> ] | | |
+====================+ | | | +====================+ | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
|-------------------->| | | |-------------------> | | |
ANCP Replication-Stop | | | ANCP Replication-Stop | | |
(<S/*,G> or Multicast MAC,Customer-Port-ID) | | (<S/*,G> or Multicast MAC,Customer-Port-ID) | |
| | | | | | | |
| |---------------------->| | | |---------------------> | |
| | ANCP Replication-Stop | | | | ANCP Replication-Stop | |
(<S/*,G> or Multicast MAC,Customer-Port-ID) (<S/*,G> or Multicast MAC,Customer-Port-ID)
Figure 5. Interactions for NAS based Multicast Admission Control (no Figure 8. Interactions for NAS based Multicast Admission Control (no
IGMP processing on ANX, and NAS maintains available video bandwidth for IGMP processing on ANX, and NAS maintains available video bandwidth
PON). for PON).
. An alternate approach is required if the NAS is not aware of the - 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 bandwidth on the PON. In this case the OLT does the PON bandwidth
management, and requests NAS to perform bandwidth admission management, and requests NAS to perform bandwidth admission control
control on subscriber bandwidth and the bandwidth on the link to on subscriber bandwidth and the bandwidth on the link to the OLT.
the OLT.
ANX operation: ANX operation:
o ONT can snoop IGMP messages. If conditional access is configured - ONT/ONU can snoop IGMP messages. If conditional access is
and the channel is in the Black list (or it is not on the White configured and the channel is in the Black list (or it is not on the
list), ONT will drop the IGMP Join. If the channel passes the White list), ONT will drop the IGMP Join. If the channel passes the
conditional access check, the ONT will forward the IGMP Join, conditional access check, the ONT will forward the IGMP Join,and will
and will send a bandwidth admission control request to the OLT. send a bandwidth admission control request to the OLT. In case the
In case the multicast stream is already being received on the multicast stream is already being received on the PON, the ONT/ONU
PON, the ONT does not forward the stream to the access port does not forward the stream to the access port where IGMP is received
where IGMP is received, till it has received a positive till it has received a positive admission control response from the
admission control response from the OLT. OLT.
o OLT can snoop IGMP messages. It also receives a bandwidth - OLT can snoop IGMP messages. It also receives a bandwidth
admission control request from the ONT for the requested admission control request from the ONT/ONU for the requested
channel. It can be programmed with a channel bandwidth map. If channel. It can be programmed with a channel bandwidth map. If
the multicast channel is already being streamed on the PON, or the multicast channel is already being streamed on the PON, or
the channel bandwidth is less than the multicast available the channel bandwidth is less than the multicast available
bandwidth on the PON, the OLT forwards the IGMP request to the bandwidth on the PON, the OLT forwards the IGMP request to the
NAS and keeps track of the subscriber (identified by customer- NAS and keeps track of the subscriber (identified by customer-
Port-ID) as a receiver. If the channel is not already being Port-ID) as a receiver. If the channel is not already being
streamed on the PON, but the PON has sufficient bandwidth for streamed on the PON, but the PON has sufficient bandwidth for
that channel, the OLT reduces the PON multicast video bandwidth that channel, the OLT reduces the PON multicast video bandwidth
by the channel bandwidth and may optionally add the PON to the by the channel bandwidth and may optionally add the PON to the
multicast tree without activation for that channel. This is multicast tree without activation for that channel. This is
biased towards a forward expectation that the request will be biased towards a forward expectation that the request will be
accepted at the NAS. The OLT forwards the IGMP join to the NAS. accepted at the NAS. The OLT forwards the IGMP join to the NAS.
It also sends a bandwidth admission request to the NAS It also sends a bandwidth admission request to the NAS
identifying the channel, and the premise for which the request identifying the channel, and the premises for which the request
is made. It sets a timer for the subscriber multicast entry is made. It sets a timer for the subscriber multicast entry
within which it expects to receive a request from the NAS that within which it expects to receive a request from the NAS that
relates to this request. If the PON available bandwidth is relates to this request. If the PON available bandwidth is
less than the bandwidth of the requested channel, the OLT sends less than the bandwidth of the requested channel, the OLT sends
an admission response (with a reject) to the ONT, and does not an admission response (with a reject) to the ONT/ONU, and does not
forward the IGMP join to the NAS. forward the IGMP join to the NAS.
NAS operation: NAS operation:
The NAS receives the IGMP join from the subscriber on the The NAS receives the IGMP join from the subscriber on the
subscriber connection. When NAS receives the admission control subscriber connection. When NAS receives the admission control
request from ANX (also signifying the bandwidth on the PON is request from ANX (also signifying the bandwidth on the PON is
available), it performs admission control against the subscriber available), it performs admission control against the subscriber
available multicast bandwidth. If this check passes, and the NAS is available multicast bandwidth. If this check passes, and the NAS is
already transmitting that channel to the OLT, the request is already transmitting that channel to the OLT, the request is
accepted. If the check passes and the NAS is not transmitting the accepted. If the check passes and the NAS is not transmitting the
channel to the OLT yet, it performs admission control against the channel to the OLT yet, it performs admission control against the
multicast video available bandwidth (this includes the dedicated multicast video available bandwidth (this includes the dedicated
multicast bandwidth and the shared bandwidth between multicast and multicast bandwidth and the shared bandwidth between multicast and
video on demand) on the link(s) to the OLT. If the check passes, video on demand) on the link(s) to the OLT. If the check passes,
the request is accepted, the available video bandwidth for the the request is accepted, the available video bandwidth for the
subscriber and downlink to the OLT are reduced by the channel subscriber and downlink to the OLT are reduced by the channel
bandwidth, and the NAS sends an ANCP admission control response bandwidth, and the NAS sends an ANCP admission control response
(indicating accept) to the OLT, requesting the addition of the (indicating accept) to the OLT, requesting the addition of the
subscriber to the multicast tree for that channel. The OLT subscriber to the multicast tree for that channel. The OLT
activates the corresponding multicast entry if not active and activates the corresponding multicast entry if not active and
maintains state of the subscriber in the list of receivers for that 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 channel. The OLT also sends an ANCP request to the ONT/ONU to enable
reception of the multicast channel and forwarding to the subscriber reception of the multicast channel and forwarding to the subscriber
access port. Otherwise, if the request is rejected, the NAS will access port. Otherwise, if the request is rejected, the NAS will
send an admission reject to the OLT, which in turns removes the send an admission reject to the OLT, which in turns removes the
subscriber as a receiver for that channel (it it were added), and subscriber as a receiver for that channel (if it were added), and
credits back the channel bandwidth to the PON video bandwidth if credits back the channel bandwidth to the PON video bandwidth if
there is no other receiver on the PON for that channel. The there is no other receiver on the PON for that channel. The
interactions between ANX and NAS are show in Figures 6 and 7. 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 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 timer, the OLT removes the subscriber from the potential list of
receivers for the indicated channel. It also returns the allocated receivers for the indicated channel. It also returns the allocated
bandwidth to the PON available bandwidth if there are no other bandwidth to the PON available bandwidth if there are no other
receivers. In this case, the NAS may send a response to the OLT 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 with no matching entry as the entry has been deleted. The OLT must
perform admission control against the PON available bandwidth and perform admission control against the PON available bandwidth and
may accept the request and send an ANCP request to the ONT to may accept the request and send an ANCP request to the ONT/ONU to
activate the corresponding multicast entry as described earlier. If activate the corresponding multicast entry as described earlier. If
it does not accept the request, it will respond back to the NAS 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 with a reject. The NAS shall credit back the channel bandwidth to
the subscriber. It shall also stop sending the channel to the OLT the subscriber. It shall also stop sending the channel to the OLT
if that subscriber was the last leaf on the multicast tree towards if that subscriber was the last leaf on the multicast tree towards
the OLT. the OLT.
On processing an IGMP leave, the OLT will send an ANCP request to On processing an IGMP leave, the OLT will send an ANCP request to
NAS to release resources. NAS will release the subscriber NAS to release resources. NAS will release the subscriber
bandwidth. If this leave causes the stream to be no longer required bandwidth. If this leave causes the stream to be no longer required
by the OLT, the NAS will update its replication state and release by the OLT, the NAS will update its replication state and release
the bandwidth on the NAS to OLT link. the bandwidth on the NAS to OLT link.
If the subscriber makes a request for a unicast video stream (i.e., If the subscriber makes a request for a unicast video stream (i.e.,
Video on Demand), it results in appropriate application level Video on Demand), the request results in appropriate application
signaling, which typically results in an application server level signaling, which typically results in an application server
requesting a policy server for bandwidth-based admission control requesting a policy server for bandwidth-based admission control
for the VoD stream. The policy server after authorizing the for the VoD stream. The policy server after authorizing the
request, can send a request to the NAS for the required bandwidth request, can send a request to the NAS for the required bandwidth
if it needs to use bandwidth that is shared with multicast. This 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 request may be based on a protocol outside of the scope of this
document. The NAS checks if the available video bandwidth document. The NAS checks if the available video bandwidth
(accounting for both multicast and unicast) per subscriber and for (accounting for both multicast and unicast) per subscriber and for
the link to the OLT is sufficient for the request. If it is, it the link to the OLT is sufficient for the request. If it is, it
temporarily reserves the bandwidth and sends an ANCP admission temporarily reserves the bandwidth and sends an ANCP admission
request to the OLT for the subscriber, indicating the desired VoD request to the OLT for the subscriber, indicating the desired VoD
bandwidth. If the OLT has sufficient bandwidth on the corresponding bandwidth. If the OLT has sufficient bandwidth on the corresponding
PON, it reserves that bandwidth and returns an admission response 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 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 receives an accept, it returns an accept to the policy server which
in turn returns an accept to the application server, and the video in turn returns an accept to the application server, and the video
stream is streamed to the subscriber. This interaction is shown in stream is streamed to the subscriber. This interaction is shown in
Figure 8. If the NAS does not accept the request from the policy 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 server, it returns a reject. If the NAS receives a reject from the
OLT, it returns the allocated bandwidth pool to the subscriber and OLT, it returns the allocated bandwidth to the subscriber and
the downlink to the OLT. the downlink to the OLT.
+----+
+-------- |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 9. Interaction between NAS & ANX for Multicast Bandwidth
+----------|ONT |-------- HGW Admission Control in the All-ANCP ANX control model. Similar
+----+ +----+ + +----+ functionality will be required when OMCI is enabled between the OLT
|NAS |---------------| |------<PON> and ONT/ONU in the ANCP+OMCI ANX control model. In this latter case,
| |<------------->| | + +-----+ the OLT will act as ANCP-OMCI gateway.
+----+ 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
+----+
+--------- |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 +--------- |ONT |-------- HGW
+------------+ 1. VoD Request +----+ +----+ + +----+
| App. Server|<---------------------------------------------------- |NAS |---------------| |------<PON>
| Server | | |<------------->| | + +-----+
+------------+ +----+ ANCP |OLT | +--------- | |--------- HGW
| 2. Admission-Request (VoD-Flow) | | | ANCP | |
+-------+ | | |<------------------>| ONU |----------HGW
|Policy | | +----+ +-----+
|Server | | | | |
+-------+ |1.IGMP Join(s/*,G) +=============+ +=============+ |
| + |<------------------[IGMP Snooping]--------[IGMP snooping]---- |
|<-|---3. Admission-Request | +=============+ +=============+ |
| | | |2.Admission-Request | |
+ | 8. Admission-Reply | |(Flow,Customer-Port-ID) | |
+----+ + +----+ +-----+ | |<---------------------- | |
|NAS |---------------|OLT |------<PON>-------|ONT |------HGW----CPE | 2.+===============+ | |
| |<------------->| | +-----+ | | [ Access Ctrl ] | |
+----+ ANCP +----+ | | | [ & PON B/W ] | |
| | | | | [ Admission Ctrl] | |
4.| | | | | +===============+ PASS | |
+=================+ | | | |3.Admission-Request | | |
[Subscriber B/W ] | | | | <Flow,Customer-Port-ID> | |
[& OLT link B/W ] | | | |<--------------------| | |
[Admission Ctrl ] | | | 4.| | | |
+=================+PASS | | | +==================+ | | |
| | | | [Subscriber B/W ] | | |
| 5.Admission-Request | | | [& OLT link B/W ] | | |
|(Bandwidth,PON-Port-ID) | | [Admission Ctrl ] | | |
|-------------------> | | | +==================+FAIL | |
| | | | | | | |
| 6.+===============+ | | |5.Admission-Reply-Fail | |
| [ PON B/W ] | | |<Flow,Cust-Port-ID> | | |
| [ Admission Ctrl] | | |-------------------->| | |
| +===============+ PASS | | | 6.+==================+ | |
|7.Admission-Reply | | | | [Release PON B/W ] | |
| <PON-Port-ID> | | | | [Remove Repl.State ] | |
|<--------------------| | | | +==================+ | |
| | | | | | 7.Admission-Reply-Fail | |
| | | | | |<Flow,Cust-Port-ID> | |
| |----------------------> | |
| | 8.+============+ |
| | [Remove Repl.] |
| | [ State ] |
| | +============+ |
Figure 8. Interactions for VoD Bandwidth Admission Control Figure 10. Interaction between NAS and ANX for Multicast Bandwidth
Admission Control in the All-ANCP ANX control model. Similar
functionality will be required when OMCI is enabled between the OLT
and ONT/ONU in the ANCP+OMCI ANX control model. In this latter case,
the OLT will act as ANCP-OMCI gateway.
. A third possible approach is where the ANX is assumed to have a +------------+ 1. VoD Request
full knowledge to make an autonomous decision on admitting or | App. Server|<----------------------------------------------------
rejecting a multicast and a unicast join. With respect to the | Server |
interaction between ONT and OLT, the procedure is similar to the +------------+
first approach (i.e. NAS controlled replication). However, when the | 2. Admission-Request (VoD-Flow)
OLT receives an IGMP request for a subscriber, it performs +-------+
admission control against that subscriber multicast video bandwidth |Policy |
(dedicated and shared with Video on Demand), the PON and uplink to |Server |
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 |<-|---3. Admission-Request
downstream bandwidth from NAS to OLT and the selection is | |
communicated to the NAS, or the OLT has to be ready to receive the + | 8. Admission-Reply
stream on any link. If the check passes, the OLT updates the video +----+ + +----+ +-----+
available bandwidth per PON and subscriber. The OLT adds the |NAS |---------------|OLT |------<PON>-------|ONT |------HGW----CPE
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 +----+ ANCP +----+ | |
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 4.| | | |
subscriber and link available video bandwidth and the channel the +=================+ | | |
subscriber joined. The NAS upon receiving the ANCP information [Subscriber B/W ] | | |
message, updates the necessary information, including the OLT to [& OLT link B/W ] | | |
the multicast tree if it is not already on it. It should be noted [Admission Ctrl ] | | |
in this case that the ANCP message from the OLT to the NAS is being +=================+PASS | | |
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 | 5.Admission-Request | | |
acting as an IGMP proxy at the expense of added messages. In this |(Bandwidth,PON-Port-ID) | |
option, the OLT acts as the network IGMP router for the subscriber. |-------------------> | | |
| | | |
| 6.+===============+ | |
| [ PON B/W ] | |
| [ Admission Ctrl] | |
| +===============+ PASS | |
|7.Admission-Reply | | |
| <PON-Port-ID> | | |
|<------------------- | | |
| | | |
| | | |
For unicast video streams, the policy server receiving an admission Figure 11. Interactions for VoD Bandwidth Admission Control in the
request from an application server, as described before, may query All-ANCP ANX control model. Similar functionality will be required
the OLT for admission control as it has all information. If the OLT when OMCI is enabled between the OLT and ONT in the ANCP+OMCI ANX
has sufficient bandwidth for the stream it reserves that bandwidth control model. In this latter case, the OLT will act as ANCP-OMCI
for the subscriber, PON and OLT uplink to the NAS and returns an gateway.
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 -A third possible approach is where the ANX is assumed to have a
NAS, the policy server may make the admission request to the NAS. full knowledge to make an autonomous decision on admitting or
The NAS then sends an ANCP admission request to the OLT on behalf of rejecting a multicast and a unicast join. With respect to the
the policy server. The NAS returns an accept or reject to the policy interaction between ONT/ONU and OLT, the procedure is similar to the
server if it gets a reject or accept, respectively, from the OLT. 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 and shared with Video on Demand), the PON and uplink to
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/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.
6.3 Multicast Accounting 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 may be desirable to perform accurate per-user or per Access Loop It should be noted that if the policy server adjacency is with the
time or volume based accounting. In case the ANX is performing the NAS, the policy server may make the admission request to the NAS.
traffic replication process, it knows when replication of a multicast The NAS then sends an ANCP admission request to the OLT on behalf of
flow to a particular Access Port or user starts and stops. Multicast the policy server. The NAS returns an accept or reject to the policy
accounting can be addressed in two ways: server if it gets a reject or accept, respectively, from the OLT.
o ANX keeps track of when replication starts or stops, and 7.3. Multicast Accounting
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
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 It may be desirable to perform accurate per-user or per Access Loop
generates the time and/or volume based accounting information time or volume based accounting. In case the ANX is performing the
per Access Loop and per multicast flow, before sending it to a traffic replication process, it knows when replication of a multicast
central accounting system for logging. Since ANX communicates flow to a particular Access Port or user starts and stops. Multicast
with this accounting system directly, the approach does not accounting can be addressed in two ways:
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 - ANX keeps track of when replication starts or stops, and reports
asynchronously query the ANX to obtain an instantaneous status report this information to the NAS for further processing. In this case,
related to multicast flows currently replicated by the ANX. Such a ANCP can be used to send the information from the ANX to the NAS.
reporting functionality could be useful for troubleshooting and This can be done with the Information Report message. The NAS can
monitoring purposes. If the replication function in the ANX is then generate the appropriate time and/or volume accounting
distributed between the OLT and the ONT, then for some of the information per Access Loop and per multicast flow, to be sent to the
information required by the NAS (such as the list of access-ports on accounting system. The ANCP requirements to support this approach are
which a flow is being forwarded or list of flows being forwarded on specified in [ANCP-FRAMEWORK. If the replication function is
an access-port), a query to the OLT from the NAS will result in a distributed between the OLT and ONT/ONU, a query from the NAS will
query from OLT to ONT. The OLT responds back to the NAS when it result in OLT generating a query to the ONT/ONU.
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 - 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;
In an end-to-end Ethernet aggregation network, end-to-end Ethernet It may also be desirable for the NAS to have the capability to
OAM as specified in IEEE 802.1ag and ITU-T Recommendation Y.1730/1731 asynchronously query the ANX to obtain an instantaneous status report
can provide Access Loop connectivity testing and fault isolation. related to multicast flows currently replicated by the ANX. Such a
However, most HGWs do not yet support these standard Ethernet OAM reporting functionality could be useful for troubleshooting and
procedures. Also, in a mixed Ethernet and ATM access network (e.g. monitoring purposes. If the replication function in the ANX is
Ethernet based aggregation upstream from the OLT, and BPON distributed between the OLT and the ONT/ONU, then for some of the
downstream), interworking functions for end-to-end OAM are not yet information required by the NAS (such as the list of access-ports on
standardized and widely available. Until such mechanisms become which a flow is being forwarded or list of flows being forwarded on
standardized and widely available, Access Node Control mechanism an access-port), a query to the OLT from the NAS will result in a
between NAS and ANX can be used to provide a simple mechanism to test query from OLT to ONT/ONU. The OLT responds back to the NAS when it
connectivity of an access-loop from the NAS. 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.
Triggered by a local management interface, the NAS can use the Access 8. Remote Connectivity Check
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.
8 Access Topology Discovery 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 or 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.
In order to avoid congestion in the network, and manage and utilize Triggered by a local management interface, the NAS can use the Access
the network resources better, and ensure subscriber fairness, NAS Node Control Mechanism (Control Request Message) to initiate an
performs hierarchical shaping and scheduling of the traffic by Access Loop test between Access Node and HGW or ONT/ONU. On reception
modeling different congestion points in the network (such as the of the ANCP message, the OLT can trigger native OAM procedures
last-mile, Access Node uplink, and the access facing port). 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.
Such mechanisms require that the NAS gains knowledge about the 9. Access Topology Discovery
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 In order to avoid congestion in the network, manage and utilize the
manner the consistency of such data, notably across organizational network resources better, and ensure subscriber fairness, NAS
boundaries under certain deployment scenarios. The Access Topology performs hierarchical shaping and scheduling of the traffic by
Discovery function allows the NAS to perform these advanced functions modeling different congestion points in the network (such as the
without having to depend on an error-prone and possibly complex last-mile, Access Node uplink, and the access facing port).
integration with an OSS system.
The rate of the access-loop can be communicated via ANCP (Information Such mechanisms require that the NAS gains knowledge about the
Report Message) from the ONT to the OLT, and from OLT to the NAS. topology of the access network, the various links being used and
Additionally, during the time the DSL NT is active, data rate changes their respective rates. Some of the information required is somewhat
can occur due to environmental conditions (the DSL Access Loop can dynamic in nature (e.g. DSL line rate in case the last mile is xDSL
get "out of sync" and can retrain to a lower value, or the DSL Access based, e.g., in case of "PON fed DSLAMs" for FTTC/FTTB scenarios),
Loop could use Seamless Rate Adaptation making the actual data rate hence cannot come from a provisioning and/or inventory management OSS
fluctuate while the line is active). In this case, ANX sends an system. Some of the information varies less frequently (e.g.,
additional Information Report to the NAS each time the Access Loop capacity of the OLT uplink), but nevertheless needs to be kept
attributes change above a threshold value. strictly in sync between the actual capacity of the uplink and the
image the NAS has of it.
9 Security Considerations 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.
[ANCP-SECURITY] lists the ANCP related security threats that could The rate of the access-loop can be communicated via ANCP (Information
be encountered on the Access Node and the NAS. It develops a threat Report Message) from the ONT/ONU to the OLT in the All-ANCP ANX
model for ANCP security, and lists the security functions that are control model or via OMCI in the ANCP+OMCI ANX control model, and
required at the ANCP level. 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 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. Existing DSL procedures are not applicable in this case
because an adapted message flow and additional TLVs are needed.
With Multicast handling as described in this document, ANCP protocol +--------+
activity between the ANX and the NAS is triggered by join/leave | Policy |
requests coming from the end-user equipment. This could potentially | Server |
be used for denial of service attack against the ANX and/or the NAS. +--------+ + +---+ +---+
| + +-----------|ONT|---- |HGW|
| + | +---+ +---+
| +--------------- |-------------------+
+----+ | +----+ | +-----+ | +---+
|NAS |------------ | | | | | |-|-|HGW|
| |<----------> | | | | |ONT/ | | +---+
+----+ ANCP | |OLT |------<PON>--------- |ONU | |
| | | | | | | +---+
| | | |<------------------> | |---|HGW|
| | +----+ OMCI +-----+ | +---+
| +------------------------------------+
| | Access Node |
| | |
| |------GPON Ranging------ |
| Port Status Message| ONT Port UP |
|<------------------ |<----------------------- |
|Port Configuration |GPON Line/Service Profile|
|------------------> |<----------------------> |
| ONT/ONI Port UP| |
|<------------------ | |
| | |
| ANCP | OMCI |
<-------------------><-----------------------> |
PPP, DHCP, IP
<----------------------------------------------------------->
To mitigate this risk, the NAS and ANX MAY implement control plane Figure 12: Message Flow for the use case of Topology Discovery for
protection mechanisms such as limiting the number of multicast flows the ANCP+OMCI access control model.
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 Figure 12 depicts a message flow for topology discovery when using
provisioning black lists as close to the subscriber as possible (e.g. the ANCP+OMCI access control model. Basically, when an ONT/ONU gets
in the ONT). 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 GPON Service profile is assigned
from OLT to ONT/ONU, the OLT reports the final status to NAS with
information about service profile and other information such as the
ONT/ONU port rate to the subscriber for instance.
10 Differences in ANCP applicability between DSL and PON 10.Access Loop Configuration
As it currently stands, both ANCP framework [ANCP-FRAMEWORK] and Topology Discovery reports access port identification to NAS when
protocol [ANCP-PROTOCOL] are defined in context of DSL access. Due to sending an Access Port Discovery message. This informs NAS
inherent differences between PON and DSL access technologies, ANCP identification of PON port on an Access Node. Based on Access Port
needs a few extensions for supporting the use-cases outlined in this Identification and on customer identification, service related
document for PON based access. These specific differences and parameters could be configured on an OLT and an ONU/ONT.
extensions are outlined below.
o In PON, the access-node functionality is split between OLT and ONT. Service related parameters could be sent to OLT via ANCP before or
Therefore, ANCP interaction between NAS and AN translates to after an ONU/ONT is up. Sending of ANCP loop Configuration messages
transactions between NAS and OLT and between OLT and ONT. The from NAS can be triggered by a management system or by customer
processing of ANCP messages (e.g. for multicast replication control) identification and authentication after Topology Discovery. It may be
on the OLT can trigger generation of ANCP messages from OLT to ONT. used for first time configuration (zero touch) or for
Similarly, ANCP messages from ONT to the OLT can trigger ANCP updating/upgrading customer's profile like C-VLAN ID, S-VLAN ID, and
exchange between the ONT and the NAS (e.g. admission-request service bandwidth.
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 Parameters of UNI (subscriber interface to HGW/CPE) of ONU/ONT can
ONTs on the same PON. The local-loop in case of DSL is point-to- also be configured via ANCP. When the ONU/ONT supports ANCP,
point. In case of DSL access network, the access facing port on the parameters of the UNI on ONU/ONT are sent to the ONU/ONT via ANCP. If
NAS (i.e. port to the network between NAS and the DSLAM), and the the ONU/ONT does not support ANCP, but only OMCI, parameters have to
access-facing ports on the DSLAM (i.e. customer's local-loop) are the be sent from the NAS to the OLT via ANCP first. Then, the OLT
two bandwidth constraint points that need to be considered for translates such configuration into OMCI and sends it to the ONU/ONT.
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 9 Security Considerations
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 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 [ANCP-SECURITY] lists the ANCP related security threats that could be
for channels replicated on a PON or a list of PONs and to specific encountered on the Access Node and the NAS. It develops a threat
access ports. The latter should trigger the OLT to query the ONT for model for ANCP security, and lists the security functions that are
a list of channels being replicated on all access ports or on required at the ANCP level.
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 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.
ONT Management and Control Interface (OMCI) [OMCI] is specified for To mitigate this risk, the NAS and ANX MAY implement control plane
in-band ONT management via the OLT. This includes configuring protection mechanisms such as limiting the number of multicast flows
parameters on the ONT. Such configuration can include adding an a given user can simultaneously join, or limiting the maximum rate of
access port on the ONT to a multicast tree and the ONT to a multicast join/leave from a given user.
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 Protection against invalid or unsubscribed flows can be deployed via
the same information elements that would be carried over ANCP, the provisioning black lists as close to the subscriber as possible (e.g.
OLT must perform the necessary translation between ANCP and OMCI for in the ONT).
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
configured by OLT requests.
12 IANA Considerations 10 Differences in ANCP applicability between DSL and PON
This document does not require actions by IANA. 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.
13 Acknowledgements - 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 flows in
Figures 5
and 6 of section 6. In case of DSL, the ANCP exchange is contained
between
two network elements (NAS and the DSLAM).
14 References - 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 7.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 7.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 9 in section 7.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).
14.1 Normative References - 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 case of DSL, the
replication can potentially be performed on NAS and/or the DSLAM.
Section 7.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
3) 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.
[RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., - For reporting purposes, ANCP must enable the NAS to query the OLT
and R. Wheeler, "A Method for Transmitting PPP Over for channels replicated on a PON or a list of PONs and to specific
Ethernet (PPPoE)", RFC 2516, February 1999. 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.
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation 11.ANCP versus OMCI between the OLT and ONT/ONU
over ATM Adaptation Layer 5", RFC 2684, September 1999.
14.2 Informative References ONT Management and Control Interface (OMCI) [OMCI] 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 suitable protocol for dynamic
transactions as required for the multicast application.
[RFC2881] Mitton, D. and M. Beadles, "Network Access Server If OMCI is selected to be enabled between the OLT and ONT/ONU to
Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, Jul carry the same information elements that would be carried over ANCP,
2000. 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,
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/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.
[ANCP-FRAMEWORK] Ooghe, S., et al., "Framework and Requirements 12. IANA Considerations
for Access Node Control Mechanism in Broadband Networks", RFC 5851,
May 2010.
[G.983.1] ITU-T recommendation G.983.1, Broadband optical access This document does not require actions by IANA.
systems based on Passive Optical Networks (PON).
[G.984.1] ITU-T recommendation G.984.1 Gigabit-capable Passive 13. Acknowledgements
Optical Networks (G-PON): General characteristics 14. References
[TR-101] Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL 14.1. Normative References
Aggregation", DSL Forum TR-101, May 2006.
[ANCP-SECURITY] Moustafa, H., Tschofenig, H., and S. De Cnodder, [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
"Security Threats and Security Requirements for the Access Node and R. Wheeler, "A Method for Transmitting PPP Over
Control Protocol (ANCP)", RFC 5713, January 2010. Ethernet (PPPoE)", RFC 2516, February 1999.
[OMCI] ITU-T recommendation G.984.4 GPON ONT Management and Control [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
Interface (OMCI) Specifications. over ATM Adaptation Layer 5", RFC 2684, September 1999.
[ANCP-PROTOCOL] Wadhwa, S et al, "Protocol for Access Node Control 14.2. Informative References
Mechanism in Broadband Networks", draft-ietf-ancp-protocol-12.txt,
August 2010, work in progress.
Author's Addresses [RFC2881] Mitton, D. and M. Beadles, "Network Access Server
Requirements Next Generation (NASREQNG) NAS Model", RFC 2881, Jul
2000.
Nabil Bitar [ANCP-FRAMEWORK] Ooghe, S., et al., "Framework and Requirements
Verizon for Access Node Control Mechanism in Broadband Networks", RFC 5851,
117 West Street May 2010.
Waltham, MA 02451
Email: nabil.n.bitar@verizon.com [G.983.1] ITU-T recommendation G.983.1, Broadband optical access
systems based on Passive Optical Networks (PON).
Sanjay Wadhwa [G.984.1] ITU-T recommendation G.984.1 Gigabit-capable Passive
Juniper Networks Optical Networks (G-PON): General characteristics
10 Technology Park Drive
Westford, MA 01886
Email: swadhwa@juniper.net [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-17.txt,
April 2011, work in progress.
Authors' Addresses
Nabil Bitar
Verizon
60 Sylvan Road
Waltham, MA 02451
Email: nabil.n.bitar@verizon.com
Sanjay Wadhwa
Alcatel-Lucent
701 East Middlefield Road
Mountain View, CA, 94043
Email: sanjay.wadhwa@alcatel-lucent.com
Hongyu Li
Email: hongyu.lihongyu@huawei.com
Thomas Haag
Email: HaagT@telekom.de
 End of changes. 182 change blocks. 
1252 lines changed or deleted 1490 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/