RFC 5851
Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks
RFC 5851 🎀 Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks
okay bestie, here's the tea on the title block 💅
- Stream: Internet Engineering Task Force (IETF)
- Authors: S. Ooghe (Alcatel-Lucent), N. Voigt (Nokia Siemens Networks), M. Platnic (ECI Telecom), T. Haag (Deutsche Telekom), and S. Wadhwa (Juniper Networks)
- Category: Informational 🧚 (so not a Standards Track thing, just useful info)
- ISSN: 2070-1721
- Date: May 2010
- Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates
Abstract
so the whole point of this doc is to set up a framework for an Access Node Control Mechanism 🦋 that sits between a Network Access Server (NAS) and an Access Node (think a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture. the goal is handling service, quality of service, and subscriber stuff. the mechanism makes sure info doesn't have to bounce through separate element managers, and the devices just talk directly, device to device. that means access-link operations can happen inside those network elements without messing with the existing Operational Support Systems, which is seriously iconic ✨
the doc first lists use cases where this mechanism may be a good fit 🌸. then it lays out the requirements for the Access Node Control Protocol (ANCP) that must be taken into account during protocol design. finally, it covers requirements for the network elements that need to support ANCP and those use cases. these requirements should be seen as guidelines rather than absolute requirements, so RFC 2119 therefore does not apply to the nodal requirements 🙈
Status of This Memo
this document is not an Internet Standards Track specification. it's published for informational purposes 🧚
it's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every doc the IESG approves is a candidate for any level of Internet Standard, so see Section 2 of RFC 5741 for that drama 💀
info about the current status, any errata, and how to give feedback lives at http://www.rfc-editor.org/info/rfc5851 ✨
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved 💜
this document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. please read these carefully, because they spell out your rights and restrictions for this document 🫶
code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. they're provided without warranty, as described in the Simplified BSD License.
this document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. the person(s) controlling the copyright in some of that material may not have granted the IETF Trust the right to allow modifications outside the IETF Standards Process. so unless you get an adequate license from whoever controls the copyright in those materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process. the exceptions are formatting it for publication as an RFC or translating it into languages other than English 🌈
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5
1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
2. General Architecture Aspects . . . . . . . . . . . . . . . . . 7
2.1. Concept of an Access Node Control Mechanism . . . . . . . 7
2.2. Reference Architecture . . . . . . . . . . . . . . . . . . 8
2.2.1. Home Gateway . . . . . . . . . . . . . . . . . . . . . 9
2.2.2. Access Loop . . . . . . . . . . . . . . . . . . . . . 9
2.2.3. Access Node . . . . . . . . . . . . . . . . . . . . . 9
2.2.4. Access Node Uplink . . . . . . . . . . . . . . . . . . 10
2.2.5. Aggregation Network . . . . . . . . . . . . . . . . . 10
2.2.6. Network Access Server . . . . . . . . . . . . . . . . 10
2.2.7. Regional Network . . . . . . . . . . . . . . . . . . . 10
2.3. Prioritizing Access Node Control Traffic . . . . . . . . . 11
2.4. Interaction with Management Systems . . . . . . . . . . . 12
2.5. Circuit Addressing Scheme . . . . . . . . . . . . . . . . 12
3. Use Cases for Access Node Control Mechanism . . . . . . . . . 13
3.1. Access Topology Discovery . . . . . . . . . . . . . . . . 13
3.2. Access-Loop Configuration . . . . . . . . . . . . . . . . 15
3.3. Remote Connectivity Test . . . . . . . . . . . . . . . . . 16
3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 17
3.4.1. Multicast Conditional Access . . . . . . . . . . . . . 18
3.4.2. Multicast Admission Control . . . . . . . . . . . . . 21
3.4.3. Multicast Accounting and Reporting . . . . . . . . . . 26
3.4.4. Spontaneous Admission Response . . . . . . . . . . . . 27
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1. ANCP Functional Requirements . . . . . . . . . . . . . . . 28
4.2. ANCP Multicast Requirements . . . . . . . . . . . . . . . 29
4.3. Protocol Design Requirements . . . . . . . . . . . . . . . 30
4.4. Access Node Control Adjacency Requirements . . . . . . . . 31
4.5. ANCP Transport Requirements . . . . . . . . . . . . . . . 31
4.6. Access Node Requirements . . . . . . . . . . . . . . . . . 32
4.6.1. General Architecture . . . . . . . . . . . . . . . . . 32
4.6.2. Control Channel Attributes . . . . . . . . . . . . . . 33
4.6.3. Capability Negotiation Failure . . . . . . . . . . . . 33
4.6.4. Adjacency Status Reporting . . . . . . . . . . . . . . 33
4.6.5. Identification . . . . . . . . . . . . . . . . . . . . 34
4.6.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 34
4.6.7. Message Handling . . . . . . . . . . . . . . . . . . . 36
4.6.8. Parameter Control . . . . . . . . . . . . . . . . . . 37
4.7. Network Access Server Requirements . . . . . . . . . . . . 37
4.7.1. General Architecture . . . . . . . . . . . . . . . . . 37
4.7.2. Control Channel Attributes . . . . . . . . . . . . . . 39
4.7.3. Capability Negotiation Failure . . . . . . . . . . . . 39
4.7.4. Adjacency Status Reporting . . . . . . . . . . . . . . 40
4.7.5. Identification . . . . . . . . . . . . . . . . . . . . 40
4.7.6. Multicast . . . . . . . . . . . . . . . . . . . . . . 40
4.7.7. Message Handling . . . . . . . . . . . . . . . . . . . 42
4.7.8. Wholesale Model . . . . . . . . . . . . . . . . . . . 42
5. Management-Related Requirements . . . . . . . . . . . . . . . 43
6. Security Considerations . . . . . . . . . . . . . . . . . . . 44
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 45
8.1. Normative References . . . . . . . . . . . . . . . . . . . 45
8.2. Informative References . . . . . . . . . . . . . . . . . . 451. Introduction ✨
okay so DSL tech is everywhere for broadband access in Next Generation Networks 🌈. a few docs, Broadband Forum TR-058 [TR-058], Broadband Forum TR-059 [TR-059], and Broadband Forum TR-101 [TR-101], describe possible architectures for these access networks. their scope is delivering voice, video, and data services 📱
this framework is aimed at DSL-based access, either ATM/DSL or Ethernet/DSL 💖. it's going to stay open to other access technologies too, like Passive Optical Networks that use DSL tech at the Optical Network Unit (ONU), or wireless tech like IEEE 802.16 🦋. use cases such as Access Topology Discovery, Remote Connectivity Test, and Multicast could apply to those access techs too, but the details are outside the scope of this doc 🙈
traditional architectures need Permanent Virtual Circuit(s) per subscriber. that virtual circuit is configured on layer 2 and terminated at the first layer 3 device, like a Broadband Remote Access Server (BRAS) 🧚. besides the data plane, the models define architectures for element, network, and service management. interworking at the management plane isn't always possible, because of organizational boundaries between the departments running the local loop, the ATM network, and the IP network. also, management networks usually aren't designed to send management data between entities in real time 💀
when you deploy value-added services over DSL access networks, you have to pay special attention to quality of service and service control 😤. that means tighter coordination between Network Nodes (like Access Nodes and Network Access Server (NAS)), without burdening the Operational Support System (OSS) with unpractical expectations 💅
so there's a need for an Access Node Control Mechanism between a NAS and an Access Node (like a Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi-service reference architecture 🫶. it's for handling service, quality of service, and subscribers. the mechanism makes sure info doesn't have to go through separate element managers, and devices use direct device-to-device communication instead. that means access-link operations can happen inside those network elements without impacting the existing OSSes 🔥
this document gives a framework for that mechanism and identifies use cases where it can be justified 🌸. then it presents requirements for the Access Node Control Protocol (ANCP) and for the network elements that need to support it 👑
the requirements in this document are based on work done by the Broadband Forum [TR-147] 🎀
1.1. Requirements Notation
so the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in [RFC2119] 🤓✨
part 1 of 11 is a wrap! 🦋 more parts coming, don't go anywhere 💜
1.2. Definitions ✨
okay so bestie, this is the glossary section 🤓💖 it's where the document defines all its key terms so everyone's on the same page. no cap, these definitions are the foundation of everything else, so let's get them right 💅
- Access Node (AN): a network device, usually sitting at a service provider's central office or in a street cabinet, that terminates the access-loop connections coming from subscribers 🏢. when the access loop is a Digital Subscriber Line (DSL), people often call this a DSL Access Multiplexer (DSLAM) ✨.
- Network Access Server (NAS): a network device that aggregates the multiplexed subscriber traffic coming from a bunch of Access Nodes 🌸. the NAS is the main character when it comes to per-subscriber policy enforcement and quality of service (QoS) 👑. it's also often called a Broadband Network Gateway (BNG) or Broadband Remote Access Server (BRAS) 🎀. a more detailed definition of the NAS is given in [RFC2881] 📚.
- "Net Data Rate": defined by ITU-T G.993.2 [G.993.2], section 3.39 💜. it's the portion of the total data rate that can actually be used to send user information (like ATM cells or Ethernet frames) 📦. it leaves out overhead tied to the physical transmission mechanism (like trellis coding in the case of DSL) 🙅♀️. it does include TPS-TC (Transport Protocol Specific - Transmission Convergence) encapsulation, which is zero for ATM encapsulation and non-zero for 64/65 encapsulation 🌈.
- "Line Rate": defined by ITU-T G.993.2 🦋. it contains the complete overhead, including Reed-Solomon and Trellis coding 🫶.
- Access Node Control Mechanism: a method for multiple network scenarios, with an extensible communication scheme that carries status and control information between one or more ANs and one or more NASes 💫, all without needing intermediate element managers 🙅♀️✨.
- Control Channel: a bidirectional IP communication interface between the controller function (in the NAS) and the reporting/enforcement function (in the AN) 🧚. it's assumed that this interface is configured (rather than discovered) on the AN and the NAS 🍓.
- Access Node Control Adjacency: the relationship between an Access Node and a NAS, set up for the purpose of exchanging Access Node Control Protocol messages 💜. the adjacency may be either up or down, depending on the result of the Access Node Control Adjacency protocol operation 🔥.
- Multicast Flow: designates datagrams sent to a group from a set of sources for which multicast reception is desired 🌸. a distinction can be made between Any Source Multicast (ASM) and Source-Specific Multicast (SSM) 💅.
- Join: signaling from the user equipment that it wishes to start receiving a new multicast flow 🦋. in ASM it's called a "Join" 🎀. in SSM [RFC4607] it's called a "subscribe" 🌈. in IGMPv2, joins are indicated through an "IGMPv2 membership report" 💖. in IGMPv3 [RFC3376], "join" is indicated through a "membership report" using different Filter-Mode-Change (ASM) and Source-List-Change Records 🧚.
- Leave: signaling from the user equipment that it wishes to stop receiving a multicast flow 🙈. with IGMPv2, this is conveyed inside the "Leave Group" message 🍓. in IGMPv3, "leave" is indicated through the "IGMPv3 membership report" message using different Filter-Mode-Change (ASM) and Source-List-Change Records 💀✨.
2. General Architecture Aspects 🏗️
This section is the big picture 🖼️ it introduces the basic concept of the Access Node Control Mechanism and describes the reference architecture where it gets applied 💅. based on that reference architecture, it then explains how Access Node Control messages are prioritized over other data traffic, plus how ANCP interacts with the network management system 🫶. finally, it describes the addressing schemes that let you identify an Access Port inside Access Node Control messages 🦋.
2.1. Concept of an Access Node Control Mechanism 🧠
The high-level communication framework for an Access Node Control Mechanism is shown in Figure 1 🎀. the Access Node Control Mechanism defines a quasi-real-time, general-purpose method for multiple network scenarios with an extensible communication scheme 👑, covering the different use cases described throughout this document ✨.
+--------+
| Policy |
| Server |
+--------+
|
|
+-----+ +-----+ +--------+ +-----+ +----------+
| CPE |--| HGW |--| | | | | |
+-----+ +-----+ | Access | +-------------+ | | | Regional |
| Node |---| Aggregation |---| NAS |--| Network |
+-----+ +-----+ | | | Network | | | | |
| CPE |--| HGW |--| | +-------------+ | | | |
+-----+ +-----+ +--------+ +-----+ +----------+
Information Report / Admission Request
------------------------------>
Admission Response / Control Request
<------------------------------
Control Response
------------------------------>
Access Node Control Mechanism
<----------------------------->
PPP, DHCP, IP
<---------><----------------------------------------->
CPE: Customer Premises Equipment
HGW: Home Gateway
Figure 1: Access Network Architecturethe messages in Figure 1 show the conceptual message flow 💌. how these flows are actually used, and the times or frequencies when these messages get generated, depends on the actual use cases 🗓️, which are described in Section 3 🌟.
the use cases in this document are described in an abstract way, independent of any actual protocol mapping 🧁. the actual protocol specification is out of scope for this document 🙅♀️, but there are certain characteristics of the protocol that are required to simplify specification, implementation, debugging, and troubleshooting, and to extend support for additional use cases 💖.
A number of functions can be identified 🔍:
- A controller function: this function is used either to send out requests for information to be used by the network element where the controller function resides, or to trigger a certain behavior in the network element where the reporting and/or enforcement function resides 🎯.
- A reporting function: this function is used to convey status information to the controller function 📣. an example is the transmission of the access-loop data rate from an Access Node to a Network Access Server (NAS) tasked with shaping traffic to that rate 📊.
- An enforcement function: this function is contacted by the controller function to trigger a remote action on the Access Node ⚡. an example is initiating a port-testing mechanism on an Access Node 🧪. another example is enforcing whether a multicast join is to be honored or denied 🚦.
2.2. Reference Architecture 🏛️
The reference architecture used in this document can be based on ATM or Ethernet access/aggregation 💜. specifically:
- In case of a legacy ATM aggregation network that is to be used for the introduction of new QoS-enabled IP services, the architecture builds on the reference architecture specified in the Broadband Forum [TR-059] 🕰️;
- In case of an Ethernet aggregation network that supports new QoS-enabled IP services (including Ethernet multicast replication), the architecture builds on the reference architecture specified in the Broadband Forum [TR-101] 🌐.
given the industry's move towards Ethernet as the new access and aggregation technology for triple-play services, the primary focus throughout this document is on a TR-101 architecture 🚀. however, the concepts are equally applicable to an ATM architecture based on TR-059 🤝.
2.2.1. Home Gateway 🏠
The Home Gateway (HGW) connects the different Customer Premises Equipment (CPE) to the Access Node and the access network 🔌. in case of DSL, the HGW is a DSL Network Termination (NT) 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) 🧭.
2.2.2. Access Loop ➰
The access loop ensures physical connectivity between the HGW at the customer premises and the Access Node 💞. in case of DSL, the access-loop physical layer could be, e.g., ADSL, ADSL2+, VDSL, VDSL2, or SHDSL ⚡. to increase bandwidth, it's also possible to group multiple DSL links together to form a single virtual link, a process called "DSL bonding" 🔗✨. the protocol encapsulation on the access loop could be based on multi-protocol encapsulation over ATM Adaption Layer 5 (AAL5) defined in [RFC2684] 📦. this covers PPP over Ethernet (PPPoE, defined in [RFC2516]), bridged IP (IP over Ethernet (IPoE), defined in [RFC894]) and routed IP (IP over ATM (IPoA), defined in [RFC2225]) 🌷. next to this, PPP over AAL5 (PPPoA) as defined in [RFC2364] can be used 🎀. future scenarios include cases where the access loop supports direct Ethernet encapsulation (e.g., when using VDSL or VDSL2) 🔮.
2.2.3. Access Node 🖥️
The Access Node (AN) may support one or more access-loop technologies and allow them to interwork with a common aggregation network technology 🤝. besides the access-loop termination, the AN can also aggregate traffic from other Access Nodes using ATM or Ethernet 🧺.
The framework defined by this document is targeted at DSL-based access (either by means of ATM/DSL or as Ethernet/DSL) 🎯. the framework shall be open to non-DSL technologies, like Passive Optical Networks (PONs) and IEEE 802.16 (WiMAX) 🌊, but the details of this are outside the scope of this document 🙏.
The reporting and/or enforcement function defined in Section 2.1 typically resides in an Access Node 📍.
2.2.4. Access Node Uplink ⬆️
The fundamental requirements for the Access Node uplink are to provide traffic aggregation, Class of Service (CoS) distinction, and customer separation and traceability 💪. this can be achieved using an ATM- or Ethernet-based technology 🌟.
2.2.5. Aggregation Network 🕸️
The aggregation network provides traffic aggregation towards the NAS 🫧. the aggregation technology can be based on ATM (in case of a TR-059 architecture) or Ethernet (in case of a TR-101 architecture) 💜.
2.2.6. Network Access Server 🛰️
The Network Access Server (NAS) interfaces to the aggregation network by means of standard ATM or Ethernet interfaces 🔗, and towards the Regional Network by means of transport interfaces for Ethernet frames (e.g., Gigabit Ethernet (GigE), Ethernet over Synchronous Optical Network (SONET)) 🌈. the NAS functionality corresponds to the BNG functionality described in Broadband Forum TR-101 🎀. in addition to this, the NAS supports the Access Node Control functionality defined for the respective use cases throughout this document 👑.
The controller function defined in Section 2.1 typically resides in a NAS 💅.
2.2.7. Regional Network 🌸
okay so the Regional Network is basically the big hub 🧚 that connects one or more NAS devices (and their Access Networks) up to Network Service Providers (NSPs) and Application Service Providers (ASPs). the NSP is the one that authenticates access, provides and manages the IP addresses for subscribers, and is responsible for overall service assurance. ISPs count as NSPs here 💅. the ASP is the one serving the fun stuff to the application subscriber, like gaming, video, content on demand, IP telephony, and more 🎮
the Regional Network does aggregation of traffic from multiple Access Networks and hands bigger geographic chunks off to NSPs and ASPs. this is the whole point: they don't have to build their own infrastructure to plug into every single Access Network one by one 🫶 that's a major glow-up for them ✨
2.3. Prioritizing Access Node Control Traffic 🚦
okay, this part is all about making sure Access Node Control messages don't get lost while they're traveling across the aggregation network 😭 the way the connection works can be different depending on which layer 2 technology is in use (ATM or Ethernet), so this section gives a quick rundown of how the network connectivity can be set up 💖
for an ATM access/aggregation network, the typical move is to send the Access Node Control Protocol messages over a dedicated Permanent Virtual Circuit (PVC) that's configured between the AN and the NAS. these ATM PVCs then get a high priority, so that when the network is congested, losing the ATM cells that carry the Access Node Control Protocol is avoided or at least minimized 🔥. it's discouraged to route these messages inside the Virtual Path (VP) that also carries the customer connections, if that VP is set up with a best-effort QoS class (e.g., Unspecified Bitrate (UBR)) 🙈 the PVCs of multiple Access Node Control Adjacencies can be bundled into a VP that gets a high priority and runs across the aggregation network. this needs a VC cross-connect in the aggregation node that terminates the VP 🎀
for an Ethernet access/aggregation network, the typical practice is to send the Access Node Control Protocol messages over a dedicated Ethernet Virtual LAN (VLAN) with its own separate VLAN identifier (VLAN ID) 🌈. you can use a different VLAN ID for each Access Node. or, in networks with lots of Access Nodes and a high degree of aggregation, you can use one Customer VLAN (C-VLAN) per Access Node plus one Service VLAN (S-VLAN) for the Access Node Control Adjacencies of all the Access Nodes 🧩. the traffic should be given a high priority (for example, by using a high CoS value) so that the frame loss of the Ethernet frames carrying the Access Node Control Protocol messages is minimized when the network is congested 💜
in both cases, the Control Channel between the NAS and the Access Node could use the same physical network and routing resources as the subscriber traffic 🦋. that makes the connection inband between the network elements involved, so there's no need for an extra physical interface just to set up the Control Channel. main character energy, honestly ✨
just so we're clear, these methods for transporting Access Node Control Protocol messages are typical examples. they don't rule out other methods that achieve the same behavior 🫶
the Access Node Control Adjacency interactions must be reliable 🔒. on top of that, some of the use cases described in Section 3 require the interactions to be performed in a transactional fashion, i.e., using a "request/response" mechanism 💅. this is required so that the network elements always stay in a known state, no matter whether or not the transaction is successful 🌸
2.4. Interaction with Management Systems 🎀
okay, when you introduce an Access Node Control Mechanism, you have to make sure the existing management mechanisms keep working just like before 💖
here's the tricky bit: if you use the Access Node Control Mechanism to perform a configuration action on a network element, you end up with multiple managers for the same device 😬. both the Element Manager and the Access Node Control Mechanism may now do configuration actions on that same network element, so conflicts need to be avoided 💀
using the Access Node Control Mechanism, the NAS retrieves and controls a bunch of subscriber-related parameters 🍓. the NAS might decide to pass this info along to a central Policy or AAA Server so it can keep track of the parameters and apply policies to them, and then the Server can enforce those policies on the NAS 👑. for example, if a subscriber is connected to more than one NAS, the policy server could coordinate the bandwidth available on a given Access Port between the different NAS devices 🧚
guidelines related to management will be addressed in Section 5 🦋
2.5. Circuit Addressing Scheme 🗺️
so, to link subscriber parameters to a particular Access Port, the NAS needs to be able to uniquely identify the Access Port (or a specific circuit on an Access Port) using an addressing scheme ✨
in deployments with an ATM aggregation network, the ATM PVC on an access loop is what connects the subscriber to a NAS. because of that, the NAS typically includes a NAS-Port-Id, NAS-Port, or Calling-Station-Id attribute in the RADIUS authentication and accounting packets it sends to the RADIUS server(s) 💅. that attribute carries the identification of the ATM VC for this subscriber, which in turn lets you identify the access loop 🫶
in an Ethernet-based aggregation network, a new addressing scheme is defined in [TR-101]. there are two mechanisms you can use:
- a first approach is to use a one-to-one VLAN assignment model for all Access Ports (e.g., a DSL port) and circuits on an Access Port (e.g., an ATM PVC on an ADSL port). this lets you directly derive the port and circuit identification from the VLAN tagging information, i.e., the S-VLAN ID or the
<S-VLAN ID, C-VLAN ID>pair 🌈 - a second approach is to use a many-to-one VLAN assignment model and encode the Access Port and circuit identification in the "Agent Circuit ID" sub-option that gets added to a DHCP or PPPoE message 🧩. the details of this approach are specified in [TR-101] 💜
this document reuses the addressing scheme specified in TR-101 🔁. just note that using such a scheme doesn't imply that a PPPoE or DHCP session actually exists, or that the specific interworking function is present in the Access Node 🙈. in some cases, no PPPoE or DHCP session may be present, while port and circuit addressing would still be desirable 🦋
3. Use Cases for Access Node Control Mechanism 🌷
3.1. Access Topology Discovery 🔍
okay, [TR-059] and [TR-101] talk about various queuing/scheduling mechanisms that avoid congestion in the access network while handling multiple flows with distinct QoS requirements 🚦. one technique a NAS can use is called "Hierarchical Scheduling" (HS) 🧁. this is applicable in a single NAS scenario (where the NAS manages all the bandwidth on the access loop) or in a dual NAS scenario (where the NAS manages some fraction of the access loop's bandwidth) 💖. the HS must, at a minimum, support 3 levels modeling the NAS port, Access Node uplink, and access-loop sync rate 🎀. the reasons for supporting HS are as follows:
- provide fairness of network resources within a class 🫶
- allow for a better utilization of network resources. drop traffic early at the NAS rather than letting it traverse the aggregation network just to be dropped at the Access Node 🗑️
- enable more flexible CoS behaviors than only strict priority 💅
- the HS system could be augmented to provide per-application admission control 🌈
- allow fully dynamic bandwidth partitioning between the various applications (as opposed to static bandwidth partitioning) ✨
- support "per-user weighted scheduling" to allow differentiated Service Level Agreements (e.g., business services) within a given traffic class 💼
these mechanisms require the NAS to learn about the topology of the access network, the various links being used, and their respective rates 🧠. some of that info is pretty dynamic (e.g., the DSL line rate, which means the net data rate too), so it can't come from a provisioning and/or inventory management OSS system 😵. other info changes less often (e.g., the capacity of a DSLAM uplink), but it still needs to stay strictly in sync between the actual capacity of the uplink and the image the BRAS has of it 🔒
OSS systems usually aren't designed to enforce the consistency of this kind of data reliably and at scale across organizational boundaries 🙈. the Access Topology Discovery function is there so the NAS can do all this without having to rely on an integration with an OSS system 💖
communicating access-loop attributes is especially important when the rate of the access loop changes over time ⏰. the DSL actual data rate may be different every time the DSL NT is turned on. in that case, the Access Node sends an Information Report message to the NAS after the DSL line has resynchronized 🔁
also, while the DSL NT is active, the data rate can change because of environmental conditions 🌧️. the DSL access loop can get "out of sync" and retrain to a lower value, or it could use Seamless Rate Adaptation, which makes the actual data rate fluctuate while the line is active 🎢. in this case, the Access Node sends an additional Information Report to the NAS each time the access-loop attributes change above a threshold value 📩
the hierarchy and the rates of the various links that enable the NAS hierarchical scheduling and policing mechanisms are as follows 🪜:
- the identification and speed (data rate) of the DSL access loop (i.e., the net data rate) 🧵
- the identification and speed (data rate) of the Remote Terminal (RT) / Access Node uplink (when relevant) 🛰️
the NAS can adjust downstream shaping to the Access Loop's current actual data rate, and more generally reconfigure the appropriate nodes of its hierarchical scheduler (support of advanced capabilities according to TR-101) 🎛️
this use case can actually include more info than just link identification and corresponding data rates 🤯. for DSL access loops, the following access-loop characteristics can be sent to the NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]) 📚:
- DSL Type (e.g., ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2) 🧾
- Framing mode (e.g., ATM, ITU-T Packet Transfer Mode (PTM), IEEE 802.3 Ethernet in the First Mile (EFM)) 🖼️
- DSL port state (e.g., synchronized/showtime, low power, no power/idle) 💤
- Actual net data rate (upstream/downstream) ⚡
- Maximum achievable/attainable net data rate (upstream/downstream) 🚀
- Minimum net data rate configured for the access loop (upstream/downstream) 📉
- Maximum net data rate configured for the access loop (upstream/downstream) 📈
- Minimum net data rate in low power state configured for the access loop (upstream/downstream) 🌙
- Maximum achievable interleaving delay (upstream/downstream) ⏳
- Actual interleaving delay (upstream/downstream) ⌛
the NAS MUST be able to receive access-loop characteristics information, and share such information with AAA/policy servers. this one's non-negotiable, bestie 🚨
3.2. Access-Loop Configuration ✨
okay so access-loop rates are typically configured in a static way 🙄 like, when a subscriber wants to change its access-loop rate, the network operator needs to reconfigure the Access Port configuration, which can mean a business-to-business transaction between an Internet Service Provider (ISP) and an Access Provider 💼. From an Operating Expenditures (OPEX) perspective that is a costly operation 💸 ngl, no thank you.
using the Access Node Control Mechanism to change the access-loop rate from the NAS skips all those cross-organization business-to-business interactions 🙌 and lets you centralize subscriber-related service data in e.g., a policy server 🧚. more generally, several access-loop parameters (e.g., minimum data rate, interleaving delay) could be changed by means of the Access Node Control Mechanism 💜.
triggered by the communication of the access-loop attributes described in Section 3.1, the NAS could query a Policy or AAA Server to retrieve access-loop configuration data 🎀. the best way to change access-loop parameters is by using profiles 👑. these profiles (e.g., DSL profiles for different services) are pre-configured by the Element Manager managing the Access Nodes 🍓. the NAS may then use the Configure Request message to send a reference to the right profile to the Access Node ✨. the NAS may also update the access-loop configuration due to a subscriber service change (e.g., triggered by the policy server) 🦋.
the access-loop configuration mechanism may also be useful for configuration of parameters that are not specific to the access-loop technology 🌈. examples include the QoS profile to be used for an access loop, or the per-subscriber multicast channel entitlement information, used for IPTV applications where the Access Node is performing IGMP snooping or IGMP proxy function 📺. the latter is also discussed in Section 3.4 🫶.
it may be possible that a subscriber wants to change its access-loop rate, and that the operator wants to enforce this updated access-loop rate on the Access Node using ANCP, but that the Access Node Control Adjacency is down 😭. in such a case, the NAS will not be able to request the configuration change on the Access Node. the NAS SHOULD then report this failure to the external management system, which could use application-specific signaling to notify the subscriber of the fact that the change could not be performed at this time 💌.
3.3. Remote Connectivity Test 🔍
traditionally, ATM circuits are point-to-point connections between the BRAS and the DSLAM or DSL NT 🛤️. in order to test the connectivity on layer 2, appropriate Operations, Administration, and Maintenance (OAM) functionality is used for operation and troubleshooting 🔧. an end-to-end OAM loopback is performed between the edge devices (NAS and HGW) of the broadband access network 🔁.
when migrating to an Ethernet-based aggregation network (as defined by TR-101), end-to-end ATM OAM functionality is no longer applicable 🙃. ideally, in an 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, various access technologies exist such as ATM/DSL, Ethernet in the First Mile (EFM), etc. each of these access technologies have their own link-based OAM mechanisms that have been or are being standardized in different standard bodies 🌸.
in a mixed Ethernet and ATM access network (including the local loop), it is desirable to keep the same ways to test and troubleshoot connectivity as those used in an ATM-based architecture 💖. to reach consistency with the ATM-based approach, an Access Node Control Mechanism between NAS and Access Node can be used until end-to-end Ethernet OAM mechanisms are more widely available 🦄.
triggered by a local management interface, the NAS can use the Access Node Control Mechanism to initiate an access-loop test between Access Node and HGW 🎯. in case of an ATM-based access loop, the Access Node Control Mechanism can trigger the Access Node to generate ATM (F4/F5) loopback cells on the access loop 🌊. in case of Ethernet, the Access Node can perform a port synchronization and administrative test for the access loop 🔌. the Access Node can send the result of the test to the NAS via a Control Response message 📬. the NAS may then send the result via a local management interface 💅. thus, the connectivity between the NAS and the HGW can be monitored by a single trigger event 👑.
3.4. Multicast 📺
with the rise of supporting IPTV services in a resource efficient way, multicast services are getting increasingly important 🍿.
in case of an ATM access/aggregation network, such as the reference architecture specified in Broadband Forum [TR-059], multicast traffic replication is performed in the NAS 🧠. in this model, typically IGMP is used to control the multicast replication process towards the subscribers 💜. the NAS terminates and processes IGMP signaling messages sent by the subscribers; towards the Regional Network, the NAS typically uses a multicast routing protocol such as Protocol Independent Multicast (PIM) 🎀. the ATM Access Nodes and aggregation switches don't perform IGMP processing, nor do they perform multicast traffic replication 🙈. as a result, network resources are wasted within the access/aggregation network 😩.
to overcome this resource inefficiency, the Access Node, aggregation node(s), and the NAS MUST all be involved in the multicast replication process 🫶. this prevents several copies of the same stream from being sent within the access/aggregation network 🌟. in case of an Ethernet-based access/aggregation network, this may, for example, be achieved by means of IGMP snooping or IGMP proxy in the Access Node and aggregation node(s) 🧚.
by introducing IGMP processing in the access/aggregation nodes, the multicast replication process is now divided between the NAS, the aggregation node(s), and Access Nodes 🍰. in order to ensure backward compatibility with the ATM-based model, the NAS, aggregation node, and Access Node 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 Access Node and the NAS 🔁.
another option is for the subscriber to communicate the "join/leave" information with the NAS 📨. this can for instance be done by terminating all subscriber IGMP signaling on the NAS 🛑. another example could be a subscriber using some form of application-level signaling, which is redirected to the NAS 🦋. in any case, this option is transparent to the access and aggregation network 🌈. in this scenario, the NAS can use ANCP to create replication state in the AN for efficient multicast replication 💫. the NAS sends a single copy of the multicast stream towards the AN 🩷. the NAS can perform conditional access and multicast admission control on multicast joins, and create replication state in the AN if the flow is admitted by the NAS 🔥.
the following subsections describe the different use cases related to multicast 🧚♀️.
3.4.1. Multicast Conditional Access ✨
okay so picture this, bestie 🎀 in a DSL broadband setup, service providers may want to control access to some multicast flows per user, dynamically, at the network level 👀. That can be used to tell apart multiple Service Offers, or to lock down sensitive content with real conditional access 🔐. ngl, in some environments, application-layer conditional access through Digital Rights Management (DRM) may already give enough control, so Multicast Conditional Access may not be needed 💅.
When Multicast Conditional Access is required, sometimes you can provision the conditional access information into the AN so the AN can make the calls on its own 🧠. In those cases the NAS can use ANCP to load the info into the AN, so the AN can decide locally whether to honor a join or not 🫶. This can be done with the Control Request and Control Response messages.
Provisioning that conditional access info on the AN can be done with a "white list", a "grey list", and/or a "black list" 🌈. A white list tied to an Access Port lists the multicast flows that are allowed to be replicated to that port ✅. A black list tied to an Access Port lists the multicast flows that are not allowed to be replicated to that port 🚫. A grey list tied to an Access Port lists the multicast flows where the AN, upon receiving a join message and before it starts replicating traffic, asks the NAS for further authorization 🤔. Each list can hold zero, one, or multiple entries, and each entry can name a single flow or cover a range (aka a mask on the Group address and/or a mask on the Source address) 🦋.
Here's the flow 💖. When a join message comes in on an Access Port, the Access Node first checks whether the requested multicast flow is in a white, grey, or black list tied to that port. If it's in a white list, the AN autonomously starts replicating the multicast traffic ✨. If it's in a black list, the AN autonomously discards the message because the request isn't authorized, and it may then inform the NAS and log the request 📝. If it's in a grey list, the AN uses ANCP to query the NAS, and the NAS replies to the AN saying whether the join is honored (so the AN does the replication) or denied (so the AN does not replicate) 💜.
If the requested multicast flow shows up in multiple lists tied to the Access Port, then the most specific match is used 🎯. If that most specific match appears in multiple lists, the black list entry takes precedence over the grey list, which takes precedence over the white list 👑.
If the requested multicast flow isn't in any list, the message should be discarded 🙈. This default can be changed with a "catch-all" statement in either the white list or the grey list. For example, adding (<S=,G=>) to the white list makes the default accept join messages for any multicast flow that has no other match on any list 🌸. And if you want the default to be sending a request to the NAS instead, adding (<S=,G=>) to the grey list does that 🧚.
The white list, black list, and grey list can hold entries that allow:
- an exact match for a (*,G) ASM group (e.g.,
<G=g.h.i.l>); - an exact match for a (S,G) 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/Mask,G=g.h.i.l/Mask>).
Here are some example configurations 📋:
Scenario 1: reject all messages
* black list = {<S=*,G=*>}
Scenario 2: reject all messages, except Join (S=*,G=Gi) (1<=i<=n)
* white list = { <S=*,G=G1> , <S=*,G=G2>, ... <S=*,G=Gn>}
* black list = {<S=*,G=*>}
Scenario 3: AN performs autonomous decisions for some channels,
and asks the NAS for other channels
* white list = { <S=*,G=G1> , <S=*,G=G2>, ... <S=*,G=Gn>}
* grey list = { <S=s,G=Gm>} for m>n
* black list = {<S=*,G=*>}
* ==> Join (S=*,G=Gi) gets honored by AN (1<=i<=n)
* ==> Join (S=s,G=Gm) triggers ANCP Admission Request to NAS
* ==> everything else gets rejected by ANThe white list and black list setup is a good fit for regular IPTV services (aka broadcast TV) that an Access Provider offers to broadband (e.g., DSL) subscribers 📺✨. For this, the IPTV subscription is usually bound to one specific DSL line, and the multicast flows in that subscription are known ahead of time 💅. Changes to the conditional access info are rare too, since they're tied to the subscription 🌈. So the Access Node can be provisioned with the conditional access info for the IPTV service, no stress 💖.
Other times, it makes more sense for the conditional access decision to be made by the NAS or a Policy Server 🫶. That's the case when the conditional access info changes a lot, or when the multicast groups aren't known to a client application in advance 😭. The conditional access control could also be wrapped in a more complex policy/authorization mechanism, like time-of-day access, location-based access, or a call out to a remote authorization server 🕰️📍. For these cases, the AN can use ANCP to query the NAS, and the NAS replies to the AN saying whether the join is denied or honored (so the AN does the replication). This can be done with the Admission Request and Admission Response messages.
Some examples of NAS querying are 🫧:
- Roaming users: a subscriber who logs in on different wireless hotspots and would like to receive the multicast content they're entitled to receive 📶;
- Mobility or seamless handover (a related example): in both cases, the burden of (re)configuring access nodes with white lists or black lists may be too high 🙃;
- "Over-the-top video partnerships": service providers may choose to partner with Internet video providers to provide video content. In this case, the multicast group mappings may not be known in advance, or may be reused for different content in succession 🎬;
- "Pay Per View": a subscriber chooses a specific IPTV channel that is made available for a given amount of time 🍿💜.
3.4.2. Multicast Admission Control ✨
okay so triple-play broadband is quickly turning into a huge capacity planning headache for most Service Providers rn 😭 Just adding more bandwidth isn't always practical, cost-effective, and/or enough to keep end users happy 💅. Unicast delay-sensitive apps like VoIP and video have super strict needs, and multicast interactive stuff is growing fast too: videoconferencing, digital TV, digital audio, online movies, and networked gaming 🎮. These apps are typically delay-sensitive, extremely loss-sensitive, and bandwidth-hungry 🔥. They're also "non-elastic," which means they run at a fixed bandwidth that can't be dynamically adjusted to whatever bandwidth is currently available 🫶.
So a Connection Admission Control (CAC) mechanism covering admission of video traffic over the DSL broadband access is required 🎀. The whole point is to avoid oversubscribing the available bandwidth and wrecking the end-user experience 💀.
Now, specifically for admission control over the access line: before honoring a user request to join a new multicast flow, the combination of AN and NAS has to run admission control to validate that there's enough bandwidth left on the access line to carry the new video stream. That's on top of all the other multicast and unicast video streams already sent over the access line 🦋. The solution needs to handle multiple flows per access line and let access-line bandwidth be dynamically shared across multicast and unicast traffic (the unicast CAC is done either by the NAS or by some off-path policy server) 🌸.
So supporting CAC for the access line needs some kind of synchronization between the entity doing multicast CAC (e.g., the NAS or the AN), the entity doing unicast CAC (e.g., the policy server), and the entity actually enforcing the multicast replication (i.e., the AN) 🧚. There are a few ways to make that sync happen:
- One approach is for the AN to query the NAS, so Admission Control for the access line is done by the NAS, or by the policy server which talks to the AN via NAS ✨. The AN can use ANCP to ask the NAS, which then does a multicast Admission Control check for the new multicast flow and replies to the AN saying whether the join is denied or honored (and so whether the AN does the replication) 🔥. The NAS may keep local track of the portion of the access-loop net data rate that's available for (unicast or multicast) video flows and do video bandwidth accounting for the access loop 📊. When the NAS gets an Admission Request from the AN, it can check the available access-loop bandwidth before admitting or denying the multicast flow 💅. While doing that, the NAS may talk to the policy server 🫶. For unicast video services such as Video on Demand (VoD), the NAS may also be queried (by a policy server or via on-path CAC signaling), so it can do admission control for the unicast flow and update the remaining available access-loop bandwidth 🎬. The ANCP requirements to support this approach are specified in this document 📜.
- The model above could be leveled up with the notion of "Delegation of Authorization" 👑. In this model, the NAS or the policy server delegates authority to the Access Node to perform multicast Admission Control on the access loop. This is sometimes called "Bandwidth Delegation," which refers to the portion of the total access-loop bandwidth the Access Node can use for multicast Admission Control 🌈. In this setup, the NAS or the policy server manages the total access-line bandwidth, does unicast admission control, and uses ANCP to authorize the Access Node to do multicast Admission Control within the bounds of the "delegated bandwidth" 🍓. When the AN gets a request for a multicast flow replication that matches an entry in the white or grey list, it does the necessary bandwidth admission control check for the new multicast flow before starting the replication ⭐. At this point there's typically no need for the Access Node to talk to the NAS or the policy server via the NAS 🙈. The ANCP requirements to support this approach are also specified in this document 💜.
- If the subscriber communicates the "join/leave" information with the NAS (e.g., by terminating all subscriber IGMP signaling on the NAS or by using some form of application-level signaling), the approach is very similar 🦋. The NAS may keep local track of the portion of the access-loop bandwidth available for video flows, do CAC for unicast and multicast flows, and handle video bandwidth management 🎀. If the flow is admitted, the NAS can set the replication state on the AN using ANCP ✨. For unicast video services, the NAS may be queried (by a policy server or via on-path CAC signaling) to do admission control for the unicast flow and update the remaining available access-loop bandwidth 💅. The ANCP requirements to support this approach are specified in this document 📜.
- In the last approach, the policy server queries the AN directly or indirectly via the NAS, so both unicast and multicast CAC for the access line are done by the AN 🔥. Here, a subscriber request for a unicast flow (e.g., a Video on Demand session) triggers a resource request message towards a policy server 🎬. The policy server then queries the AN (possibly via the NAS), which does unicast CAC for the access line and responds, saying whether the unicast request is honored or denied 🫶. The model above could also be enhanced with the notion of "Delegation of Authorization" 👑. In this model, the policy server delegates authority to the Access Node to perform multicast Admission Control on the access loop. When the policy server queries the AN directly, the approach doesn't need ANCP, so it's beyond the scope of this document 🙈. When the policy server queries the AN indirectly via the NAS, the approach does need ANCP, so it's in the scope of this document 💜.
3.4.2.1. Delegation of Authority - Bandwidth Delegation
The NAS uses ANCP to indicate to the AN whether or not Admission Control is required for a particular multicast flow on a given Access Port 🧚. If Admission Control is required, the Access Node needs to know whether it's authorized to do Admission Control itself and, if so, within which bounds (i.e., how much bandwidth is "delegated" by the NAS or the policy server) 🌸. Depending on the type of multicast flow, Admission Control may or may not by done by the AN 🫶:
- Multicast flows that need a Conditional Access operation to be performed by the Access Node are put in the black or white list ✨. The Access Node also does Admission Control for those flows in the white list that it's authorized to handle 💅.
- Multicast flows that need a Conditional Access operation to be performed by the NAS or the policy server are put in the grey list 🔥. For flows in the grey list where the Access Node should do Admission Control, the NAS or the policy server will delegate authority to the AN 👑.
Sometimes the bandwidth that the NAS or the policy server first delegated to the AN isn't enough for a new multicast flow request 😭. In that case, the AN can use ANCP to ask the NAS for more delegated multicast bandwidth 🎀. This extends the AN's authorization to do Admission Control 🦋. The NAS or the policy server decides whether the request for more bandwidth can be satisfied and uses ANCP to send a response to the AN with the updated delegated multicast bandwidth 📜. Worth noting: in this case, the time it takes to finish the procedure adds to the zapping delay ⏱️. To keep zapping delay low for future join requests, the AN can put two values in the request message: the minimum amount of additional multicast bandwidth requested and the preferred additional amount 🌈. The first value is the amount that lets the current join request get satisfied, and the second is an amount that anticipates more join requests 🍓.
Sometimes the NAS or the policy server doesn't have enough unicast bandwidth for a new incoming video request 💀. In those cases, the NAS can use ANCP to query (or instruct) the AN to decrease the amount of multicast bandwidth previously delegated on a given Access Port 🙈. This limits or withdraws the AN's authorization to do Admission Control 🧚. The NAS can use ANCP to send a response to the AN with the updated delegated multicast bandwidth 🫶. Using similar reasoning to the previous paragraph, it indicates the minimum amount of multicast bandwidth it needs released, plus a preferred amount, which may be larger 💜.
Note: in order to avoid impacting existing multicast traffic, the NAS must not decrease the amount of delegated multicast bandwidth to a value lower than the bandwidth that is currently in use. This requires the NAS to be aware of this information (e.g., by means of a separate query action). 🚨
Also, in some cases, when the AN gets a leave for a specific multicast flow, it may decide it has an excess of delegated but uncommitted bandwidth 🌸. If so, the AN can use ANCP to send a message to the NAS to release all of part of the unused multicast bandwidth that was previously delegated 🍓. During this process, the Access Node may decide to keep a minimum amount of bandwidth for multicast services 🎀.
3.4.2.2. When Not to Perform Admission Control for a Subset of Flows ✨
Okay so bestie, the Access Node and the NAS literally can't know about every multicast group that's gonna get streamed in the access network 😭. It's super likely there'll be multicast streams coming in from across the Internet, and for those unknown streams, doing bandwidth Admission Control is gonna be kinda chaotic 💀.
So the fix is giving those requests a free pass and skipping Admission Control for them. This only works if the network treats those streams as best effort, so the other streams (the ones that DO get Admission Control) don't get hurt when things get congested 🫶.
Turning off Admission Control for an unknown stream can be done by adding a "catch-all statement" to the Access Node white list or grey list. If the Access Node queries the NAS, the NAS on his turn will have to accept the request. That way, unknown streams aren't blocked by default 🦋.
Next up, to make sure these streams are actually handled as best effort, the flow has to be marked that way when it enters the service provider network. Then, whenever congestion pops up somewhere in the access/aggregation network, this stream gets kicked out first, before the access provider's own premium content 👑.
This concept isn't just for "Internet streams" or other unknown streams. It works for known multicast streams too 💖. In that case, the Access Node or NAS will accept the stream even when bandwidth may not be sufficient to support it. Again, this needs the stream to be marked as best-effort traffic before it enters the access/aggregation network 🌸.
3.4.2.3. Multicast Admission Control and White Lists 🎀
As mentioned in Section 3.4.1, conditional access to popular IPTV channels can be achieved by means of a white and black list configured on the Access Node. This method lets the Access Node autonomously decide whether or not access can be granted to a multicast flow 🧚.
IPTV is an example of a service that won't be offered as best effort, because it needs some level of guaranteed quality of service. So it requires Multicast Admission Control 📺. Hence, if the Access Node wants to autonomously perform the admission process, it must be aware of the bandwidth characteristics of multicast flows. Otherwise, the Access Node would have to query the NAS for Multicast Admission Control (per the grey list behavior), and that would totally defeat the purpose of using a white and black list 😤.
Some network deployments may combine the use of white list, black list, and grey list. The implications of such a model to the overall Multicast Admission Control model aren't fully explored in this document 🤷♀️.
3.4.3. Multicast Accounting and Reporting 💜
It may be desirable to perform time- and/or volume-based accounting for certain multicast flows sent on particular Access Ports. If the AN is doing the traffic replication process, it knows exactly when replication of a multicast flow to a particular Access Port or user starts and stops 🕰️. Multicast accounting can be handled in two ways:
- The AN keeps track of when replication for a given multicast flow starts or ends on a specified Access Port, and generates time- and/or volume-based accounting information per Access Port and per multicast flow, before sending it to a central accounting system for logging. Since the AN talks to the accounting system directly, this approach doesn't require the use of ANCP. It is therefore beyond the scope of this document 🙅♀️.
- The AN keeps track of when replication for a given multicast flow starts or ends on a specified Access Port, and reports this information to the NAS for further processing. In this case, ANCP can be used to send the information from the AN to the NAS. This will be discussed in the remainder of this document 🌈.
The Access Node can send multicast accounting information to the NAS using the Information Report message. There are two cases to know about 📨:
- Basic accounting information: the Access Node informs the NAS whenever replication starts or ends for a given multicast flow on a particular Access Port.
- Detailed accounting information: the Access Node not only informs the NAS when replication starts or ends, but also tells the NAS about the multicast traffic volume replicated on the Access Port for that multicast flow. This is done by adding a byte count in the Information Report message that is sent to the NAS when replication ends 🔢.
Once the NAS gets the Information Report messages, it generates the appropriate time- and/or volume-based accounting records per access loop and per multicast flow, which then get sent to the accounting system 🧾.
The NAS should inform the Access Node about the type of accounting needed for a given multicast flow on a particular Access Port 🗣️:
- No reporting messages need to be sent to the NAS.
- Basic accounting is required.
- Detailed accounting is required.
Heads up: with very fast channel changes, the amount of Information Report messages sent to the NAS could get really high 😬.
The ANCP requirements to support this use case are specified below in this document ✨.
It may also be desirable for the NAS to be able to asynchronously query the AN for an instantaneous status report on the multicast flows currently replicated by the AN. This kind of reporting can be super useful for troubleshooting and monitoring 🔍. The NAS can query the AN to find out the following:
- Which flows are currently being sent on a specific Access Port (i.e., a report for one Access Port)
- On which Access Ports a specified multicast flow is currently being sent (i.e., a report for one multicast flow)
- Which multicast flows are currently being sent on each of the Access Ports (i.e., a global report for one Access Node)
3.4.4. Spontaneous Admission Response 🚨
The ability to dynamically stop the replication of a multicast flow can be really useful in different scenarios. For example, with a prepaid service, when available credit expires, the Service Provider may want to stop multicast replication on a specified Access Port for a particular user 💸. Another example is when a Service Provider wants to show a "Content Preview". In this case, multicast content is delivered for just a fixed amount of time 🎬.
In both cases, an external entity (for example, a policy server or an external application entity) can instruct the NAS to interrupt the multicast replication of a specified multicast flow to a specified Access Port or user. The NAS can then use ANCP to pass this decision along to the Access Node. This can be done with the Admission Response message 💅.
In some deployments, the NAS may find out about end-users' requests to join or leave a multicast flow by means other than ANCP Admission Requests sent by the AN. One possible scenario is when the Access Node doesn't process the IGMP join/leave messages from the end-user (e.g., because they are tunneled), but forwards them to the NAS instead 🚇. In these environments, the NAS can control multicast replication on the AN via ANCP using Spontaneous Admission Responses (i.e., responses sent by the NAS without prior receipt of a corresponding Admission Request) 🦋.
4. Requirements 📋
4.1. ANCP Functional Requirements 💪
R-1 The ANCP MUST be easily extensible through the definition of new message types or TLVs to support use cases beyond those currently addressed in this document. This includes the use of Access Nodes different from a DSLAM, e.g., a PON Access Node 🧩.
R-2 The ANCP MUST be flexible enough to accommodate the various technologies that can be used in an access network and in the Access Node. This includes both ATM and Ethernet 🌐.
R-3 The Access Node Control interactions MUST be reliable. This can be done either by using a reliable transport protocol (e.g., TCP) for the Access Node Control Protocol messages, or by designing ANCP to be reliable 🛡️.
R-4 The ANCP MUST support "request/response" transaction-based interactions for the NAS to communicate control decisions to the Access Node, or for the NAS to request information from the Access Node. Transactions MUST be atomic, i.e., they are either fully completed, or rolled back to the previous state. This is required so that the network elements always remain in a known state, irrespective of whether or not the transaction is successful 🔄.
In case the NAS wants to communicate a bulk of independent control decisions to the Access Node, the transaction (and notion of atomicity) applies to the individual control decisions. This avoids having to roll back all control decisions 🙌. Similarly, if the NAS wants to request a bulk of independent information elements from the Access Node, the notion of transaction applies to the individual information elements 📦.
R-5 The ANCP MUST be scalable enough to allow a given NAS to control at least 5000 Access Nodes 📈.
R-6 The operation of the ANCP in the NAS and Access Nodes MUST be controllable via a management station (e.g., via SNMP). This MUST allow a management station to retrieve statistics and alarms related to the operation of the ANCP, as well as to allow it to initiate OAM operations and retrieve corresponding results 🖥️✨.
4.2. ANCP Multicast Requirements ✨
Okay, multicast time 🦋 The ANCP MUST support giving Access Ports on an Access Node multicast conditional access info, using black, grey, and white lists. R-7
The ANCP MUST support binding a particular black, grey, and white List to a given Access Port. R-8
Upon receiving a join to a multicast flow that matches the grey list, the ANCP MUST allow the AN to query the NAS to request an admission decision for replicating that multicast flow to a particular Access Port. R-9
The ANCP MUST allow the NAS to send an admission decision to the AN indicating whether or not a multicast flow may be replicated to a particular Access Port. R-10
The ANCP MUST allow the NAS to indicate to the AN whether or not Admission Control is needed for some multicast flows on a given Access Port, and (where needed) whether or not the Access Node is authorized to perform Admission Control itself (i.e., whether or not AN Bandwidth Delegation applies). R-11
In case of Admission Control without AN Bandwidth Delegation, the ANCP MUST allow the NAS to reply to a query from the AN indicating whether or not a multicast flow is allowed to be replicated to a particular Access Port. R-12
In case of Admission Control with AN Bandwidth Delegation, the ANCP MUST allow the NAS to delegate a certain amount of bandwidth to the AN for a given Access Port for multicast services only. R-13
In case of Admission Control with AN Bandwidth Delegation, the ANCP MUST allow the AN to query the NAS to request additional multicast bandwidth on a given Access Port. R-14
In case of Admission Control with AN Bandwidth Delegation, the ANCP MUST allow the NAS to query (or to instruct) the AN to reduce the amount of bandwidth previously delegated on a given Access Port. R-15
In case of Admission Control with AN Bandwidth Delegation, the ANCP MUST allow the AN to inform the NAS if it autonomously releases redundant multicast bandwidth on a given Access Port. R-16
The ANCP MUST allow the AN to send an Information Report message to the NAS whenever replication of a multicast flow on a particular Access Port starts or ends. R-17
The ANCP MUST allow the AN to send an Information Report message to the NAS indicating the multicast traffic volume that has been replicated on that port. R-18
The ANCP MUST allow the NAS to indicate to the AN whether or not multicast accounting is needed for a multicast flow on a particular Access Port. R-19
In case multicast accounting is needed for a multicast flow on a particular Access Port, the ANCP MUST allow the NAS to indicate to the AN whether or not additional volume accounting information is required. R-20
The ANCP MUST allow the NAS to revoke a decision to replicate a multicast flow to a particular Access Port, which had been conveyed earlier to an AN. R-21
The ANCP MUST support partial updates of the white, grey, and black lists. R-22
The ANCP MUST allow the NAS to query the AN to obtain information on what multicast flows are currently being replicated on a given Access Port, what Access Ports are currently receiving a given multicast flow, or what multicast flows are currently replicated on each Access Port. R-23
4.3. Protocol Design Requirements 💅
The ANCP SHOULD provide a "shutdown" sequence allowing the protocol to inform the peer that the system is gracefully shutting down. R-24
The ANCP SHOULD include a "report" model for the Access Node to spontaneously communicate to the NAS changes of states. R-25
The ANCP SHOULD support a graceful restart mechanism to enable it to be resilient to network failures between the AN and NAS. R-26
The ANCP MUST provide a means for the AN and the NAS to inform each peer about the supported use cases (either use cases defined in this document or future use cases yet to be defined), and to negotiate a common subset. R-27
4.4. Access Node Control Adjacency Requirements 🫶
The notion of an Access Node Control Adjacency is defined in Section 1.2.
The ANCP MUST support an adjacency protocol in order to automatically synchronize its operational state between its peers, to agree on which version of the protocol to use, to discover the identity of its peers, and to detect when they change. R-28
The ANCP MUST include a mechanism to automatically detect adjacency loss. R-29
A loss of the Access Node Control Adjacency MUST NOT affect subscriber connectivity. R-30
If the Access Node Control Adjacency is lost, it MUST leave the network elements in a known state, irrespective of whether or not the ongoing transaction was successful. R-31
The ANCP MUST support a mechanism to synchronize access port configuration and status information between ANCP peers as part of establishing or recovering the Access Node Control Adjacency. R-32
4.5. ANCP Transport Requirements 🌈
The Access Node Control Mechanism MUST be defined in a way that is independent of the underlying layer 2 transport technology. Specifically, the Access Node Control Mechanism MUST support transmission over an ATM as well as over an Ethernet aggregation network. R-33
The ANCP MUST use the IP protocol stack. R-34
If the layer 2 transport technology is based on ATM, then the ANCP peers must use the encapsulation according to [RFC2684] (IPoA). R-35
If the layer 2 transport technology is based on Ethernet, then the ANCP peers must use the encapsulation according to [RFC894] (IPoE). R-36
4.6. Access Node Requirements 🍓
This section lists the requirements for an AN that supports the use cases defined in this document. Note that this document does not intend to impose absolute requirements on network elements. Therefore, the words "must" and "should" used in this section are not capitalized.
4.6.1. General Architecture 🧚
The Access Node Control Mechanism is defined to operate between an Access Node (AN) and a NAS. In some cases, one AN can be connected to more than one physical NAS device (e.g., in case different wholesale service providers have different NAS devices). In such a model, the physical AN needs to be split in virtual ANs, each having its own Access Node Control reporting and/or enforcement function.
An Access Node as physical device can be split in logical partitions. Each partition may have its independent NAS. Therefore, the Access Node must support at least 2 partitions. The Access Node should support 8 partitions. R-37
One partition is grouped of several Access Ports. Each Access Port on an Access Node must be assigned uniquely to one partition. R-38
It is assumed that all circuits (i.e., ATM PVCs or Ethernet VLANs) on top of the same physical Access Port are associated with the same partition. In other words, partitioning is performed at the level of the physical Access Port only.
Each AN partition must have a separate Access Node Control Adjacency to a NAS. R-39
Each AN partition must be able to enforce access of the controllers to their designated partitions. R-40
The Access Node should be able to establish and maintain ANCP Adjacencies to redundant controllers. R-41
4.6.2. Control Channel Attributes 💖
The Control Channel is a bidirectional IP communication interface between the controller function (in the NAS) and the reporting/enforcement function (in the AN). It is assumed that this interface is configured (rather than discovered) on the AN and the NAS.
Depending on the network topology, the Access Node can be located in a street cabinet or in a central office. If an Access Node in a street cabinet is connected to a NAS, all user traffic and Access Node Control data can use the same physical link.
The Control Channel should use the same facilities as the ones used for the data traffic. Note that this is actually a deployment consideration, which has no impact on the actual protocol design. R-42
The Access Node must process control transactions in real-time (i.e., with a specific response latency). R-43
The Access Node should mark Access Node Control Protocol messages with a high priority (e.g., Variable Bit Rate - Real Time (VBR-RT) for ATM cells, p-bit 6 or 7 for Ethernet packets) in order to avoid or reduce the likelihood of dropping packets in case of network congestion. R-44
If ATM interfaces are used, then any Virtual Path Identifier (VPI) and Virtual Circuit Identifier (VCI) value must be able to be used for the purpose of supporting the Access Node Control Channel. R-45
If Ethernet interfaces are used then any C-VID and S-VID must be able to be used for the purpose of supporting the Access Node Control Channel. R-46
4.6.3. Capability Negotiation Failure 🔥
In case the Access Node and NAS cannot agree on a common set of capabilities, as part of the ANCP capability negotiation procedure, the Access Node must report this to network management. R-47
4.6.4. Adjacency Status Reporting 👑
The Access Node should support generating an alarm to a management station upon loss or malfunctioning of the Access Node Control Adjacency with the NAS. R-48
4.6.5. Identification 🌸
To identify the Access Node and Access Port within a control domain, a unique identifier is required. This identifier must be in line with the addressing scheme principles specified in Section 3.9.3 of TR-101. R-49
In a Broadband Forum TR-101 network architecture, an Access Circuit Identifier (ACI) identifying an AN and Access Port is added to DHCP and PPPoE messages. The NAS must use the same ACI format in ANCP messages in order to allow the NAS to correlate this information with the information present in DHCP and PPPoE messages. R-50
4.6.6. Multicast 🎶
- R-51 The AN must deny any join to a multicast flow matching the black list for the relevant Access Port. 🚫
- R-52 The AN must accept any join to a multicast flow matching the white list and for which no Bandwidth Delegation is used. ✅
- R-53 Upon receiving a join to a multicast flow that matches the white list and for which Bandwidth Delegation is used, the AN must perform the necessary bandwidth admission control check for the new flow before starting the multicast flow replication. This may involve a decision made locally, or querying the NAS or external system such as a policy server, to request additional delegated multicast bandwidth on a given Access Port. 🧮
- R-54 Upon receiving a join to a multicast flow which matches the grey list and for which no Bandwidth Delegation is used, the AN must support using ANCP to query the NAS to receive a response indicating whether that join is to be honored or denied. In this case, the NAS will perform both the necessary conditional access and the admission control checks for the new flow. 🔐
- R-55 Upon receiving a join to a multicast flow that matches the grey list and for which Bandwidth Delegation is used, the AN must first perform the necessary bandwidth admission control check for the new flow. If successful, the AN must support using ANCP to query the NAS to receive a response indicating whether that join is to be honored or denied. 🫣
- R-56 In case of Admission Control with AN Bandwidth Delegation, the AN must support using ANCP to notify the NAS when the user leaves the multicast flow. 👋
- R-57 In case of Admission Control with AN Bandwidth Delegation, the AN must support using ANCP to query the NAS to request additional delegated multicast bandwidth on a given Access Port; the AN should be able to specify both the minimum and the preferred amount of additional multicast bandwidth requested. 🎯
- R-58 In case of Admission Control with AN Bandwidth Delegation, upon receiving a Bandwidth Delegation Request from the NAS querying the AN for the delegated multicast bandwidth on a given Access Port, the AN must support using ANCP to send a Bandwidth Delegation Response, indicating the currently delegated multicast bandwidth. 📬
- R-59 In case of Admission Control with AN Bandwidth Delegation, it may happen that the NAS wants to "revoke" all or part of the delegated bandwidth. Part of the previously delegated bandwidth may however be in use by multicast services. Therefore, upon receiving a Bandwidth Delegation Request from the NAS instructing to decrease the delegated multicast bandwidth on a given Access Port, the AN must support using ANCP to send a Bandwidth Delegation Response, indicating the delegated multicast bandwidth after the decrease (indicating how much of the delegated bandwidth can be returned to the NAS without impacting multicast services that are currently running). 🫠
- R-60 In case of Admission Control with AN Bandwidth Delegation, the AN must support using ANCP to send a Bandwidth Release message to the NAS in order to release unused delegated multicast bandwidth on a given Access Port. 🎁
- R-61 If the requested multicast flow is not part of any list associated with the Access Port, the AN must discard the message. 🗑️
- R-62 If the requested multicast flow is part of multiple lists associated with the Access Port, the AN must use the most specific match. 🔍
- R-63 If the requested multicast flow has the same most specific match in multiple lists, the AN must give precedence to the black list, followed by the grey list, and then the white list. 👑
- R-64 The AN must support configuring a "catch-all" statement in the black, white, or grey list in order to enforce a default behavior for a join to a multicast flow which doesn't match any other entry in a list for the relevant Access Port. 🧺
- R-65 Upon querying the NAS, the AN must not propagate the join message before the successful authorization from the NAS is received. 🙅♀️
- R-66 Upon receiving a leave for a multicast flow that matches the grey list, the AN should be able to autonomously stop replication and advertise this event to the NAS. 🛑
- R-67 The AN must support using ANCP to send an Information Report message to the NAS whenever replication starts or ends. 📣
- R-68 The AN should support using ANCP to send an Information Report message to the NAS indicating the multicast traffic volume that has been replicated on that port. 📊
- R-69 Upon request by the NAS, the AN must support using ANCP to send an Information Report message to the NAS, indicating what multicast flows are currently being replicated on a given Access Port. 💁♀️
- R-70 Upon request by the NAS, the AN must support using ANCP to send an Information Report message to the NAS, indicating what Access Ports are currently receiving a given multicast flow. 🧭
- R-71 Upon request by the NAS, the AN must support using ANCP to send an Information Report message to the NAS, indicating what multicast flows are currently being replicated on each Access Port. 🗂️
- R-72 Upon receiving an Admission Response from the NAS, indicating that replication of a multicast flow is to start or stop on a given access port of the AN, the AN must enforce this decision. This decision must be taken irrespective of whether or not a corresponding Admission Request was issued by the AN earlier. 💅
4.6.7. Message Handling 💌
- R-73 The Access Node must be designed to allow fast completion of ANCP operations, in the order of magnitude of tens of milliseconds. ⚡
- R-74 The Access Node should avoid sending bursts of ANCP messages related to notification of line attributes or line state, by spreading message transmission over time. 🌊
4.6.8. Parameter Control 🎛️
Naturally, the Access Node Control Mechanism is not designed to replace an Element Manager managing the Access Node. There are parameters in the Access Node, such as the DSL noise margin and DSL Power Spectral Density (PSD), which are not allowed to be changed via ANCP or any other control session, but only via the Element Manager. This has to be ensured and protected by the Access Node. 🔒
When using ANCP for access-loop configuration, the EMS needs to configure on the Access Node which parameters may or may not be modified using the Access Node Control Mechanism. Furthermore, for those parameters that may be modified using ANCP, the EMS needs to specify the default values to be used when an Access Node comes up after recovery. 🔄
- R-75 When access-loop configuration via ANCP is required, the EMS must configure on the Access Node which parameter set(s) may be changed/controlled using ANCP. 🧑💻
- R-76 Upon receiving an Access Node Control Request message, the Access Node must not apply changes to the parameter set(s) that have not been enabled by the EMS. 🚧
4.7. Network Access Server Requirements 🖥️
This section lists the requirements for a NAS that supports the use cases defined in this document. Note that this document does not intend to impose absolute requirements on network elements. Therefore, the words "must" and "should" used in this section are not capitalized. 🫶
4.7.1. General Architecture 🎀
R-77 okay so the NAS MUST establish ANCP Adjacencies only with authorized ANCP peers. no strangers in the group chat 🙅♀️
R-78 the NAS MUST support the capability to simultaneously run ANCP with multiple ANs in a network. multitasking queen 👑
R-79 the NAS MUST be able to establish an Access Node Control Adjacency to a particular partition on an AN and control the access loops belonging to that partition ✨
R-80 the NAS MUST support obtaining access-loop information (e.g., net data rate) from its peer Access Node partitions via the Access Node Control Mechanism 📊
R-81 the NAS MUST support shaping traffic aimed at a particular access loop so it does not exceed the net data rate learned from the AN via the Access Node Control Mechanism 🫶
R-82 the NAS SHOULD support reducing or disabling the shaping limit used in the Hierarchical Scheduling process, based on per-subscriber authorization data pulled from a AAA or policy server 🌸
R-83 the NAS MUST support reporting access-loop attributes learned via the Access Node Control Mechanism to a Policy or AAA Server using RADIUS Vendor-Specific Attributes (VSAs) 🦋
R-84 in a TR-059/TR-101 network architecture, the NAS shapes traffic sent to a particular Access Port according to the bitrate available on that port. the NAS SHOULD take into account the layer 1 and layer 2 encapsulation overhead on the Access Port, retrieved from the AN via the Access Node Control Mechanism 💅
R-85 the NAS SHOULD support dynamically configuring and reconfiguring discrete service parameters for access loops that are controlled by the NAS. the configurable service parameters for access loops could be driven by local configuration on the NAS or by a policy server 🧚
R-86 the NAS SHOULD support triggering an AN via the Access Node Control Mechanism to execute local OAM procedures on an access loop that is controlled by the NAS. if the NAS supports this capability, then the following applies: 🔥
- the NAS MUST identify the access loop on which OAM procedures need to be executed by specifying an Access Circuit Identifier (ACI) in the request message to the AN.
- the NAS SHOULD support processing and reporting of the remote OAM results learned via the Access Node Control Mechanism.
- as part of the parameters conveyed within the OAM message to the AN, the NAS SHOULD send the list of test parameters pertinent to the OAM procedure. the AN will then execute the OAM procedure on the specified access loop according to the specified parameters. in case no test parameters are conveyed, the AN and NAS MUST use default and/or appropriately computed values.
- after issuing an OAM request, the NAS will consider the request to have failed if no response is received after a certain period of time. the timeout value SHOULD be either the one sent within the OAM message to the AN, or the computed timeout value when no parameter was sent.
the exact set of test parameters mentioned above depends on the particular OAM procedure executed on the access loop. an example of a set of test parameters is the number of loopbacks to be performed on the access loop and the timeout value for the overall test. in this case, and assuming an ATM-based access loop, the default value for the timeout parameter would be equal to the number of F5 loopbacks to be performed, multiplied by the F5 loopback timeout (i.e., 5 seconds per the ITU-T I.610 standard). 🧪
R-87 the NAS MUST treat PPP or DHCP session state independently from any Access Node Control Adjacency state. the NAS MUST NOT bring down the PPP or DHCP sessions just because the Access Node Control Adjacency goes down. ⚠️
the sessions stay up even when the adjacency drops. that's the whole vibe 💜
R-88 the NAS SHOULD internally treat Access Node Control traffic in a timely and scalable fashion ⭐
R-89 the NAS SHOULD support protection of Access Node Control communication to an Access Node in case of line card failure 🛡️
4.7.2. Control Channel Attributes 🍓
R-90 the NAS MUST mark Access Node Control Protocol messages as high priority (e.g., appropriately set Diffserv Code Point (DSCP), Ethernet priority bits, or ATM Cell Loss Priority (CLP) bit) so that the aggregation network between the NAS and the AN can prioritize these messages over user traffic in case of congestion 🚀
4.7.3. Capability Negotiation Failure 🙈
R-91 in case the NAS and Access Node cannot agree on a common set of capabilities as part of the ANCP capability negotiation procedure, the NAS MUST report this to network management 📣
R-92 the NAS MUST only commence Access Node Control information exchange and state synchronization with the AN when there is a non-empty common set of capabilities with that AN 🤝
4.7.4. Adjacency Status Reporting 🚨
R-93 the NAS MUST support generating an alarm to a management station upon loss or malfunctioning of the Access Node Control Adjacency with the Access Node 🔔
4.7.5. Identification 🪪
R-94 the NAS MUST support correlating Access Node Control Protocol messages pertaining to a given access loop with subscriber session(s) over that access loop. this correlation MUST be achieved by either: 🧩
- matching an Access Circuit Identifier (ACI) inserted by the AN in Access Node Control Protocol messages with the corresponding ACI value received in subscriber signaling (e.g., PPPoE and DHCP) messages as inserted by the AN. the format of ACI is defined in [TR-101]; or
- matching an ACI inserted by the AN in Access Node Control Protocol messages with an ACI value locally configured for a static subscriber on the NAS.
4.7.6. Multicast 🦄
R-95 the NAS MUST support using ANCP to configure multicast conditional access information to Access Ports on an Access Node, using black lists, grey lists, and white lists 🖤
R-96 the NAS MUST support using ANCP to indicate to the AN whether or not Admission Control is needed for some multicast flows on a given Access Port and, where needed, whether or not the Access Node is authorized to perform Admission Control itself (i.e., whether or not AN Bandwidth Delegation applies) 🎯
R-97 upon receiving a query from the AN for a request to replicate a multicast flow to a particular Access Port, and no AN Bandwidth Delegation is used for that flow, the NAS MUST be able to perform the necessary checks (conditional access and/or admission control) for the new flow. the NAS MUST support using ANCP to reply to the AN indicating whether the request is to be honored or denied. this MAY involve a decision made locally or querying an external system such as a policy server 🔍
R-98 upon receiving a query from the AN for a request to replicate a multicast flow to a particular Access Port, and Admission Control with AN Bandwidth Delegation is used for that flow, the NAS MUST be able to perform the conditional access checks (if needed), and MUST support using ANCP to delegate a certain amount of bandwidth to the AN for a given Access Port 🎁
R-99 in case of Admission Control with AN Bandwidth Delegation, upon receiving a Bandwidth Delegation Request from the AN requesting to increase the delegated multicast bandwidth on a given Access Port, the NAS MUST support using ANCP to send a Bandwidth Delegation Response indicating the new delegating multicast bandwidth 📈
R-100 in case of Admission Control with AN Bandwidth Delegation, the NAS MUST support using ANCP to send a request to the AN to decrease the amount of multicast bandwidth previously delegated on a given Access Port; the NAS SHOULD be able to specify both the minimum and the preferred amount of decrement of multicast bandwidth requested 📉
R-101 in case of Admission Control with AN Bandwidth Delegation, upon receiving an ANCP Bandwidth Release message, the NAS MUST be able to update accordingly its view of the multicast bandwidth delegated to the AN 🔄
R-102 the NAS MUST support using ANCP to configure the Access Node with the "maximum number of multicast streams" allowed to be received concurrently per Access Port 🔢
R-103 the NAS MUST support using ANCP to incrementally add, remove, and modify individual entries in white, black, and grey lists ➕
R-104 the NAS MUST support using ANCP to indicate to the AN whether or not multicast accounting is needed for a multicast flow on a particular Access Port 🧾
R-105 in case multicast accounting is needed for a multicast flow on a particular Access Port, the NAS SHOULD support using ANCP to indicate to the AN whether or not additional volume accounting information is required 🧮
R-106 the NAS MUST support using ANCP to query the AN to obtain information on what multicast flows are currently replicated on a given Access Port 👀
R-107 the NAS MUST support using ANCP to query the AN to obtain information on what Access Ports are currently receiving a given multicast flow 👀
R-108 the NAS MUST support using ANCP to query the AN to obtain information on what multicast flows are currently replicated on each Access Port 👀
R-109 when multicast replication occurs on the AN, the NAS MUST support using ANCP to revoke the authorization to replicate a multicast flow to a particular Access Port 🚫
R-110 the NAS SHOULD support using ANCP to indicate to the AN that replication of a multicast flow is to start or stop on a given access port of the AN, without having received a corresponding Admission Request from the AN earlier on 🎬
4.7.7. Message Handling ⏱️
R-111 the NAS MUST be designed to allow fast completion of ANCP operations, in the order of magnitude of tens of milliseconds ⚡
R-112 the NAS SHOULD protect its resources from misbehaving Access Node Control peers by providing a mechanism to dampen information related to an Access Node partition 🧊
4.7.8. Wholesale Model 🧚
Okay so, Broadband Forum TR-058 [TR-058], Broadband Forum TR-059 [TR-059], and Broadband Forum TR-101 [TR-101] describe a DSL broadband access architecture and how it enables wholesaling 🌸. The vibe is that the broadband access provider has a wholesale agreement with one or more service providers. The access provider owns the broadband access network and manages connectivity to those service providers. This is the best part: service providers can offer broadband to retail customers without owning any of the access network infrastructure themselves 💅✨
When you apply the Access Node Control Mechanism to a wholesale network architecture, there are a few extra requirements on top 🎀
- R-113 In case of wholesale access, the network provider's NAS should support reporting of access-loop attributes learned from the AN via the Access Node Control Mechanism (or values derived from such attributes), to a retail provider's network gateway owning the corresponding subscriber(s). 🦋
- R-114 In case of Layer 2 Tunneling Protocol (L2TP) wholesale, the NAS must support a proxy architecture that gives different providers conditional access to dedicated Access Node Control resources on an Access Node. 💖
- R-115 The NAS when acting as an L2TP Access Concentrator (LAC) must communicate generic access-line-related information to the L2TP Network Server (LNS) in a timely fashion. ⭐
- R-116 The NAS when acting as a LAC may asynchronously notify the LNS of updates to generic access-line-related information. 🫶
5. Management-Related Requirements 💅
Okay, management time 🎀 This section lists the management-related requirements for the AN and NAS. Quick heads up though: this document does not mean to slap absolute requirements on network elements. So the words "must" and "should" used in this section are not capitalized, bestie 🙈
- R-117 It must be possible to configure the following parameters on the Access Node and the NAS: 🧚
- Parameters related to the Control Channel transport method: these include the VPI/VCI and transport characteristics (e.g., VBR-RT or Constant Bitrate (CBR)) for ATM networks, or the C-VLAN ID, S-VLAN ID, and p-bit marking for Ethernet networks.
- Parameters related to the Control Channel itself: these include the IP address of the IP interface on the Access Node and the NAS.
- R-118 When the operational status of the Control Channel is changed (
up>down,down>up) a linkdown/linkup trap should be sent towards the EMS. This requirement applies to both the AN and the NAS. 🌈 - R-119 The Access Node must provide the possibility using SNMP to associate individual DSL lines with specific Access Node Control Adjacencies. 🍓
- R-120 The Access Node must notify the EMS of configuration changes made by the NAS on the AN using ANCP, in a timely manner. 👑
- R-121 The Access Node must provide a mechanism that allows the concurrent access on the same resource from several managers (EMS via SNMP, NAS via ANCP). Only one manager may perform a change at a certain time. 😭
- R-122 The ANCP may provide a notification mechanism to inform the NAS about configuration changes done by an EMS, in a timely manner. This applies only to changes of parameters that are part of the use case "Access-Loop Configuration" (Section 3.2). 🦋
6. Security Considerations 🔥
Serious moment, bestie 😤 [RFC5713] lists the ANCP-related security threats that could be encountered on the Access Node and the NAS. It develops a threat model and identifies requirements for ANCP security, aiming to decide which security functions are required at the ANCP level.
Now the spicy part. With multicast handling as described in this document, ANCP protocol activity between the AN and the NAS is triggered by join/leave requests coming from the end-user equipment. This could potentially be used for denial-of-service attacks against the AN and/or the NAS 💀
This is not a new class of risk over already possible IGMP messages sent from subscribers to the NAS when the AN uses no IGMP snooping, and thus is transparent as long as processing of ANCP messages on the NAS/AN is comparably efficient and protected against congestion. Lowkey the same vibe as before, as long as the processing stays efficient and protected from congestion ✨
To mitigate this risk, the AN 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. 🛡️
We also observe that an operator can easily deploy some protection against attacks using invalid multicast flows by taking advantage of the mask-based match in the black list. This way, joins for invalid multicast flows can be denied at the AN level without any ANCP protocol interactions and without NAS involvement. Iconic move 👑
- R-123 The ANCP MUST comply with the security requirements spelled out in RFC 5713. 🔒
- R-124 The Access Node MUST NOT allow the sending of Access Node Control Messages towards the customer premises. 🚫
7. Acknowledgements 🫶
The authors would like to thank everyone that has provided comments or input to this document, so thank you all, you're the real ones 💖 Special shout-out to the contributors to the Broadband Forum activities: Jerome Moisand, Wojciech Dec, Peter Arberg, and Ole Helleberg Andersen. The authors also acknowledge the inputs provided by Roberta Maglione, Angelo Garofalo, Francois Le Faucheur, and Toerless Eckert regarding multicast 🌸 And finally, the authors thank Bharat Joshi, Stefaan De Cnodder, Kirubaharan Dorairaj, Markus Freudenberger, Fortune Huang, and Lothar Reith for providing comments ✨
8. References 📚
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2684] Grossman, D. and J. Heinanen, "Multiprotocol Encapsulation
over ATM Adaptation Layer 5", RFC 2684, September 1999.
[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.
[RFC894] Hornig, C., "A Standard for the Transmission of IP
Datagrams over Ethernet Networks", STD 41, RFC 894,
April 1984.
[TR-101] Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL
Aggregation", Broadband Forum TR-101, May 2006.8.2. Informative References
[G.993.2] ITU-T, "Very high speed digital subscriber line
transceivers 2 (VDSL2)", ITU-T Rec. G.993.2, Feb 2006.
[G.997.1] ITU-T, "Physical layer management for digital subscriber
line (DSL) transceivers", ITU-T Rec. G.997.1, Sep 2005.
[RFC2225] Laubach, M. and J. Halpern, "Classical IP and ARP over
ATM", RFC 2225, April 1998.
[RFC2364] Gross, G., Kaycee, M., Lin, A., Malis, A., and J.
Stephens, "PPP Over AAL5", RFC 2364, July 1998.
[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.
[RFC2881] Mitton, D. and M. Beadles, "Network Access Server
Requirements Next Generation (NASREQNG) NAS Model",
RFC 2881, July 2000.
[RFC3376] Cain, B., Deering, S., Kouvelas, I., Fenner, B., and A.
Thyagarajan, "Internet Group Management Protocol, Version
3", RFC 3376, October 2002.
[RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for
IP", RFC 4607, August 2006.
[TR-058] Elias, M. and S. Ooghe, "Multi-Service Architecture &
Framework Requirements", Broadband Forum TR-058,
September 2003.
[TR-059] Anschutz, T., "DSL Evolution - Architecture Requirements
for the Support of QoS-Enabled IP Services", Broadband
Forum TR-059, September 2003.
[TR-147] Voigt, N., Ooghe, S., and M. Platnic, "Layer 2 Control
Mechanism For Broadband Multi-Service Architectures",
Broadband Forum TR-147, November 2008.Authors' Addresses 🎀
Sven Ooghe
Alcatel-Lucent
Copernicuslaan 50
B-2018 Antwerpen
Belgium
Phone: +32 3 240 42 26
EMail: sven.ooghe@alcatel-lucent.com
Norbert Voigt
Nokia Siemens Networks
Siemensallee 1
17489 Greifswald
Germany
Phone: +49 3834 555 771
EMail: norbert.voigt@nsn.com
Michel Platnic
ECI Telecom
30 Hasivim Street
49517 Petakh Tikva
Israel
Phone: + 972 54 33 81 567
EMail: mplatnic@gmail.com
Thomas Haag
Deutsche Telekom
Heinrich-Hertz-Strasse 3-7
64295 Darmstadt
Germany
Phone: +49 6151 628 2088
EMail: haagt@telekom.de
Sanjay Wadhwa
Juniper Networks
10 Technology Park Drive
Westford, MA 01886
US
Phone:
EMail: swadhwa@juniper.net📦 where this page comes from
- ietf: rfc5851 2010-05
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms