RFC 6934
Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs)
RFC 6934 💖 Part 1 of 10
Okay bestie, let's start with the basics 🎀. This is RFC 6934, called Applicability of the Access Node Control Mechanism to Broadband Networks Based on Passive Optical Networks (PONs). It's an Informational doc, so it's published for information and isn't a standards-track spec 👀. It came out in June 2013 and has ISSN 2070-1721. The editors are N. Bitar (Verizon) and S. Wadhwa (Alcatel-Lucent), and the other authors are T. Haag (Deutsche Telekom) and H. Li (Huawei Technologies). Its header has no "Obsoletes" or "Updates" line, so it isn't replacing or changing any other RFC 🦋.
Abstract 🌸
The goal here is to explain how the Access Node Control Mechanism applies to broadband access over Passive Optical Networks (PONs). The doc says a NAS (Network Access Server) and an Access Node Complex need an Access Node Control Mechanism between them. The Access Node Complex is made of an Optical Line Termination (OLT) and an Optical Network Termination (ONT) element. This is described in a multi-service reference architecture, so the network can handle QoS-related, service-related, and subscriber-related operations ✨. The mechanism is also extended so the OLT and ONT inside the Access Node Complex can talk to each other.
The big idea is that information moving between the NAS and the Access Node Complex (ANX), and between the OLT and ONT inside an ANX, doesn't have to bounce through separate element managers. Instead, the devices talk directly to each other device-to-device and stay on net 🔥. That makes it possible to do access-link-related operations inside those network elements so they can hit their performance objectives 💅.
Status of This Memo 🧚
This document isn't an Internet Standards Track specification. It's published just for information 🍓.
It's a product of the Internet Engineering Task Force (IETF), so it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check out Section 2 of RFC 5741 for that 🤓.
If you want the latest status, errata, or a way to send feedback, go to http://www.rfc-editor.org/info/rfc6934.
Copyright Notice 💜
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info), as they stand on the publication date. Please read these carefully, because they spell out your rights and restrictions for this doc 📜. Code components pulled from this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They come with no warranty, as described in the Simplified BSD License.
Table of Contents 🗺️
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Motivation for Explicit Extension of ANCP to FTTx PON ...........6
4. Reference Model for PON-Based Broadband Access Network ..........7
4.1. Functional Blocks ..........................................9
4.1.1. Home Gateway ........................................9
4.1.2. PON Access ..........................................9
4.1.3. Access Node Complex ................................10
4.1.4. Access Node Complex Uplink to the NAS ..............10
4.1.5. Aggregation Network ................................10
4.1.6. Network Access Server ..............................10
4.1.7. Regional Network ...................................10
4.2. Access Node Complex Control Reference Architecture
Options ...................................................11
4.2.1. ANCP+OMCI ANX Control ..............................11
4.2.2. All-ANCP ANX Control ...............................12
5. Concept of Access Node Control Mechanism for PON-Based Access ..13
6. Multicast ......................................................16
6.1. Multicast Conditional Access ..............................16
6.2. Multicast Admission Control ...............................18
6.3. Multicast Accounting ......................................30
7. Remote Connectivity Check ......................................31
8. Access Topology Discovery ......................................32
9. Access Loop Configuration ......................................34
10. Security Considerations .......................................34
11. Differences in ANCP Applicability between DSL and PON .........35
12. ANCP versus OMCI between the OLT and ONT/ONU ..................36
13. Acknowledgements ..............................................37
14. References ....................................................37
14.1. Normative References .....................................37
14.2. Informative References ...................................381. Introduction ✨
Okay, so PONs are a big deal right now 💅. There are two flavours, Broadband PON (BPON) [G.983.1] and Gigabit PON (GPON) [G.984.1], and carriers are rolling them out everywhere 🌈. There are two main PON deployment models. The first is Fiber to the Building/Curb (FTTB/FTTC), where the last-mile connection to the subscriber's premises runs over the local copper loop, often using Very High Speed Digital Subscriber Line (VDSL). The second is Fiber to the Premises (FTTP), where the PON reaches all the way into the subscriber's home. There are also four main PON technologies: (1) BPON, (2) GPON, (3) 10-Gigabit PON (XG-PON), and (4) Ethernet PON (EPON). This doc is about how ANCP (Access Node Control Protocol) works in FTTB/C and FTTP setups, and it focuses on BPON, GPON, and XG-PON 🦋. Because the architecture choices change how ANCP gets put together, the ANCP communication between Access Nodes (ANs) and Network Access Servers (NASs) is described using several different models.
Now the speed part, which is honestly wild 🔥. In FTTP deployments, BPON, GPON, and XG-PON give a huge amount of bandwidth in the first mile. It's an order of magnitude bigger than what xDSL gives. Downstream, BPON provides 622 Mbit/s per PON, GPON provides 2.4 Gbit/s, and XG-PON provides 10 Gbit/s 🚀.
In residential setups, the number of homes sharing one PON is limited by the technology and the network engineering rules. Typical deployments have 32-64 homes per PON 🏠.
Next, why anyone's doing this in the first place: it's all about triple-play services over IP, which means voice, video, and data 🎀. Voice doesn't need much bandwidth, but it really cares about low delay, low jitter, and low packet loss. Data services, like Internet access, usually want high throughput and can handle medium latency. Data can also include multimedia downloads like video, but then the video doesn't have to be real-time, or it's lower quality. Video services are the picky ones 😭. They deliver Standard Definition or High Definition content in real time or near real time, depending on the service model. Standard Definition content encoded with MPEG2 needs roughly 3.75 Mbit/s per stream, and High Definition content encoded with MPEG2 needs 15-19 Mbit/s, depending on how much compression is used. Video needs low jitter, low packet loss, and low start-time latency. There are two kinds: on demand, and broadcast (also called linear programming content). Linear programming content can be carried over Layer 1 on the PON, but this doc focuses on sending it over IP to the subscriber using IP multicast. Video on Demand (VoD) is also covered, delivered over IP using a unicast session model 🍿.
Now the tricky bit 🙈. To run triple-play over IP with unicast video, multicast video, VoIP, and data, you need an architecture that keeps each service's quality of service intact. The key thing is making sure the video (both unicast and multicast) going to the subscriber doesn't go over the bandwidth allocated for video services. Architectures usually guarantee data a minimum bandwidth and guarantee VoIP its own bandwidth 💜. QoS control across services usually happens at a Network Access Server (NAS), which is often called a Broadband Network Gateway (BNG) for subscriber management, and it handles per-subscriber and shared link resources. Efficient multicast video also means enabling multicast in the access network between the subscriber and the subscriber management platform. In a FTTP/B/C PON setup, that means turning on IP multicast on the ANX, which is made of the Optical Network Terminal (ONT) or Unit (ONU) and the Optical Line Terminal (OLT), as applicable. DSL is different, since there multicast only gets enabled on the DSL Access Multiplexer (DSLAM) 🌸.
The rest of this doc zooms in on the ANCP requirements needed for coordinated admission control of unicast and multicast video in FTTP/B/C PON environments, between the ANX and the NAS. It especially focuses on the bandwidth dedicated to multicast and the bandwidth shared between multicast and unicast 🧚.
[RFC5851] already gives the framework and requirements for coordinated admission control between a NAS and an AN, with a special focus on DSL deployments. This doc extends that framework and its related requirements so they explicitly cover PON deployments ✨.
(Part 2 is coming next, bestie, so stay tuned 💅🫶)
2. Terminology ✨
okay bestie, let's get the vocab down first 📚🎀 these terms show up everywhere, so they're worth knowing cold
- PON (Passive Optical Network) [G.983.1][G.984.1]: a point-to-multipoint FTTP network architecture 🌸 It uses unpowered splitters to split one optical signal from a central office, sent over a single optical fiber, out to multiple premises. Up to 32-128 may be supported on the same PON. A PON configuration has an Optical Line Terminal (OLT) at the service provider's central office (CO) and a number of Optical Network Units or Terminals (ONUs/ONTs) near end users, with an Optical Distribution Network (ODN) made of fibers and splitters in between. Compared with point-to-point architectures, a PON cuts down on the amount of fiber and CO equipment you need. so efficient 💅
- Access Node Complex (ANX): two geographically separated functional elements, OLT and ONU/ONT, working together 🦋 The general term Access Node Complex (ANX) is used when we're describing a functionality that doesn't depend on physical location, and instead depends on the "black box" behavior of the OLT and ONU/ONT.
- Optical Line Terminal (OLT): lives in the service provider's central office (CO) ✨ It terminates and aggregates multiple PONs, which gives fiber access to multiple premises or neighborhoods, on the subscriber side. It also interfaces with the Network Access Server (NAS) that handles subscriber management.
- Optical Network Terminal (ONT): terminates the PON on the network side and provides PON adaptation 💜 The subscriber side interface and the location of the ONT depend on the type of network deployment. For an FTTP deployment (fiber all the way to the apartment or living unit), the ONT has Ethernet connectivity (Fast Ethernet (FE) / Gigabit Ethernet (GE) / Multimedia over Coax Alliance (MoCA)) with the Home Gateway (HGW) / Customer Premises Equipment (CPE). In certain cases, one ONT may connect to more than one Home Gateway at the same time 👑
- Optical Network Unit (ONU): a generic term for a device that terminates any one of the distributed (leaf) endpoints of an Optical Distribution Network (ODN), implements a PON protocol, and adapts PON PDUs to subscriber service interfaces 🍓 In a multi-dwelling unit (MDU) or multi-tenant unit (MTU), a multi-subscriber ONU usually sits in the basement or a wiring closet (the FTTB case). It connects to each CPE at the subscriber premises over FE/GE/Ethernet (a native Ethernet link or over xDSL, typically VDSL). When fiber ends outside the premises (neighborhood or curbside) on an ONT/ONU, the last-leg-premises connections could use existing or new copper, with an xDSL physical layer (typically VDSL). In that case, the ONU is effectively a "PON-fed DSLAM" 🧚
- Network Access Server (NAS): a network element that aggregates subscriber traffic from a number of ANs or ANXs 🌈 The NAS is often an injection point for policy management and IP QoS in the access network. It's also called a Broadband Network Gateway (BNG) or a Broadband Remote Access Server (BRAS).
- Home Gateway (HGW): a network element that connects subscriber devices to the AN or ANX and to the access network 🏠 For xDSL, the Home Gateway is an xDSL network termination that can operate either as a Layer 2 bridge or as a Layer 3 router. In the latter case, the device is also called a Routing Gateway (RG). For PON, it's often a Layer 3 routing device, with the ONT doing the PON termination.
- PON-Customer-ID: an identifier that uniquely identifies the ANX and the access loop logical port on the ANX that goes to the subscriber (customer) premises 🔑 It's used in any interaction between the NAS and the ANX that relates to access loops. Logically, it's made up of information that identifies the OLT (which may be physically and directly connected to the NAS), the PON port on the OLT, the ONT/ONU, and the port on the ONT/ONU that connects to the subscriber HGW. When the OLT acts as a DHCP relay agent, it can encode the PON-Customer-ID in the "Agent Circuit ID" sub-option in Option 82 of the DHCP messages [RFC3046] 💖
3. Motivation for Explicit Extension of ANCP to FTTx PON
okay so the big difference between PON and DSL is that a PON is an optical broadcast network by definition 📡 At the PON level, every ONT on the same PON sees the same signal. The ONT filters out everything except the PON frames addressed to it. Encryption is used on the PON to prevent eavesdropping, so nosy neighbors are out of luck 🙈
The broadcast nature of PON is super handy for delivering multicast content to connected premises, which maximizes bandwidth efficiency on the PON 🌸 Like with DSL deployments, enabling multicast on the Access Node Complex (ANX) also improves bandwidth efficiency on the path between the Access Node and the NAS. It also makes the NAS more scalable, because there's less multicast traffic being replicated at the NAS. The broadcast capability on the PON lets the AN (OLT) send one copy onto the PON, instead of one copy to each receiver on the PON. The PON multicast capability can be used with GPON and BPON, as discussed in this document. it's giving efficiency 💅
Leveraging the PON broadcast capability for multicast delivery depends on being able to assign one of three things: no key, a single encryption key for all PON frames carrying all multicast channels, or a key per set of multicast channels that correspond to a service package 🔐 When encryption is used for multicast channels, the OLT generates the encryption key and sends it to each targeted ONT through the ONT Management and Control Interface (OMCI), as described in Section 15.5.2 of ITU-T G.987.3 [G.987.3] for XG-PON. Also, the ONT can be a multi-dwelling unit (MDU) ONT with multiple Ethernet ports, each connected to a living unit 🏢 So the ONT must not only be able to receive a multicast frame, it must also be able to forward that frame only to the Ethernet port with receivers for the corresponding channel. main character behavior for the ONT, honestly ✨
To deliver triple-play service with the necessary "quality-of-experience", including end-to-end bandwidth-optimized multicast video delivery, the NAS and the ANX need to be tightly coordinated 🎬 That interaction needs to be near real-time, since broadband subscribers request services through application- or network-level signaling. ANCP, as defined in [RFC5851] for DSL-based networks, is a great fit for a control protocol with transactional exchange capabilities between the PON-enabled ANX and the NAS. It also works between the components inside the ANX, meaning between the OLT and the ONT. Typical use cases for ANCP in the PON environment include the following:
- Access topology discovery
- Access loop configuration
- Multicast
- Optimized multicast delivery
- Unified video resource control
- NAS-based provisioning of ANX
- Remote connectivity check
4. Reference Model for PON-Based Broadband Access Network
here's the big picture 🗺️ The overall end-to-end reference architecture of a PON access network is shown in Figures 1 and 2. Figure 1 has an ONT serving a single HGW, and Figure 2 has an ONT/ONU serving multiple HGWs. An OLT may provide FTTP and FTTB/C access at the same time, but most likely not on the same PON port 🦋 The following PON cases are addressed in the context of this reference architecture:
- BPON with Ethernet uplink to the NAS and ATM on the PON side
- GPON/XG-PON with Ethernet uplink to the NAS and Ethernet on the PON side
In an Ethernet aggregation network that supports new QoS-enabled IP services (including Ethernet multicast replication), the architecture builds on the reference architecture specified in the Broadband Forum (BBF) [TR-101] 🌷 The Ethernet aggregation network between a NAS and an OLT may be reduced to one or more direct physical Ethernet links.
Since the industry is moving toward Ethernet as the new access and aggregation technology for triple-play services, the main focus of this document is GPON/XG-PON and BPON with Ethernet between the NAS and the OLT 💜
Access Customer
<---------Aggregation-------><-Prem->
Network Network
+------------------+
| Access Node |
| 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 FE/GE/VDSL
+---+ +---+
+----------------+ | |-|HGW|
+---------+ +-----+ | +-----+ +----+| | | +---+
| | +-|NAS |--| |Eth |--|OLT||-<PON>- | |
NSP--+Regional | | +-----+ | |Agg | | || | |ONT| +---+
|Broadband| | | | | | || | | or|-|HGW|
|Network | | +-----+ | +-----+ +----+| | |ONU| +---+
| |-+-|NAS | +----------------+ | | |
ASP--+ | | +-----+ | | | +---+
| | | +-----+ | | |-|HGW|
+---------+ +-|NAS | | +---+ +---+
+-----+ |
| +---+ +---+
+-|ONT|-|HGW|
+---+ +---+
Figure 2: FTTP/FTTB/C with Multi-Subscriber ONT/ONU Serving MTUs/MDUsnext up we're breaking down the functional blocks and network segments in this PON access reference architecture, so stay tuned 🫶
4.1. Functional Blocks
4.1.1. Home Gateway 🏠
Okay so the Home Gateway (HGW) is the bestie that connects all the CPEs to the ANX and the access network 💖. With PON, the HGW is a Layer 3 router 💅. It handles IP configuration for devices in the home via DHCP and does Network Address and Port Translation (NAPT) between the LAN and WAN side ✨. With FTTP/B/C, the HGW plugs into the ONT/ONU over an Ethernet interface. That Ethernet interface could sit on an Ethernet physical port or run over some other medium 🧚.
Lowkey wild: for FTTP there's a single box GPON CPE solution, where the ONT does the HGW job and the GPON adaptation function too 🤯🎀.
4.1.2. PON Access 🦋
PON access is the ONT/ONU and the OLT working together 🌈. PON keeps the ONT/ONU at the customer premises physically connected to the OLT. PON framing can be BPON or GPON.
On BPON, the protocol encapsulation is multi-protocol encapsulation over ATM Adaptation Layer 5 (AAL5), defined in [RFC2684]. That covers PPP over Ethernet (PPPoE, defined in [RFC2516]) or IP over Ethernet (IPoE) 🫶. On GPON, the protocol encapsulation is always IPoE 🍓. In every case, the connection between the AN (OLT) and the NAS (or BNG) is assumed to be Ethernet in this document 💜.
4.1.3. Access Node Complex 🌸
The Access Node Complex (ANX) is made up of the OLT and ONT/ONU, and it's defined in Section 2 📖✨.
4.1.4. Access Node Complex Uplink to the NAS 🛣️
The ANX uplink is what connects the OLT to the NAS 🔥. The fundamental requirements for it are traffic aggregation, Class of Service distinction, customer separation, and traceability 👑. You can get that with an ATM or an Ethernet-based technology. As mentioned earlier, this document focuses on Ethernet, so that's what we're vibing with 💅.
4.1.5. Aggregation Network 🧺
The aggregation network handles traffic aggregation toward the NAS. In this document it's assumed to be Ethernet 🦋.
4.1.6. Network Access Server 🛡️
The NAS is a network device that aggregates multiplexed subscriber traffic from a bunch of ANXs. It plays a central role in per-subscriber policy enforcement and QoS, so it's a major main character 👑💅. It's often called a Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS). A detailed definition of the NAS is given in [RFC2881]. The NAS hooks up to the aggregation network with 802.1Q or 802.1 Q-in-Q Ethernet interfaces, and toward the Regional Network with transport interfaces (e.g., GigE, PPP over Synchronous Optical Network (SONET)) 🌊. The NAS functionality matches the BNG functionality described in BBF TR-101 [TR-101]. On top of that, the NAS supports the Access Node Control functionality defined for the respective use cases in this document 🧠✨.
4.1.7. Regional Network 🌍
The Regional Network connects one or more NASs and their associated access networks to Network Service Providers (NSPs) and Application Service Providers (ASPs) 🌐. The NSP authenticates access, and it provides and manages the IP address given to subscribers. It's 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. Plot twist, but make it make sense 🙈🌈.
4.2. Access Node Complex Control Reference Architecture Options 🧩
Section 3 breaks down the differences between xDSL access and PON access, and what those differences mean for DSLAM control versus OLT and ONT/ONU (ANX) control 🔍. The next sections describe two reference models: (1) ANCP+OMCI ANX control and (2) All-ANCP ANX control. So the two models differ in how the ONT/ONU is controlled within the ANX 💜. Picking which model to implement may be based on the ONT/ONU type and the capabilities of the ONT/ONU and OLT, but that's an implementation-specific decision and it's outside the scope of this document 🤷♀️. It's possible for an OLT or an OLT PON port to connect to ONTs/ONUs with different capabilities, and for these two models to co-exist on the same OLT and same PON 🫶. Section 12 describes the differences between OMCI and ANCP when it comes to controlling the ONU/ONT 📚.
OMCI is designed as a protocol between the OLT and ONT/ONU. It lets the OLT configure and administer capabilities on the ONT/ONU in BPON, GPON, and XG-PON 🛠️. ANCP is designed as a protocol between the NAS and the Access Node. Among other things, it lets the NAS enforce dynamic policies on the Access Node, and lets the Access Node report events to the NAS 📡💅.
4.2.1. ANCP+OMCI ANX Control 🎀
Figure 3 shows the reference model for ANCP+OMCI ANX control 📸. In this model, ANCP is enabled between the NAS and a connected OLT, and OMCI is enabled between the OLT and an attached ONT/ONU. The NAS talks to the ANX via ANCP 🗣️. The OLT acts as an ANCP/OMCI gateway, passing along necessary events and policies between the OLT and the ONT/ONU within the ANX, and passing relevant policies and events between the ONT/ONU and the NAS 🦋. The functionality the OLT performs as an ANCP/OMCI gateway is application dependent (e.g., multicast control, topology discovery), and it should be specified in a related specification 📝. Also, some applications are expected to need ANCP and/or OMCI extensions to map messages between OMCI and ANCP, and OMCI extensions are likely to be defined by the ITU-T 🌏.
Something to notice: in addition to configuration and administration, OMCI can report status changes on an ONT/ONU with AVC (Attribute Value Change) notifications 🔔. When the ONT/ONU's DSL or Ethernet User-Network Interface (UNI) attributes change, a related Management Entity sends a corresponding AVC notification to the OLT. The OLT interworks that notification into an ANCP report and sends it to the connected NAS over the ANCP session between the OLT and the NAS 📬. Since the ANCP report carries info about the ONT/ONU's UNI and the OLT's PON port, the NAS can get accurate information about the access topology 🗺️💖.
+----------------------+
| ANX |
+---------+ +---+ +---+ |+---+ +-------+ | +---+
| | +-|NAS|--|Eth|--||OLT|-<PON>-|ONU/ONT|-|-|HGW|
NSP---+Regional | | +---+ |Agg| |+---+ +-------+ | +---+
|Broadband| | +---+ +---+ +----------------------+
|Network |-+-|NAS| |
ASP---+ | | +---+ |
| | | +---+ |
+---------+ +-|NAS| | +-------+ +---+
+---| +-<PON>-|ONU/ONT|-|HGW|
| +-------+ +---+
| +---+ +---+
+--|ONT|-----|HGW|
+---+ +---+
ANCP OMCI
+<--------------->+<----------->+
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 Control4.2.2. All-ANCP ANX Control 🌷
Figure 4 shows 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, relaying policies and events between the NAS and the ONT/ONU within the ANX, and also communicating policies and events between the OLT and the ONT/ONU 🔁. Note that in this model, OMCI (not shown) is expected to be enabled at the same time between the ONT and OLT, supporting the existing OMCI capabilities and applications on the PON, independent of ANCP or of the applications ANCP is meant to support 🧚♀️💜.
+----------------------+
| 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|
+-------+ +---+
ANCP ANCP
+<----------------->+<---------->+
HGW: Home Gateway
NAS: Network Access Server
PON: Passive Optical Network
OLT: Optical Line Terminal
ONT: Optical Network Terminal
ONU: Optical Network Unit
Figure 4: All-ANCP ANX Control Reference Model5. Concept of Access Node Control Mechanism for PON-Based Access ✨
okay so the big picture for the Access Node Control Mechanism 🦋 It's shown in Figure 5 for the All-ANCP ANX control model, and honestly it's giving quasi-real-time, general-purpose, and super extensible 💅 It's built to cover lots of different network scenarios, and the use cases in the sections that follow each get their own flavor. The mechanism also gets extended to run between the OLT and the ONT/ONU, which is so iconic 👑
The mechanism has two parts: a controller function and a reporting and/or enforcement function. The controller is the one who receives status info or admission requests from the reporting function. It's also the one that triggers a certain behavior on the network element where the reporting and/or enforcement function lives 🫶
The reporting function's whole job is conveying status information to the controller, specifically the info the controller needs to run its local functions 🌸 The enforcement function is the one the controller can reach out to when it wants to enforce a specific policy or trigger a local action 💜
Figure 5 shows the conceptual message flow. Here's the vibe check 👇
+--------+
| 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
<--------------------><-------------------->
PPP, DHCP, IP
<------------------------------------------------------>
Figure 5: Conceptual Message Flow for Access Node Control Mechanism
in All-ANCP ANX Control ModelThe actual use of these flows, and when or how often these messages get generated, depends on the specific use cases, which are covered in later sections 💅
As we talked about earlier, ANCP can be used in different ways across different PON deployment scenarios, and it can interwork with other protocols too, like OMCI 🌈 In the ANCP+OMCI control model we covered before, the NAS keeps its ANCP adjacency with the OLT, and the OLT controls the ONT/ONU through OMCI. Figure 6 shows the conceptual message flow for this model, and again, the actual use of these flows and the timing of the messages depend on the actual use cases 🎀
+--------+
| Policy |
| Server |
+--------+ +---+ +---+
| +---- |ONT|--------|HGW|
| | +---+ +---+
| +--------------- |-------------+
+----+ | +----+ | +-----+ | +---+
|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)
<--------------------><-------------------->
PPP, DHCP, IP
<------------------------------------------------------->
Figure 6: Conceptual Message Flow for ANCP+OMCI ANX Control Model6. Multicast 💖
okay this one is so important, bestie 📺 Supporting IPTV in a resource-efficient way is becoming a huge deal, so multicast services matter more and more 😭
To get the bandwidth optimization that multicast offers, the replication of multicast content per access loop has to be pushed out to the ANX 🔥 One way to do that is making the ANX (both the OLT and the ONT/ONU) multicast aware, by implementing IGMP [RFC3376] snooping and/or a proxy function [RFC4605]. So the replication gets split up between the NAS, the aggregation nodes, and the ANX, and this is super viable for GPON, and for BPON with an Ethernet uplink ✨
Here's the contrast 👀 In the ATM-based model, the NAS was the single element responsible for all multicast control and replication. But once you add IGMP processing on the ANX and the aggregation nodes, that work gets divided between the NAS, the aggregation node(s), and the ANX 🧚
To keep backward compatibility with the ATM-based model, the NAS, the aggregation node, and the ANX need to behave as a single logical device 💅 That logical device has to have exactly the same functionality as the NAS in the ATM access/aggregation network, no exceptions bestie. The Access Node Control Mechanism can help make sure this logical and functional equivalence actually happens, by swapping the necessary information between the ANX and the NAS 🫶
There's also an alternative to making the ANX multicast aware 🌸 In this version, the subscriber sends the IGMP "join/leave" messages to the NAS, and the ANX stays transparent to them. The NAS can then use ANCP to create replication state in the ANX for efficient multicast replication. The NAS sends a single copy of the multicast stream toward the ANX, and it can run network-based conditional access and multicast admission control on the multicast joins. If the NAS admits the request, it creates the replication state in the ANX 💜
The following sections dig into various use cases related to multicast 🦋
6.1. Multicast Conditional Access 🔐
okay so in a broadband FTTP/B/C setup, service providers may want to dynamically control, at the network level, who gets access to certain multicast flows on a per user basis 💅 this can be used to tell apart multiple Service Offers, or to realize/reinforce conditional access based on what a customer is subscribed to 🎀 ngl, in some environments application-layer conditional access (Digital Rights Management (DRM), for instance) may provide enough control, so network-based multicast conditional access may not be needed 🙈 but network-level access control can add to service security by stopping the subscriber from receiving a non-subscribed channel. it also boosts network security by stopping a multicast stream from being sent on a link or a PON because of a non-subscriber's request 🛡️✨
if you want network-based channel conditional access, there are two approaches 🦋 the first is to do it 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 (we'll cover this in a later section, bestie 🫶). the second approach is to provision the needed conditional access information on the ANX (ONT/ONU and/or OLT) so the ANX can make conditional access decisions on its own 👑 for these cases, the NAS can use ANCP to provision black and white lists as defined in [RFC5851] on the ANX, so the ANX can decide locally whether to honor a join or not. it should be noted that in the PON case, the ANX is made up of the ONT/ONU and OLT, so this information can be programmed on the ONT/ONU and/or OLT. programming it on the ONT/ONU stops illegitimate joins from propagating further into the network 🧚 a third approach, which is outside the scope of this document, may be to program the HGW with the access list 🌸 a white list associated with an Access Port identifies the multicast channels that are allowed to be replicated to that port, and a black list associated with an Access Port identifies the multicast channels that are not allowed to be replicated to that port. it should be noted that the black list, if not explicitly programmed, is the complement of the white list and vice versa 🌈
if the ONT/ONU does IGMP snooping and is programmed with a channel access list, it will first check whether the requested multicast channel is part of a white list or a black list associated with the Access Port where the IGMP join was received 🍓 if the channel is on a white list, the ONT/ONU will pass the join request upstream toward the NAS. the ONT/ONU must not start replicating the associated multicast stream to the Access Port, even if that 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 admission control criterion, and bandwidth-based admission control is another 💖 if the channel is on a black list, the ONT/ONU can autonomously discard the message, because that channel is not authorized for that subscriber 💀
in addition to forwarding the IGMP join, the ONT/ONU sends an ANCP admission request to the OLT identifying the channel to be joined and the premises ✨ premises identification to the OLT can be based on a Customer-Port-ID that maps to the Access Port on the ONT/ONU and is known at both the ONT/ONU and the OLT. if the ONT/ONU has a white list and/or black list per premises, the OLT does not need one 🫶 if the ONT/ONU does not have such a list, the OLT may be programmed with one for each premises, and in that case the OLT would perform the actions described earlier on the ONT/ONU 🔥 once the outcome of admission control (conditional access and bandwidth-based admission control) is determined by the OLT (either by interacting with the NAS or locally), it is informed to the ONT/ONU. OLT bandwidth-based admission control scenarios are defined in a later section 🎀
the white list and black list can contain entries that allow:
- an exact match for a (*,G) Any-Source Multicast (ASM) group (e.g.,
<G=g.h.i.l>) - an exact match for a (S,G) Source-Specific Multicast (SSM) channel (e.g.,
<S=s.t.u.v,G=g.h.i.l>) - a mask-based range match for a (*,G) ASM group (e.g.,
<G=g.h.i.l/Mask>) - a mask-based range match for a (S,G) SSM channel (e.g.,
<S=s.t.u.v,G=g.h.i.l/Mask>)
white and black lists may be useful for regular IPTV services (aka Broadcast TV) that an Access Provider offers to broadband (e.g., FTTP) subscribers 📺✨ for this application, the IPTV subscription is usually tied to one specific FTTP home, and the multicast channels in the subscription are known well ahead of time. plus, changes to the conditional access information are rare, since they're tied to the subscription 💜 so the ANX can be provisioned with the conditional access information related to the IPTV service. 😌
instead of putting the channel list(s) on the ONT/ONU, the OLT or NAS can be programmed with these access lists 🦋 having them on the ONT/ONU stops unauthorized joins from being forwarded to the OLT or NAS, which cuts down unnecessary control load on those network elements. likewise, doing access control at the OLT instead of the NAS (if it isn't done on the ONT/ONU) will reduce unnecessary control load on the NAS 🧠💅
6.2. Multicast Admission Control 🎟️
the successful delivery of triple-play broadband services is quickly turning into a big capacity-planning challenge for most service providers these days 😭 just increasing available bandwidth isn't always practical, cost-economical, and/or enough to keep the end-user experience good 🙈 especially with the strict QoS requirements of unicast applications like VoIP and Video on Demand, plus the fast growth of multicast interactive applications like "video conferencing", digital TV, and digital audio. these apps typically need low delay, low jitter, low packet loss, and high bandwidth 🌸 they're also typically "non-elastic", which means they run at a fixed bandwidth that can't be dynamically adjusted to whatever bandwidth is currently available 👑
an Admission Control (AC) Mechanism covering admission of multicast traffic for the FTTP/B/C access is required, so the available bandwidth doesn't get over-subscribed and wreck the end-user experience 💔 before honoring a user request to join a new multicast flow, the combination of ANX and NAS must make sure admission control is performed. it has to validate that there's enough video bandwidth left on the PON and on the uplink between the OLT and NAS to carry the new flow (on top of all the other existing multicast and unicast video traffic), and that there's enough video bandwidth for the subscriber to carry that flow 🫧 the solution needs to handle multiple flows per premises, and it needs to let bandwidth be dynamically shared across multicast and unicast video traffic per subscriber, PON, and uplink (no matter whether unicast AC is done 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. in other words, on top of the shared bandwidth, some video bandwidth could be dedicated to Video on Demand, while other video bandwidth could be dedicated to multicast 💖
this document focuses on multicast-allocated bandwidth, including the shared unicast and multicast bandwidth 🦋 so supporting admission control needs some form of synchronization between the entities doing multicast AC (e.g., the ANX and/or NAS), the entity doing unicast AC (e.g., the NAS or a policy server), and the entity actually enforcing the multicast replication (i.e., the NAS and the ANX). this synchronization can be achieved in a number of ways ✨
one approach is for the NAS to perform bandwidth-based admission control on all multicast video traffic, and on unicast video traffic that needs to use the shared bandwidth with multicast 🧚 based on the outcome of admission control, the NAS then controls the replication state on the ANX. the subscriber generates an IGMP join for the desired stream on its logical connection to the NAS. the NAS terminates the IGMP message and performs conditional access and bandwidth-based admission control on the IGMP request. the bandwidth admission control is performed against the following:
- available video bandwidth on the link to the OLT
- available video bandwidth on the PON interface
- available video bandwidth on the last mile (Access Port on the ONT/ONU)
the NAS can locally maintain and track the video bandwidth it manages for all three levels above 📊 it can maintain identifiers for the PON interface and the last mile (customer interface). it also keeps a channel map that associates every channel (or a group of channels sharing the same bandwidth requirement) with a data rate 🌈 for example, in the case of 1:1 VLAN representation of the premises, the outer tag (S-VLAN) could be inserted by the ANX to correspond to the PON interface on the OLT, and the inner tag could be inserted by the ANX to correspond to the access-line toward the customer. bandwidth tracking and maintenance for the PON interface and the last mile could be done on these VLAN identifiers 🎀 in the case of N:1 representation, the single VLAN inserted by the ANX could correspond to the PON interface on the OLT. the access loop is represented via the Customer-Port-ID received in the "Agent Circuit ID" sub-option in DHCP messages 💅
the NAS can perform bandwidth accounting on received IGMP messages 🧾 the video bandwidth is also used up by any unicast video being delivered to the CPE. the NAS can do video bandwidth accounting and control on both IGMP messages and on requests for unicast video streams when either all unicast admission control is done by the NAS, or an external policy server makes a request to the NAS for using shared bandwidth with multicast, as described later in the document 🌟
This scenario assumes the NAS knows how much bandwidth the PON has and can track how that bandwidth changes under all conditions 🧠✨. When an IGMP join message arrives, the NAS checks the subscriber bandwidth. If that passes and the stream is already being forwarded on the PON by the OLT (which also means the NAS is already forwarding it to the OLT) 🔥, the NAS admits the join, updates the available subscriber bandwidth, and sends an ANCP message to the OLT, which passes it along to the ONT/ONU to start replication on the customer port 💖.
If the stream isn't already being replicated to the PON by the OLT, the NAS also checks the available PON bandwidth. If the stream isn't already being replicated to the OLT either, the NAS checks the bandwidth on the link towards the OLT. If both checks pass, the available PON bandwidth and the link-to-OLT bandwidth get updated 🧮. The NAS then adds the OLT as a leaf on the multicast tree for that stream 🌳. When the OLT gets the start-replication message, it adds the PON interface to its replication state, as long as the stream isn't already being forwarded on that PON 🦋. The OLT also sends an ANCP message telling the ONT/ONU to add or update its replication state with the customer port for that channel 🎀.
The interactions between the ANX and the NAS are shown in Figures 7 and 8 💅.
Now, unicast video is a different vibe 🌸. Application-level signaling from the CPE usually makes an application server ask a policy server for bandwidth-based admission control. If the unicast flow needs to share bandwidth with multicast, the policy server can talk to the NAS to request bandwidth for it 🫶. If the bandwidth is available, the NAS reserves it, updates the pools for subscriber bandwidth, PON bandwidth, and the link towards the OLT, and sends a response to the policy server. That response gets passed back to the application server so streaming can start 🎬. Otherwise, the request gets rejected 😭.
+----+
+---<PON>---------- |ONT |------ HGW
+ +----+
+ +----+
+ +--------- |ONT |------ HGW
+----+ +----+ + +----+
|NAS |---------------| |------<PON>
| |<------------->| | + +-----+
+----+ ANCP |OLT | +--------- | |----- HGW
| | | | |
| | |<------------------>| ONU |------HGW
| +----+ ANCP | | +---+
| | | |-----|HGW|
| | +-----+ +---+
| 1.IGMP join (S/*,G) | |
|<---------------------------------------------------------- |
2.| | | |
+=======================+ | |
[Access Control & ] | |
[Subscriber B/W ] | |
[PON B/W & OLT link B/W ] | |
[based Admission Control] | |
+=======================+ | |
| | | |
|-------------------> | | |
3.ANCP Replication-Start| | |
(<S/*,G> or Multicast | | |
|MAC,Customer-Port-ID)| --------------------> | |
| |4.ANCP Replication-Start |
| (<S/*,G> or Multicast MAC,Customer-Port-ID)
|-------------------> | | |
|5.Multicast Flow(S,G)| | |
|on Multicast VLAN |---------------------> | |
| |6.Multicast Flow (S,G) | |
| |forwarded on | |
| |Unidirectional | |
| |<Multicast GEM-PORT> | |
| |on the PON by OLT |------------->|
7.Multicast Flow
forwarded on |
Customer-Port by|
|ONT/OLT. |
| |
Figure 7: Interactions for NAS-Based Multicast Admission Control
(No IGMP Processing on ANX and NAS Maintains Available Video
Bandwidth for PON) upon Channel Join
+----+
+---<PON>---------- |ONT |----- HGW
+ +----+
+ +----+
+ +--------- |ONT |----- HGW
+----+ +----+ + +----+
|NAS |---------------| |------<PON>
| |<------------->| | + +-----+
+----+ ANCP |OLT | +--------- | |---- HGW
| | | | |
| | |<------------------>| ONU |-----HGW
| +----+ ANCP | | +---+
| | | |-----|HGW|
| | +-----+ +---+
| | | |
| IGMP leave (S/*,G) | |
|<-----------------------------------------------------------|
| | | |
+====================+ | | |
[Admission Control ] | | |
[<Resource Released> ] | | |
+====================+ | | |
| | | |
| | | |
| | | |
|-------------------> | | |
ANCP Replication-Stop | | |
(<S/*,G> or Multicast MAC,Customer-Port-ID) | |
| | | |
| |---------------------> | |
| | ANCP Replication-Stop | |
(<S/*,G> or Multicast MAC,Customer-Port-ID)
Figure 8: Interactions for NAS-Based Multicast Admission Control
(No IGMP Processing on ANX and NAS Maintains Available Video
Bandwidth for PON) upon Channel LeaveOkay, plot twist 😱. An alternate approach is needed if the NAS doesn't know the PON bandwidth 🙃. In that case, the OLT handles PON bandwidth management and asks the NAS to run bandwidth admission control on the subscriber bandwidth and the link to the OLT. Here's what each element does 💜:
ANX operation:
- The ONT/ONU can snoop IGMP messages 👀. If conditional access is configured and the channel is on the black list (or not on the white list), the ONT drops the IGMP join 🚫. If the channel passes the conditional access check, the ONT forwards the IGMP join and sends a bandwidth admission control request to the OLT 📨. If the multicast stream is already being received on the PON, the ONT/ONU doesn't forward the stream to the Access Port where IGMP came in until it gets a positive admission control response from the OLT ⏳.
- The OLT can snoop IGMP messages too 🕵️. It also gets bandwidth admission control requests from the ONT/ONU for the requested channel, and it can be programmed with a channel bandwidth map 🗺️. If the channel is already streaming on the PON, or the channel bandwidth is less than the available multicast bandwidth on the PON, the OLT forwards the IGMP request to the NAS and tracks the subscriber (identified by Customer-Port-ID) as a receiver 🧾. If the channel isn't already streaming on the PON but the PON has enough room for it, the OLT subtracts the channel bandwidth from the PON multicast video bandwidth and may optionally add the PON to the multicast tree without activation for that channel 🌱. This is a forward-leaning approach, biased toward expecting the NAS to accept 🤞. The OLT forwards the IGMP join to the NAS and also sends a bandwidth admission request to the NAS, identifying the channel and the premises the request is for 📬. It starts a timer on the subscriber multicast entry, during which it expects a request from the NAS related to this one ⏱️. If the available PON bandwidth is less than the bandwidth of the requested channel, the OLT sends an admission response with a reject to the ONT/ONU and doesn't forward the IGMP join to the NAS 🙅.
NAS operation:
The NAS receives the IGMP join from the subscriber on the subscriber connection 📥. When the NAS gets the admission control request from the ANX (which also means the PON bandwidth is available), it runs admission control against the subscriber's available multicast bandwidth 🧐. If that check passes and the NAS is already transmitting that channel to the OLT, the request is accepted 🎉. If the check passes but the NAS isn't yet transmitting the channel to the OLT, it runs admission control against the available multicast video bandwidth on the link(s) to the OLT. That pool includes the dedicated multicast bandwidth and the bandwidth shared between multicast and Video on Demand 📊. If this check passes too, the request is accepted, the available video bandwidth for the subscriber and the downlink to the OLT are reduced by the channel bandwidth, and the NAS sends an ANCP admission control response indicating accept to the OLT 💌. That response asks the OLT to add the subscriber to the multicast tree for that channel. The OLT activates the corresponding multicast entry if it isn't active, and keeps the subscriber's state in the list of receivers for that channel 📋. The OLT also sends an ANCP request to the ONT/ONU to enable reception of the multicast channel and forwarding to the subscriber Access Port 🚀. Otherwise, if the request is rejected, the NAS sends an admission reject to the OLT. The OLT then removes the subscriber as a receiver for that channel (if they were added) and credits the channel bandwidth back to the PON video bandwidth, as long as there's no other receiver on the PON for that channel 🔄.
The interactions between the ANX and the NAS are shown in Figures 9 and 10 🌈✨.
If the OLT doesn't hear back from the NAS before its timer runs out 😬, it yeets the subscriber off the list of potential receivers for that channel 🫠. It also gives the allocated bandwidth back to the available PON bandwidth, but only if there are no other receivers 🦋. In that case the NAS may send a response to the OLT with no matching entry, because the entry has already been deleted ✨. The OLT must perform admission control against the available PON bandwidth. It may accept the request and send an ANCP request to the ONT/ONU to activate the corresponding multicast entry, like we talked about earlier 💅. If it doesn't accept the request, it responds to the NAS with a reject 💀. The NAS shall credit the channel bandwidth back to the subscriber 🫶. It also shall stop sending the channel to the OLT if that subscriber was the last leaf on the multicast tree towards the OLT 🌸.
On processing an IGMP leave, the OLT sends an ANCP request to the NAS to release resources 🧚. The NAS releases the subscriber bandwidth. If this leave means the OLT no longer needs the stream, the NAS updates its replication state and releases the bandwidth on the NAS to OLT link 💖.
If the subscriber asks for a unicast video stream (aka Video on Demand 🍿), that request kicks off application-level signaling. This usually means an application server asks a policy server for bandwidth-based admission control for the VoD stream 🎬. Once the policy server authorizes the request, it can send a request to the NAS for the bandwidth it needs if that bandwidth is shared with multicast 👑. This request may be based on a protocol outside the scope of this document 🙈. The NAS checks whether the available video bandwidth (counting both multicast and unicast) per subscriber and for the link to the OLT is sufficient for the request 👀. If it is, the NAS temporarily reserves the bandwidth and sends an ANCP admission request to the OLT for the subscriber, indicating the desired VoD bandwidth 🎀. If the OLT has enough bandwidth on the corresponding PON, it reserves that bandwidth and returns an accept to the NAS. If not, it returns a reject 💜. If the NAS receives an accept, it returns an accept to the policy server, which returns an accept to the application server, and the video stream is streamed to the subscriber 🔥. This interaction is shown in Figure 11 ⭐. If the NAS doesn't accept the request from the policy server, it returns a reject 💀. If the NAS receives a reject from the OLT, it returns the allocated bandwidth to the subscriber and the downlink to the OLT 😭.
It should be noted that similar functionality to what's described in this section and shown in Figures 9, 10, and 11 will be required when OMCI is enabled between the OLT and ONT/ONU in the ANCP+OMCI ANX control model 🌈. In that case, the OLT will act as an ANCP-OMCI gateway 🫶.
+----+
+-------- |ONT |-------- HGW
+----+ +----+ + +----+
|NAS |---------------| |------<PON>
| |<------------->|OLT | + +-----+
+----+ ANCP | | ANCP +--------- | ONU |------ HGW
| +----+<------------------>+-----+-------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
Admission Control in the All-ANCP ANX Control Model upon Success +----+
+--------- |ONT |------ HGW
+----+ +----+ + +----+
|NAS |---------------| |------<PON>
| |<------------->|OLT | + +-----+
+----+ ANCP | | ANCP +----------| ONU |----- HGW
| +----+<----------------->+-----+------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 10: Interaction between NAS and ANX for Multicast Bandwidth
Admission Control in the All-ANCP ANX Control Model upon Failure +------------+ 1. VoD Request
| App. Server|<-----------------------------------------------
| Server |
+------------+
| 2. Admission-Request (VoD-Flow)
+-------+
|Policy |
|Server |
+-------+
| +
|<-|---3. Admission-Request
| |
+ | 8. Admission-Reply
+----+ + +----+ +-----+
|NAS |---------------|OLT |------<PON>-------|ONT |---HGW--CPE
| |<------------->| | +-----+ |
+----+ ANCP +----+ | |
| | | |
4.| | | |
+=================+ | | |
[Subscriber B/W ] | | |
[& OLT link B/W ] | | |
[Admission Ctrl ] | | |
+=================+PASS | | |
| | | |
| 5.Admission-Request | | |
|(Bandwidth,PON-Port-ID) | |
|-------------------> | | |
| | | |
| 6.+===============+ | |
| [ PON B/W ] | |
| [ Admission Ctrl] | |
| +===============+ PASS | |
|7.Admission-Reply | | |
| <PON-Port-ID> | | |
|<------------------- | | |
| | | |
Figure 11: Interactions for VoD Bandwidth Admission Control
in the All-ANCP ANX Control ModelThe third approach is where the ANX is assumed to have full knowledge to make its own call on admitting or rejecting a multicast join and a unicast join 🧠✨. The ONT/ONU-to-OLT interaction looks a lot like the first approach (NAS-controlled replication) 🔁. The difference is that when the OLT gets an IGMP request from a subscriber, it runs admission control against that subscriber's multicast video bandwidth (dedicated, and shared with Video on Demand), the PON, and the uplink to the NAS 💅. Now, if there are multiple NAS-OLT links, there are three possibilities 🤔. The link the multicast stream has to go out on is either pre-determined, or the OLT picks it based on downstream bandwidth from NAS to OLT and tells the NAS which one it picked, or the OLT has to be ready to receive the stream on any link 🌈. If the check passes, the OLT updates the available video bandwidth per PON and per subscriber 📊. It adds the subscriber to the list of receivers, and adds the PON to the multicast tree if it isn't on it already 🌸. It also sends an ANCP request to the ONT/ONU to add the subscriber Access Port to that channel's multicast tree 🦋. Then it sends an ANCP message to the NAS telling it about the subscriber, the link's available video bandwidth, and the channel the subscriber joined 📨. When the NAS gets that ANCP information message, it updates what it needs to, including adding the OLT to the multicast tree if the OLT isn't on it yet 🫶. Quick aside: in this case, the ANCP message from the OLT to the NAS is what adds the OLT to a multicast tree, instead of an IGMP message 👀. The OLT can also send an IGMP message, with the OLT acting as an IGMP proxy, but that costs extra messages 💀. In this option, the OLT is the network IGMP router for the subscriber 👑.
For unicast video streams, the policy server gets an admission request from an application server (as described earlier) and may ask the OLT to do admission control, since the OLT has all the info 🎀. If the OLT has enough bandwidth for the stream, it reserves that bandwidth for the subscriber, the PON, and the OLT uplink to the NAS, then sends an accept back to the policy server ✅. It also tells the NAS (via an ANCP message) about the subscriber's available video bandwidth 📣. If the OLT rejects the policy server's request, it sends a reject back to the policy server 🙅♀️.
One more thing: if the policy server is adjacent to the NAS, the policy server may send the admission request to the NAS 🧚. The NAS then sends an ANCP admission request to the OLT on the policy server's behalf 🤝. Whatever the OLT says, the NAS flips it: a reject from the OLT becomes an accept to the policy server, and an accept from the OLT becomes a reject 🙃.
6.3. Multicast Accounting ✨
Sometimes you want accurate time-based or volume-based accounting per user or per access loop 💰. If the ANX is doing the traffic replication, it knows exactly when replication of a multicast flow to a particular Access Port or user starts and stops ⏱️. There are two ways to handle multicast accounting 💖:
- The ANX keeps track of when replication starts and stops, and reports that to the NAS for further processing 📝. In this case, ANCP can carry the info from the ANX to the NAS, using the Information Report message 📮. The NAS can then generate the time and/or volume accounting per access loop and per multicast flow, and send it to the accounting system 🧾. The ANCP requirements for this approach are specified in [RFC5851] 📖. If the replication function is split between the OLT and the ONT/ONU, a query from the NAS makes the OLT send a query to the ONT/ONU 🔎.
- The ANX keeps track of when replication starts and stops, and generates the time and/or volume accounting per access loop and per multicast flow itself, before sending it to a central accounting system for logging 🗂️. Since the ANX talks to that accounting system directly, this approach doesn't need ANCP at all, so it's beyond the scope of this document 🙅♀️. The NAS might also want to asynchronously query the ANX for an instant status report about the multicast flows the ANX is replicating right now 📡. That kind of reporting could be really useful for troubleshooting and monitoring 🔧. If the replication function in the ANX is split between the OLT and the ONT/ONU, then for some info the NAS wants (like the list of Access Ports a flow is forwarded on, or the list of flows forwarded on an Access Port), a query from the NAS to the OLT turns into a query from the OLT to the ONT/ONU 🔄. The OLT then answers the NAS once it gets the ONT/ONU's response 🫶. And if what the NAS wants is the list of PONs where a multicast channel is being replicated, or the list of channels being replicated on a PON, the OLT can return that too 🌈.
7. Remote Connectivity Check 🔍
In an end-to-end Ethernet aggregation network, end-to-end Ethernet Operations, Administration, and Maintenance (OAM) can test access loop connectivity and isolate faults 🧪. The standards for this are IEEE 802.1ag [802.1ag] and ITU-T Recommendation Y.1730/1731 [Y.1731] 📚. Ngl though, most HGWs don't support these standard Ethernet OAM procedures yet 😭. And in a mixed Ethernet and ATM access network (like Ethernet-based aggregation upstream from the OLT and BPON downstream), the interworking functions for end-to-end OAM aren't standardized yet or widely available 🙈. Until those mechanisms get standardized and widely available, the Access Node Control Mechanism between NAS and ANX can give you a simple way to test connectivity of an access loop from the NAS 🫧.
When a local management interface triggers it, the NAS can use the Access Node Control Mechanism (Control Request message) to start an access loop test between an Access Node and an HGW or ONT/ONU 🚀. When the OLT gets that ANCP message, it can trigger the native OAM procedures defined for BPON in [G.983.1] and for GPON in [G.984.1] 🧚♀️. The Access Node can send the test result back to the NAS in a Control Response message 💌.
8. Access Topology Discovery 🗺️
To avoid congestion, use network resources better, and keep subscribers fair, the NAS does hierarchical shaping and scheduling of traffic 💅. It does this by modeling the different congestion points in the network (like the last mile, the Access Node uplink, and the access-facing port) 🌊.
For this to work, the NAS needs to know the topology of the access network, the links in use, and their rates 🧠. Some of that info is kind of dynamic (like the DSL line rate if the last mile is xDSL-based, such as "PON-fed DSLAMs" in FTTC/FTTB setups), so it can't come from a provisioning and/or inventory management Operations Support System (OSS) 🙅♀️. Other info changes less often (like the capacity of the OLT uplink), but it still has to stay strictly in sync between the uplink's actual capacity and the NAS's image of it 🔒.
OSSs are rarely able to enforce consistency for this kind of data reliably and at scale 😤. That's especially true across organizational boundaries in certain deployment scenarios 🏢. The Access Topology Discovery function lets the NAS do these advanced things without depending on an error-prone, possibly complex integration with an OSS 🦋.
The rate of the access loop can be sent via ANCP (Information Report message) from the ONT/ONU to the OLT in the All-ANCP ANX control model, or via OMCI in the ANCP+OMCI ANX control model. Then the OLT passes it to the NAS via ANCP 📨. And while the DSL NT is active, the data rate can change because of environmental conditions 🌦️. The DSL access loop can go "out of sync" and retrain to a lower value, or it can use Seamless Rate Adaptation to make the actual data rate fluctuate while the line stays active 🎢. In that case, the ANX sends an extra Information Report to the NAS each time the access loop attributes change by more than a threshold value 📈. Existing DSL procedures don't apply here, because an adapted message flow and additional TLVs are needed 🙈.
+--------+
| Policy |
| Server |
+--------+ +---+ +---+
| +-----------|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
<------------------------------------------------------>
Figure 12: Message Flow for the Use Case of Topology Discovery for
the ANCP+OMCI Control ModelFigure 12 shows the message flow for topology discovery with the ANCP+OMCI control model 🎬. Basically, when an ONT/ONU connects to a PON, the OLT detects a new device and a GPON Ranging process kicks off 🌟. During that process, the OLT authorizes the ONT/ONU and identifies it by its ONT/ONU ID, PON Port ID, and max Bandwidth 🪪. That port status gets reported via ANCP to the NAS, and then potentially to the policy server through another mechanism that's out of scope for this document 📬. In a second step, once the OLT assigns the GPON service profile to the ONT/ONU, the OLT reports the final status to the NAS 💜. That includes the service profile and other info, like the ONT/ONU port rate to the subscriber, for instance 😍.
9. Access Loop Configuration ✨
okay so Topology Discovery gives the NAS the Access Port Identification when it sends an Access Port Discovery message 🔍 that's how the NAS figures out which PON port on an Access Node it's dealing with. Based on Access Port Identification and on customer identification, service-related parameters could be configured on an OLT and an ONU/ONT 💅
Service-related parameters could be sent to the OLT via ANCP before or after an ONU/ONT is up 🌈 sending ANCP loop configuration messages from the NAS can be triggered by a management system, or by customer identification and authentication after Topology Discovery. It may be used for first-time configuration (zero touch) 🧚 or for updating/upgrading a customer's profile, like C-VLAN ID, S-VLAN ID, and service bandwidth. main character glow-up energy ✨
Parameters of the User-Network Interface (UNI), which is the subscriber interface to the HGW/CPE of the ONU/ONT, can also be configured via ANCP 🎀 when the ONU/ONT supports ANCP, the UNI parameters on the ONU/ONT are sent to it via ANCP. If the ONU/ONT doesn't support ANCP but only OMCI, the parameters have to be sent from the NAS to the OLT via ANCP first. Then the OLT translates that configuration into OMCI and sends it to the ONU/ONT 🦋
10. Security Considerations 🔒
[RFC5713] lists the ANCP-related security threats that could be encountered on the Access Node and the NAS 😭 it develops a threat model for ANCP security and lists the security functions that are required at the ANCP level.
With multicast handling as described in this document, ANCP protocol activity between the ANX and the NAS is triggered by join/leave requests coming from the end-user equipment. This could potentially be used for a denial-of-service attack against the ANX and/or the NAS.
⚠️ Denial-of-service is seriously not the vibe. Read this part twice, bestie.
To mitigate this risk, the NAS and ANX may implement control plane protection mechanisms, such as limiting the number of multicast flows a given user can simultaneously join or limiting the maximum rate of join/leave from a given user 🛡️
Protection against invalid or unsubscribed flows can be deployed via provisioning black lists as close to the subscriber as possible (e.g., in the ONT) 🙈
User activity logging for accounting or tracking purposes could raise privacy concerns if it isn't appropriately protected 🥺 to protect that information, logging/accounting information can be exchanged with the corresponding server over a secure channel, and the information can be stored securely with policy-driven controlled access. privacy is everything, periodt 🔐
11. Differences in ANCP Applicability between DSL and PON 🎀
As it currently stands, both the ANCP framework [RFC5851] and protocol [RFC6320] are defined in the context of DSL access 💖 due to inherent differences between PON and DSL access technologies, ANCP needs a few extensions to support the use cases outlined in this document for PON-based access. These specific differences and extensions are outlined below.
- In PON, the access-node functionality is split between the OLT and the ONT 🧩 so ANCP interaction between the NAS and the AN translates to transactions between the NAS and the OLT, and between the OLT and the ONT. The processing of ANCP messages (e.g., for multicast replication control) on the OLT can trigger generation of ANCP messages from the OLT to the ONT. Similarly, ANCP messages from the ONT to the OLT can trigger an ANCP exchange between the OLT and the NAS (e.g., admission request messages). This is illustrated in the generic message flows in Figures 5 and 6 of Section 5. In the case of DSL, the ANCP exchange is contained between two network elements (the NAS and the DSLAM) 🙌
- The PON connection to the ONT is a shared medium between multiple ONTs on the same PON 🌸 in the case of DSL, the local loop is point-to-point. In the case of a DSL access network, the access-facing port on the NAS (i.e., the port to the network between the NAS and the DSLAM) and the access-facing ports on the DSLAM (i.e., the customer's local loop) are the two bandwidth constraint points that need to be considered for performing bandwidth-based admission control for multicast video and VoD delivered to the customer. In the case of PON access, in addition to the bandwidth constraint on the NAS-to-OLT facing ports and the subscriber-allocated bandwidth for video services, the bandwidth available on the PON for video is an additional constraint that needs to be considered for bandwidth-based admission control. If the bandwidth control is centralized in the NAS (as described in the first approach in 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 the second approach in Section 6.2), then additional ANCP request and response messages are required for the 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 6.2), or for the OLT to inform the NAS what stream bandwidth is sent to the subscriber so the NAS can take appropriate action (e.g., bandwidth adjustment for various types of traffic) 📊
- In PON, multicast replication can potentially be performed on three different network elements: (1) on the NAS, (2) on the OLT for replication to multiple PON ports, and (3) on the ONT/ONU for replication to multiple customer ports 🌟 in the case of DSL, replication can potentially be performed on the NAS and/or the DSLAM. Section 6.2 defines options for multicast replication in the case of PON. In the first option, the multicast replication is done on the AN but is controlled from the NAS via ANCP (based on the reception of per-customer IGMP messages on the NAS). In this option, the NAS needs to supply the OLT the set of PON-customer-IDs (as defined in Section 2) to which the multicast stream needs to be replicated. The PON-customer-ID identifies the OLT and the PON ports on the OLT, as well as the ONT and the Access Ports on the ONT where the multicast stream needs to be replicated. Upon receiving the request to update its multicast replication state, the OLT must update its replication state with the indicated PON ports, but may also need to interact with the ONT via ANCP to update the multicast replication state on the ONT with the set of Access Ports (as indicated by the NAS). In the case of DSL, the DSLAM only needs to update its own replication state based on the set of Access Ports indicated by the NAS 🎬
- For reporting purposes, ANCP must enable the NAS to query the OLT for channels replicated on a PON or a list of PONs, and to specific Access Ports. The latter should trigger the OLT to query the ONT for a list of channels being replicated on all Access Ports or on specific Access Ports to the premises. In a DSL case, it is sufficient to query the DSLAM for a list of channels being replicated on an Access Port or a list of Access Ports 📈
12. ANCP versus OMCI between the OLT and ONT/ONU 🥊
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. So OMCI can be a potential replacement for ANCP between the OLT and ONT/ONU, albeit it may not be a suitable protocol for the dynamic transactions required by the multicast application 🤔
If OMCI is selected to be enabled between the OLT and ONT/ONU to carry the same information elements that would be carried over ANCP, the OLT must perform the necessary translation between ANCP and OMCI for replication control messages received via ANCP. OMCI is an already available control channel, while ANCP requires a TCP/IP stack on the ONT/ONU that can be used by an ANCP client, and accordingly, it requires that the ONT/ONU be IP addressable for ANCP 🌐 most ONTs/ONUs today have a TCP/IP stack used by certain applications (e.g., VoIP and IGMP snooping). ANCP may use the same IP address that is often assigned for VoIP or, depending on the implementation, may require a different address. Sharing the same IP address between VoIP and ANCP may have other network implications on how the VoIP agent is addressed and on traffic routing. For instance, the VoIP traffic to/from the ONT is often encapsulated in a VLAN-tagged Ethernet frame and switched at Layer 2 through the OLT to the NAS, where it is routed. The VoIP agent in this case looks like another subscriber to the NAS. On the other hand, the ANCP session between the ONT and OLT is terminated at the OLT. Thus, the OLT must be able to receive/send IP traffic to/from the OLT, which will not work using this setting. Using a separate IP address for the purpose of ONT/ONU management or ANCP specifically may often be required when supporting ANCP. These considerations may favor OMCI in certain environments 💜
However, OMCI will not allow some of the transactions required in approach 2, where the ONT/ONU sends unsolicited requests to the OLT rather than being queried or configured by OLT requests. not everything is perfect, but we're getting there 🫠
13. Acknowledgements 🫶
The authors thank Rajesh Yadav and Francois Le Faucheur for their valuable comments and discussions 💕
14. References 📚
14.1. Normative References 💌
- [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
- [RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
- [RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A. Thyagarajan, "Internet Group Management Protocol, Version 3", RFC 3376, October 2002.
- [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, "Internet Group Management Protocol (IGMP) / Multicast Listener Discovery (MLD)-Based Multicast Forwarding ("IGMP/MLD Proxying")", RFC 4605, August 2006.
14.2. Informative References 📚✨
okay bestie, here's the reading list 🧚 these ones are the informative refs, so they're the extra background sources that the RFC points to. ngl the list is a whole vibe 💅
[802.1ag] IEEE 802.1ag, "Connectivity Fault Management", December
2007.
[RFC2881] Mitton, D. and M. Beadles, "Network Access Server
Requirements Next Generation (NASREQNG) NAS Model", RFC
2881, July 2000.
[RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S.
Wadhwa, "Framework and Requirements for an Access Node
Control Mechanism in Broadband Multi-Service Networks",
RFC 5851, May 2010.
[G.983.1] ITU-T G.983.1, "Broadband optical access systems based on
Passive Optical Networks (PON)", January 2005.
[G.984.1] ITU-T G.984.1, "Gigabit-capable Passive Optical Networks
(GPON): General characteristics", March 2008.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC
3046, January 2001.
[TR-101] Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL
Aggregation", DSL Forum TR-101, May 2006.
[RFC5713] 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 G.984.4, "Gigabit-capable passive optical networks
(G-PON): ONT management and control interface
specification", February 2008.
[RFC6320] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T.
Taylor, Ed., "Protocol for Access Node Control Mechanism
in Broadband Networks", RFC 6320, October 2011.
[G.987.3] ITU-T G.987.3, "10-Gigabit-capable passive optical
networks(XG-PON): Transmission convergence (TC) layer
specification", October 2010.
[Y.1731] ITU-T Y.1731, "OAM functions and mechanisms for Ethernet
based networks", May 2006.Authors' Addresses 🎀
these are the people who wrote it, so you know exactly who to thank (or blame 😭)
Nabil Bitar (editor)
Verizon
60 Sylvan Road
Waltham, MA 02451
EMail: nabil.n.bitar@verizon.com
Sanjay Wadhwa (editor)
Alcatel-Lucent
701 East Middlefield Road
Mountain View, CA, 94043
EMail: sanjay.wadhwa@alcatel-lucent.com
Thomas Haag
Deutsche Telekom
EMail: HaagT@telekom.de
Hongyu Li
Huawei Technologies
EMail: hongyu.lihongyu@huawei.comthat's the whole spec, we did it 🌈💖👑
📦 where this page comes from
- ietf: rfc6934 2013-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms