diff options
Diffstat (limited to 'doc/rfc/rfc5851.txt')
| -rw-r--r-- | doc/rfc/rfc5851.txt | 2635 |
1 files changed, 2635 insertions, 0 deletions
diff --git a/doc/rfc/rfc5851.txt b/doc/rfc/rfc5851.txt new file mode 100644 index 0000000..2d04a67 --- /dev/null +++ b/doc/rfc/rfc5851.txt @@ -0,0 +1,2635 @@ + + + + + + +Internet Engineering Task Force (IETF) S. Ooghe +Request for Comments: 5851 Alcatel-Lucent +Category: Informational N. Voigt +ISSN: 2070-1721 Nokia Siemens Networks + M. Platnic + ECI Telecom + T. Haag + Deutsche Telekom + S. Wadhwa + Juniper Networks + May 2010 + + + Framework and Requirements for an Access Node Control Mechanism + in Broadband Multi-Service Networks + +Abstract + + The purpose of this document is to define a framework for an Access + Node Control Mechanism between a Network Access Server (NAS) and an + Access Node (e.g., a Digital Subscriber Line Access Multiplexer + (DSLAM)) in a multi-service reference architecture in order to + perform operations related to service, quality of service, and + subscribers. The Access Node Control Mechanism will ensure that the + transmission of the information does not need to go through distinct + element managers but rather uses a direct device-device + communication. This allows for performing access-link-related + operations within those network elements, while avoiding impact on + the existing Operational Support Systems. + + This document first identifies a number of use cases for which the + Access Node Control Mechanism may be appropriate. It then presents + the requirements for the Access Node Control Protocol (ANCP) that + must be taken into account during protocol design. Finally, it + describes requirements for the network elements that need to support + ANCP and the described use cases. These requirements should be seen + as guidelines rather than as absolute requirements. RFC 2119 + therefore does not apply to the nodal requirements. + + + + + + + + + + + + + +Ooghe, et al. Informational [Page 1] + +RFC 5851 ANCP Framework May 2010 + + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained 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) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + 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 this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such 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, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + +Ooghe, et al. Informational [Page 2] + +RFC 5851 ANCP Framework May 2010 + + +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 + + + +Ooghe, et al. Informational [Page 3] + +RFC 5851 ANCP Framework May 2010 + + + 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 . . . . . . . . . . . . . . . . . . 45 + +1. Introduction + + Digital Subscriber Line (DSL) technology is widely deployed for + Broadband Access for Next Generation Networks. Several documents + like 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. The scope of these + specifications consists of the delivery of voice, video, and data + services. 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 other access technologies, such as Passive + Optical Networks using DSL technology at the Optical Network Unit + (ONU), or wireless technologies like IEEE 802.16. Several use cases + such as Access Topology Discovery, Remote Connectivity Test, and + Multicast may be applied to these access technologies, but the + details of this are outside the scope of this document. + + Traditional architectures require Permanent Virtual Circuit(s) per + subscriber. Such a virtual circuit is configured on layer 2 and + terminated at the first layer 3 device (e.g., Broadband Remote Access + Server (BRAS)). Beside the data plane, the models define the + architectures for element, network, and service management. + Interworking at the management plane is not always possible because + of the organizational boundaries between departments operating the + local loop, departments operating the ATM network, and departments + operating the IP network. Besides, management networks are usually + not designed to transmit management data between the different + entities in real time. + + When deploying value-added services across DSL access networks, + special attention regarding quality of service and service control is + required, which implies a tighter coordination between Network Nodes + (e.g., Access Nodes and Network Access Server (NAS)), without + burdening the Operational Support System (OSS) with unpractical + expectations. + + + + + + +Ooghe, et al. Informational [Page 4] + +RFC 5851 ANCP Framework May 2010 + + + Therefore, there is a need for an Access Node Control Mechanism + between a NAS and an Access Node (e.g., a Digital Subscriber Line + Access Multiplexer (DSLAM)) in a multi-service reference architecture + in order to perform operations related to service, quality of + service, and subscribers. The Access Node Control Mechanism will + ensure that the transmission of the information does not need to go + through distinct element managers but rather using a direct device- + device communication. This allows for performing access-link-related + operations within those network elements, while avoiding impact on + the existing OSSes. + + This document provides a framework for such an Access Node Control + Mechanism and identifies a number of use cases for which this + mechanism can be justified. Next, it presents a number of + requirements for the Access Node Control Protocol (ANCP) and the + network elements that need to support it. + + The requirements spelled out in this document are based on the work + that is performed by the Broadband Forum [TR-147]. + +1.1. Requirements Notation + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +1.2. Definitions + + o Access Node (AN): network device, usually located at a service + provider central office or street cabinet, that terminates access- + loop connections from subscribers. In case the access loop is a + Digital Subscriber Line (DSL), this is often referred to as a DSL + Access Multiplexer (DSLAM). + + o Network Access Server (NAS): network device that aggregates + multiplexed subscriber traffic from a number of Access Nodes. The + NAS plays a central role in per-subscriber policy enforcement and + quality of service (QoS). Often referred to as a Broadband + Network Gateway (BNG) or Broadband Remote Access Server (BRAS). A + detailed definition of the NAS is given in [RFC2881]. + + o "Net Data Rate": defined by ITU-T G.993.2 [G.993.2], section 3.39, + i.e., the portion of the total data rate that can be used to + transmit user information (e.g., ATM cells or Ethernet frames). + It excludes overhead that pertains to the physical transmission + mechanism (e.g., trellis coding in the case of DSL). It includes + + + + + +Ooghe, et al. Informational [Page 5] + +RFC 5851 ANCP Framework May 2010 + + + TPS-TC (Transport Protocol Specific - Transmission Convergence) + encapsulation; this is zero for ATM encapsulation, and non-zero + for 64/65 encapsulation. + + o "Line Rate": defined by ITU-T G.993.2. It contains the complete + overhead including Reed-Solomon and Trellis coding. + + o Access Node Control Mechanism: a method for multiple network + scenarios with an extensible communication scheme that conveys + status and control information between one or more ANs and one or + more NASes without using intermediate element managers. + + o Control Channel: 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. + + o Access Node Control Adjacency: the relationship between an Access + Node and a NAS for the purpose of exchanging Access Node Control + Protocol messages. The adjacency may either be up or down, + depending on the result of the Access Node Control Adjacency + protocol operation. + + o 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). + + o Join: signaling from the user equipment that it wishes to start + receiving a new multicast flow. In ASM, it is referred to as a + "Join". In SSM [RFC4607], it is referred to as a "subscribe". In + IGMPv2, "joins" are indicated through an "IGMPv2 membership + report". In IGMPv3 [RFC3376], "join" is indicated through + "membership report" using different Filter-Mode-Change (ASM) and + Source-List-Change Records. + + o 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, while in IGMPv3, "leave" is indicated + through the "IGMPv3 membership report" message using different + Filter-Mode-Change (ASM) and Source-List-Change Records. + + + + + + + + + +Ooghe, et al. Informational [Page 6] + +RFC 5851 ANCP Framework May 2010 + + +2. General Architecture Aspects + + This section introduces the basic concept of the Access Node Control + Mechanism and describes the reference architecture where it is being + applied. Based on the reference architecture, the section then + describes how Access Node Control messages are to be prioritized over + other data traffic, and the interaction between ANCP and the network + management system. Finally, the addressing schemes are described + that allow identifying an Access Port in 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 defined 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, addressing + the different use cases that are 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 Architecture + + + +Ooghe, et al. Informational [Page 7] + +RFC 5851 ANCP Framework May 2010 + + + A number of functions can be identified: + + o 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. + + o A reporting function: this function is used to convey status + information to the controller function. An example of this 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. + + o An enforcement function: this function is contacted by the + controller function to trigger a remote action on the Access Node. + An example is the initiation of a port-testing mechanism on an + Access Node. Another example is enforcing whether a multicast + join is to be honored or denied. + + The messages shown in Figure 1 show the conceptual message flow. The + actual use of these flows, and the times or frequencies when these + messages are 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 from any actual protocol mapping. The actual protocol + specification is out of scope of 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. + +2.2. Reference Architecture + + The reference architecture used in this document can be based on ATM + or Ethernet access/aggregation. Specifically: + + o 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]; + + o 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]. + + + + + +Ooghe, et al. Informational [Page 8] + +RFC 5851 ANCP Framework May 2010 + + + 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. In order to increase bandwidth, it is also possible that + multiple DSL links are grouped together to form a single virtual + link; this process is 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. + + + + + +Ooghe, et al. Informational [Page 9] + +RFC 5851 ANCP Framework May 2010 + + +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 + + The Regional Network connects one or more NAS and associated Access + Networks to Network Service Providers (NSPs) and Application Service + Providers (ASPs). The NSP authenticates access and provides and + manages the IP address to subscribers. It is responsible for overall + service assurance and includes Internet Service Providers (ISPs). + The ASP provides application services to the application subscriber + (gaming, video, content on demand, IP telephony, etc.). + + The Regional Network supports aggregation of traffic from multiple + Access Networks and hands off larger geographic locations to NSPs and + ASPs -- relieving a potential requirement for them to build + infrastructure to attach more directly to the various Access + Networks. + + + + + + + + + +Ooghe, et al. Informational [Page 10] + +RFC 5851 ANCP Framework May 2010 + + +2.3. Prioritizing Access Node Control Traffic + + When sending Access Node Control messages across the aggregation + network, care is needed that messages won't get lost. The + connectivity between the Access Node and the NAS may differ depending + on the actual layer 2 technology used (ATM or Ethernet). This + section briefly outlines how network connectivity can be established. + + In case of an ATM access/aggregation network, a typical practice is + to send the Access Node Control Protocol messages over a dedicated + Permanent Virtual Circuit (PVC) configured between the AN and the + NAS. These ATM PVCs would then be given a high priority so that at + times of network congestion, loss of the ATM cells carrying the + Access Node Control Protocol is avoided or minimized. It is + discouraged to route the Access Node Control Protocol messages within + the Virtual Path (VP) that also carries the customer connections, if + that VP is configured with a best-effort QoS class (e.g., Unspecified + Bitrate (UBR)). The PVCs of multiple Access Node Control Adjacencies + can be aggregated into a VP that is given a high priority and runs + across the aggregation network. This requires the presence of a VC + cross-connect in the aggregation node that terminates the VP. + + In case of an Ethernet access/aggregation network, a typical practice + is to send the Access Node Control Protocol messages over a dedicated + Ethernet Virtual LAN (VLAN) using a separate VLAN identifier (VLAN + ID). This can be achieved using a different VLAN ID for each Access + Node, or, in networks with many Access Nodes and a high degree of + aggregation, one Customer VLAN (C-VLAN) per Access Node and one + Service VLAN (S-VLAN) for the Access Node Control Adjacencies of all + Access Nodes. The traffic should be given a high priority (e.g., by + using a high CoS value) so that the frame loss of Ethernet frames + carrying the Access Node Control Protocol messages is minimized in + the event of network congestion. + + In both cases, the Control Channel between NAS and Access Node could + use the same physical network and routing resources as the subscriber + traffic. This means that the connection is an inband connection + between the involved network elements. Therefore, there is no need + for an additional physical interface to establish the Control + Channel. + + Note that these methods for transporting Access Node Control Protocol + messages are typical examples; they do not rule out other methods + that achieve the same behavior. + + The Access Node Control Adjacency interactions must be reliable. In + addition to this, some of the use cases described in Section 3 + require the interactions to be performed in a transactional fashion, + + + +Ooghe, et al. Informational [Page 11] + +RFC 5851 ANCP Framework May 2010 + + + i.e., using a "request/response" mechanism. This is required so that + the network elements always remain in a known state, irrespective of + whether or not the transaction is successful. + +2.4. Interaction with Management Systems + + When introducing an Access Node Control Mechanism, care is needed to + ensure that the existing management mechanisms remain operational as + before. + + Specifically, when using the Access Node Control Mechanism for + performing a configuration action on a network element, one gets + confronted with the challenge of supporting multiple managers for the + same network element: both the Element Manager as well as the Access + Node Control Mechanism may now perform configuration actions on the + same network element. Therefore, conflicts need to be avoided. + + Using the Access Node Control Mechanism, the NAS retrieves and + controls a number of subscriber-related parameters. The NAS may + decide to communicate this information to a central Policy or AAA + Server so that it can keep track of the parameters and apply policies + on them. The Server can then enforce those policies on the NAS. For + instance, in case a subscriber is connected to more than one NAS, the + policy server could be used to coordinate the bandwidth available on + a given Access Port for use amongst the different NAS devices. + + Guidelines related to management will be addressed in Section 5. + +2.5. Circuit Addressing Scheme + + In order to associate 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 using an ATM aggregation network, the ATM PVC on an + access loop connects the subscriber to a NAS. Based on this + property, the NAS typically includes a NAS-Port-Id, NAS-Port, or + Calling-Station-Id attribute in RADIUS authentication and accounting + packets sent to the RADIUS server(s). Such attribute includes the + identification of the ATM VC for this subscriber, which allows in + turn identifying the access loop. + + In an Ethernet-based aggregation network, a new addressing scheme is + defined in [TR-101]. Two mechanisms can be used: + + + + + + + +Ooghe, et al. Informational [Page 12] + +RFC 5851 ANCP Framework May 2010 + + + o 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 enables directly + deriving the port and circuit identification from the VLAN tagging + information, i.e., S-VLAN ID or <S-VLAN ID, C-VLAN ID> pair. + + o A second approach is to use a many-to-one VLAN assignment model + and to encode the Access Port and circuit identification in the + "Agent Circuit ID" sub-option to be 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. It + should be noted however that the use of such a scheme does not imply + the actual existence of a PPPoE or DHCP session, nor the presence of + the specific interworking function 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 + + [TR-059] and [TR-101] discuss various queuing/scheduling mechanisms + to avoid congestion in the access network while dealing with multiple + flows with distinct QoS requirements. One technique that can be used + on a NAS is known as "Hierarchical Scheduling" (HS). This option is + applicable in a single NAS scenario (in which case the NAS manages + all the bandwidth available on the access loop) or in a dual NAS + scenario (in which case 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 rationale for the support of HS is as follows: + + o Provide fairness of network resources within a class. + + o 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. + + o Enable more flexible CoS behaviors than only strict priority. + + o The HS system could be augmented to provide per-application + admission control. + + o Allow fully dynamic bandwidth partitioning between the various + applications (as opposed to static bandwidth partitioning). + + + + + +Ooghe, et al. Informational [Page 13] + +RFC 5851 ANCP Framework May 2010 + + + o Support "per-user weighted scheduling" to allow differentiated + Service Level Agreements (e.g., business services) within a given + traffic class. + + Such mechanisms require that the NAS gains knowledge about the + topology of the access network, the various links being used, and + their respective rates. Some of the information required is somewhat + dynamic in nature (e.g., DSL line rate -- thus also the net data + rate); hence, it cannot come from a provisioning and/or inventory + management OSS system. Some of the information varies less + frequently (e.g., capacity of a DSLAM uplink), but nevertheless needs + to be kept strictly in sync between the actual capacity of the uplink + and the image the BRAS has of it. + + OSS systems are typically not designed to enforce the consistency of + such data in a reliable and scalable manner across organizational + boundaries. The Access Topology Discovery function is intended to + allow the NAS to perform these functions without having to rely on an + integration with an OSS system. + + Communicating access-loop attributes is specifically important in + case the rate of the access loop changes overtime. The DSL actual + data rate may be different every time the DSL NT is turned on. In + this case, the Access Node sends an Information Report message to the + NAS after the DSL line has resynchronized. + + Additionally, during the time the DSL NT is active, data rate changes + can occur due to environmental conditions (the DSL access loop can + get "out of sync" and can retrain to a lower value, or the DSL access + loop could use Seamless Rate Adaptation making the actual data rate + fluctuate while the line is active). In this case, 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 to enable the NAS + hierarchical scheduling and policing mechanisms are the following: + + o The identification and speed (data rate) of the DSL access loop + (i.e., the net data rate) + + o 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). + + + + +Ooghe, et al. Informational [Page 14] + +RFC 5851 ANCP Framework May 2010 + + + This use case may actually include more information than link + identification and corresponding data rates. In case of DSL access + loops, the following access-loop characteristics can be sent to the + NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]): + + o DSL Type (e.g., ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2) + + o Framing mode (e.g., ATM, ITU-T Packet Transfer Mode (PTM), IEEE + 802.3 Ethernet in the First Mile (EFM)) + + o DSL port state (e.g., synchronized/showtime, low power, no power/ + idle) + + o Actual net data rate (upstream/downstream) + + o Maximum achievable/attainable net data rate (upstream/downstream) + + o Minimum net data rate configured for the access loop (upstream/ + downstream) + + o Maximum net data rate configured for the access loop (upstream/ + downstream) + + o Minimum net data rate in low power state configured for the access + loop (upstream/downstream) + + o Maximum achievable interleaving delay (upstream/downstream) + + o Actual interleaving delay (upstream/downstream) + + The NAS MUST be able to receive access-loop characteristics + information, and share such information with AAA/policy servers. + +3.2. Access-Loop Configuration + + access-loop rates are typically configured in a static way. When a + subscriber wants to change its access-loop rate, the network operator + needs to reconfigure the Access Port configuration, possibly implying + a business-to-business transaction between an Internet Service + Provider (ISP) and an Access Provider. From an Operating + Expenditures (OPEX) perspective this is a costly operation. + + Using the Access Node Control Mechanism to change the access-loop + rate from the NAS avoids those cross-organization business-to- + business interactions and allows to 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. + + + +Ooghe, et al. Informational [Page 15] + +RFC 5851 ANCP Framework May 2010 + + + 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. + + + + +Ooghe, et al. Informational [Page 16] + +RFC 5851 ANCP Framework May 2010 + + + 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, + + + +Ooghe, et al. Informational [Page 17] + +RFC 5851 ANCP Framework May 2010 + + + 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 + + In a DSL broadband access scenario, service providers may want to + dynamically control, at the network level, access to some multicast + flows on a per-user basis. This may be used in order to + differentiate among multiple Service Offers or to realize/reinforce + conditional access for sensitive content. Note that, in some + environments, application-layer conditional access by means of + Digital Rights Management (DRM) may provide sufficient control, so + that Multicast Conditional Access may not be needed. + + Where Multicast Conditional Access is required, it is possible, in + some cases, to provision the necessary conditional access information + into the AN so the AN can then perform the conditional access + decisions autonomously. For these cases, the NAS can use ANCP to + provision the necessary information in the AN so that the AN can + decide locally to honor a join or to not honor a join. This can be + done with the Control Request and Control Response messages. + + Provisioning the conditional access information on the AN can be done + using a "white list", "grey list", and/or a "black list". A white + list associated with an Access Port identifies the multicast flows + that are allowed to be replicated to that port. A black list + associated with an Access Port identifies the multicast flows that + are not allowed to be replicated to that port. A grey list + associated with an Access Port identifies the multicast flows for + + + +Ooghe, et al. Informational [Page 18] + +RFC 5851 ANCP Framework May 2010 + + + which the AN on receiving a join message, before starting traffic + replication queries the NAS for further authorization. Each list + contains zero, one, or multiple entries, and each entry may specify a + single flow or contain ranges (i.e., mask on Group address and/or + mask on Source address). + + Upon receiving a join message on an Access Port, the Access Node will + first check if the requested multicast flow is part of a white, grey, + or a black list associated with that Access Port. If it is part of a + white list, the AN autonomously starts replicating multicast traffic. + If it is part of a black list, the AN autonomously discards the + message because the request is not authorized, and may thus inform + the NAS and log the request accordingly. If it is part of a grey + list the AN uses ANCP to query the NAS, that in turn will respond to + the AN indicating whether the join is to be honored (and hence + replication performed by the AN) or denied (and hence replication not + performed by the AN). + + If the requested multicast flow is part of multiple lists associated + with the Access Port, then the most specific match will be used. If + the most specific match occurs 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 is not part of any list, the message + should be discarded. This default behavior can easily be changed by + means of a "catch-all" statement in either the white list or the grey + list. For instance, adding (<S=*,G=*>) in the white list would make + the default behavior to accept join messages for a multicast flow + that has no other match on any list. Similarly, if the default + behavior should be to send a request to the NAS, then adding + (<S=*,G=*>) in the grey list accomplishes that. + + The white list, black list, and grey list can contain entries + allowing: + + o an exact match for a (*,G) ASM group (e.g., <G=g.h.i.l>); + + o an exact match for a (S,G) SSM channel (e.g., + <S=s.t.u.v,G=g.h.i.l>); + + o a mask-based range match for a (*,G) ASM group (e.g., <G=g.h.i.l/ + Mask>); + + o a mask-based range match for a (S,G) SSM channel (e.g., + <S=s.t.u.v/Mask,G=g.h.i.l/Mask>); + + + + + +Ooghe, et al. Informational [Page 19] + +RFC 5851 ANCP Framework May 2010 + + + The following are some example configurations: + + o Scenario 1: reject all messages + + * black list = {<S=*,G=*>} + + o 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=*>} + + o 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 AN + + The use of a white list and black list may be applicable, for + instance, to regular IPTV services (i.e., broadcast TV) offered by an + Access Provider to broadband (e.g., DSL) subscribers. For this + application, the IPTV subscription is typically bound to a specific + DSL line, and the multicast flows that are part of the subscription + are well-known beforehand. Furthermore, changes to the conditional + access information are infrequent, since they are bound to the + subscription. Hence, the Access Node can be provisioned with the + conditional access information related to the IPTV service. + + In some other cases, it may be desirable to have the conditional + access decision being taken by the NAS or a Policy Server. This may + be the case when conditional access information changes frequently, + or when the multicast groups are not known to a client application in + advance. The conditional access control could be tied to a more + complex policy/authorization mechanism, e.g., time-of-day access, + location-based access, or to invoke a remote authorization server. + For these cases, the AN can use ANCP to query the NAS that in turn + will respond to the AN indicating whether the join is to be denied or + honored (and hence replication performed by the AN). This can be + done with the Admission Request and Admission Response messages. + + + +Ooghe, et al. Informational [Page 20] + +RFC 5851 ANCP Framework May 2010 + + + Some examples of using NAS querying are the following: + + o Roaming users: a subscriber that logs in on different wireless + hotspots and would like to receive multicast content he is + entitled to receive; + + o 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; + + o "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. + + o "Pay Per View": a subscriber chooses a specific IPTV channel which + is made available for a given amount of time. + +3.4.2. Multicast Admission Control + + The successful delivery of triple-play broadband services is quickly + becoming a big capacity planning challenge for most of the Service + Providers nowadays. Solely increasing available bandwidth is not + always practical, cost-economical, and/or sufficient to satisfy end- + user experience given not only the strict requirements of unicast + delay sensitive applications like VoIP and video, but also the fast + growth of multicast interactive applications such as + videoconferencing, digital TV, digital audio, online movies, and + networked gaming. These applications are typically characterized by + a delay-sensitive nature, an extremely loss-sensitive nature, and + intensive bandwidth requirements. They are also typically "non- + elastic", which means that they operate at a fixed bandwidth that + cannot be dynamically adjusted to the currently available bandwidth. + + Therefore, a Connection Admission Control (CAC) mechanism covering + admission of video traffic over the DSL broadband access is required, + in order to avoid oversubscribing the available bandwidth and + negatively impacting the end-user experience. + + Considering specifically admission control over the access line, + before honoring a user request to join a new multicast flow, the + combination of AN and NAS must ensure admission control is performed + to validate that there is sufficient bandwidth remaining on the + access line to carry the new video stream (in addition to all other + multicast and unicast video streams sent over the access line). The + solution needs to cope with multiple flows per access line and needs + + + + + +Ooghe, et al. Informational [Page 21] + +RFC 5851 ANCP Framework May 2010 + + + to allow access-line bandwidth to be dynamically shared across + multicast and unicast traffic (the unicast CAC is performed either by + the NAS or by some off-path policy server). + + Thus, supporting CAC for the access line requires some form of + synchronization between the entity performing multicast CAC (e.g., + the NAS or the AN), the entity performing unicast CAC (e.g., the + policy server), and the entity actually enforcing the multicast + replication (i.e., the AN). This synchronization can be achieved in + a number of ways: + + o One approach is for the AN to query the NAS so that Admission + Control for the access line is performed by the NAS, or by the + policy server which interacts with the AN via NAS. The AN can use + ANCP to query the NAS that in turn performs a multicast Admission + Control check for the new multicast flow and responds to the AN + indicating whether the join is to be denied or honored (and hence + replication performed by the AN). The NAS may locally keep track + of the portion of the access-loop net data rate that is available + for (unicast or multicast) video flows and perform video bandwidth + accounting for the access loop. Upon receiving an Admission + Request from the AN, the NAS can check available access-loop + bandwidth before admitting or denying the multicast flow. In the + process, the NAS may communicate with 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 that it can perform 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. + + o The above model could be enhanced with the notion of "Delegation + of Authorization". In such a 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 referred + to as "Bandwidth Delegation", referring to the portion of the + total access-loop bandwidth that can be used by the Access Node + for multicast Admission Control. In this model, the NAS or the + policy server manages the total access-line bandwidth, performs + unicast admission control, and uses ANCP to authorize the Access + Node to perform multicast Admission Control within the bounds of + the "delegated bandwidth". Upon receiving a request for a + multicast flow replication that matches an entry in the white or + grey list, the AN performs the necessary bandwidth admission + control check for the new multicast flow, before starting the + multicast flow replication. At this point, there is typically no + + + + + +Ooghe, et al. Informational [Page 22] + +RFC 5851 ANCP Framework May 2010 + + + need for the Access Node to communicate with the NAS or the policy + server via the NAS. The ANCP requirements to support this + approach are also specified in this document. + + o In case 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. In this case, the NAS may locally + keep track of the portion of the access-loop bandwidth that is + available for video flows, perform CAC for unicast and multicast + flows, and perform video bandwidth management. The NAS can set + the replication state on the AN using ANCP if the flow is + admitted. For unicast video services, the NAS may be queried (by + a policy server or via on-path CAC signaling) to perform 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. + + o In the last approach, the policy server queries the AN directly or + indirectly via the NAS, so that both unicast and multicast CAC for + the access line are performed by the AN. In this case, a + subscriber request for a unicast flow (e.g., a Video on Demand + session) will trigger a resource request message towards a policy + server; the latter will then query the AN (possibly via the NAS), + that in turn will perform unicast CAC for the access line and + respond, indicating whether the unicast request is to be honored + or denied. The above model could also be enhanced with the notion + of "Delegation of Authorization". In such a model, the policy + server delegates authority to the Access Node to perform multicast + Admission Control on the access loop. In the case when the policy + server queries the AN directly, the approach doesn't require the + use of ANCP. It is therefore beyond the scope of this document. + In the case when the policy server queries the AN indirectly via + the NAS, the approach requires the use of ANCP and is therefore 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. In case Admission Control is required, the Access Node needs + to know whether or not it is authorized to perform Admission Control + itself and, if so, within which bounds it is authorized to do so + (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: + + + + + +Ooghe, et al. Informational [Page 23] + +RFC 5851 ANCP Framework May 2010 + + + o Multicast flows that require a Conditional Access operation to be + performed by the Access Node are put in the black or white list. + In addition, the Access Node performs Admission Control for those + flows in the white list for which it is authorized to do so. + + o Multicast flows that require a Conditional Access operation to be + performed by the NAS or the policy server, are put in the grey + list. In addition, for those flows in the grey list for which the + Access Node should perform Admission Control, the NAS or the + policy server will delegate authority to the AN. + + In some cases, the bandwidth that the NAS or the policy server + initially delegated to the AN may not be enough to satisfy a + multicast request for a new flow. In this scenario, the AN can use + ANCP to query the NAS in order to request additional delegated + multicast bandwidth. This is a form of extending the AN + authorization to perform Admission Control. The NAS or the policy + server decides if the request for more bandwidth can be satisfied and + uses ANCP to send a response to the AN indicating the updated + delegated multicast bandwidth. It is worth noting that in this case, + the time taken to complete the procedure is an increment to the + zapping delay. In order to minimize the zapping delay for future + join requests, the AN can insert in the request message two values: + the minimum amount of additional multicast bandwidth requested and + the preferred additional amount. The first value is the amount that + allows the present join request to be satisfied, the second value an + amount that anticipates further join requests. + + In some cases, the NAS or the policy server may not have enough + unicast bandwidth to satisfy a new incoming video request: in these + scenarios, the NAS can use ANCP to query (or instruct) the AN in + order to decrease the amount of multicast bandwidth previously + delegated on a given Access Port. This is a form of limiting/ + withdrawing AN authorization to perform Admission Control. The NAS + can use ANCP to send a response to AN indicating the updated + delegated multicast bandwidth. Based on considerations similar to + those of the previous paragraph, it indicates the minimum amount of + multicast bandwidth that it needs released and 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). + + + + + + +Ooghe, et al. Informational [Page 24] + +RFC 5851 ANCP Framework May 2010 + + + In addition, in some cases, upon receiving a leave for a specific + multicast flow, the AN may decide that it has an excess of delegated + but uncommitted bandwidth. In such case, 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. In this process, the Access + Node may decide to retain a minimum amount of bandwidth for multicast + services. + +3.4.2.2. When Not to Perform Admission Control for a Subset of Flows + + In general, the Access Node and NAS may not be aware of all possible + multicast groups that will be streamed in the access network. For + instance, it is likely that there will be multicast streams offered + across the Internet. For these unknown streams, performing bandwidth + Admission Control may be challenging. + + To solve this, these requests could be accepted without performing + Admission Control. This solution works, provided that the network + handles the streams as best effort, so that other streams (that are + subject to Admission Control) are not impacted at times of + congestion. + + Disabling Admission Control for an unknown stream can be achieved by + adding a "catch-all statement" in the Access Node white list or grey + list. In case the Access Node queries the NAS, the NAS on his turn + will have to accept the request. That way, the unknown streams are + not blocked by default. + + Next, in order to ensure that the streams are handled as best effort, + the flow must be marked as such when entering the service provider + network. This way, whenever congestion occurs somewhere in the + access/aggregation network, this stream will be kicked out before the + access provider's own premium content. + + The above concept is applicable beyond the notion of "Internet + streams" or other unknown streams; it can be applied to known + multicast streams as well. In this case, the Access Node or NAS will + accept the stream even when bandwidth may not be sufficient to + support the stream. This again requires that the stream be marked as + best-effort traffic before entering 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 allows the Access Node to + autonomously decide whether or not access can be granted to a + multicast flow. + + + +Ooghe, et al. Informational [Page 25] + +RFC 5851 ANCP Framework May 2010 + + + IPTV is an example of a service that will not be offered as best + effort, but requires some level of guaranteed quality of service. + This requires the use of 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); this would 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 are not 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. In case + the AN is performing the traffic replication process, it knows when + replication of a multicast flow to a particular Access Port or user + start and stops. Multicast accounting can be addressed in two ways: + + o 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. Given that the AN communicates with the accounting + system directly, the approach doesn't require the use of ANCP. It + is therefore beyond the scope of this document; + + o 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. A distinction can be made + between two cases: + + o Basic accounting information: the Access Node informs the NAS + whenever replication starts or ends for a given multicast flow on + a particular Access Port; + + o Detailed accounting information: the Access Node not only informs + the NAS when replication starts or ends, but also informs the NAS + about the multicast traffic volume replicated on the Access Port + + + + +Ooghe, et al. Informational [Page 26] + +RFC 5851 ANCP Framework May 2010 + + + 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. + + Upon receiving the Information Report messages, the NAS generates the + appropriate time- and/or volume-based accounting records per access + loop and per multicast flow to be 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: + + o No reporting messages need to be sent to the NAS. + + o Basic accounting is required. + + o Detailed accounting is required. + + Note that in case of very fast channel changes, the amount of + Information Report messages to be sent to the NAS could become high. + + The ANCP requirements to support this use case are specified below in + this document. + + It may also be desirable for the NAS to have the capability to + asynchronously query the AN to obtain an instantaneous status report + related to multicast flows currently replicated by the AN. Such a + reporting functionality could be useful for troubleshooting and + monitoring purposes. The NAS can query the AN to know the following: + + o Which flows are currently being sent on a specific Access Port + (i.e., a report for one Access Port) + + o On which Access Ports a specified multicast flow is currently + being sent (i.e., a report for one multicast flow) + + o 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 capability to dynamically stop the replication of a multicast + flow can be useful in different scenarios: for example in case of + prepaid service, when available credit expires, the Service Provider + may want to be able to stop multicast replication on a specified + Access Port for a particular user. Another example of applicability + for this functionality is a scenario where a Service Provider would + like to show a "Content Preview": in this case, a multicast content + will be delivered just for a fixed amount of time. + + + +Ooghe, et al. Informational [Page 27] + +RFC 5851 ANCP Framework May 2010 + + + 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 communicate this + decision to the Access Node. This can be done with the Admission + Response message. + + In some deployment scenarios, the NAS may be made aware of end-users' + requests to join/leave a multicast flow by other means than ANCP + Admission Requests sent by the AN. One possible deployment scenario + where this model applies is the case where 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. In such + environments, the NAS can control multicast replication on the AN via + ANCP through the use of Spontaneous Admission Responses (i.e., 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 (using + either 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 + + + +Ooghe, et al. Informational [Page 28] + +RFC 5851 ANCP Framework May 2010 + + + 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 + + R-7 The ANCP MUST support providing multicast conditional access + information to Access Ports on an Access Node, using black, + grey, and white lists. + + R-8 The ANCP MUST support binding a particular black, grey, and + white List to a given Access Port. + + R-9 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-10 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-11 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-12 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-13 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. + + + +Ooghe, et al. Informational [Page 29] + +RFC 5851 ANCP Framework May 2010 + + + R-14 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-15 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-16 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-17 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-18 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-19 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-20 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-21 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-22 The ANCP MUST support partial updates of the white, grey, and + black lists. + + R-23 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. + +4.3. Protocol Design Requirements + + R-24 The ANCP SHOULD provide a "shutdown" sequence allowing the + protocol to inform the peer that the system is gracefully + shutting down. + + + +Ooghe, et al. Informational [Page 30] + +RFC 5851 ANCP Framework May 2010 + + + R-25 The ANCP SHOULD include a "report" model for the Access Node to + spontaneously communicate to the NAS changes of states. + + R-26 The ANCP SHOULD support a graceful restart mechanism to enable + it to be resilient to network failures between the AN and NAS. + + R-27 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. + +4.4. Access Node Control Adjacency Requirements + + The notion of an Access Node Control Adjacency is defined in + Section 1.2. + + R-28 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-29 The ANCP MUST include a mechanism to automatically detect + adjacency loss. + + R-30 A loss of the Access Node Control Adjacency MUST NOT affect + subscriber connectivity. + + R-31 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-32 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. + +4.5. ANCP Transport Requirements + + R-33 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-34 The ANCP MUST use the IP protocol stack. + + + + + +Ooghe, et al. Informational [Page 31] + +RFC 5851 ANCP Framework May 2010 + + + R-35 If the layer 2 transport technology is based on ATM, then the + ANCP peers must use the encapsulation according to [RFC2684] + (IPoA). + + R-36 If the layer 2 transport technology is based on Ethernet, then + the ANCP peers must use the encapsulation according to [RFC894] + (IPoE). + +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. + + R-37 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-38 One partition is grouped of several Access Ports. Each Access + Port on an Access Node must be assigned uniquely to one + partition. + + 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. + + R-39 Each AN partition must have a separate Access Node Control + Adjacency to a NAS. + + R-40 Each AN partition must be able to enforce access of the + controllers to their designated partitions. + + R-41 The Access Node should be able to establish and maintain ANCP + Adjacencies to redundant controllers. + + + + +Ooghe, et al. Informational [Page 32] + +RFC 5851 ANCP Framework May 2010 + + +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. + + R-42 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-43 The Access Node must process control transactions in real-time + (i.e., with a specific response latency). + + R-44 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-45 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-46 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. + +4.6.3. Capability Negotiation Failure + + R-47 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. + +4.6.4. Adjacency Status Reporting + + R-48 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. + + + + +Ooghe, et al. Informational [Page 33] + +RFC 5851 ANCP Framework May 2010 + + +4.6.5. Identification + + R-49 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-50 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. + +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. + + + +Ooghe, et al. Informational [Page 34] + +RFC 5851 ANCP Framework May 2010 + + + 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. + + + + +Ooghe, et al. Informational [Page 35] + +RFC 5851 ANCP Framework May 2010 + + + 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. + + + + + + + +Ooghe, et al. Informational [Page 36] + +RFC 5851 ANCP Framework May 2010 + + +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 The NAS must establish ANCP Adjacencies only with authorized + ANCP peers. + + R-78 The NAS must support the capability to simultaneously run ANCP + with multiple ANs in a network. + + 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 such a 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. + + + + +Ooghe, et al. Informational [Page 37] + +RFC 5851 ANCP Framework May 2010 + + + R-81 The NAS must support shaping traffic directed towards a + particular access loop to 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, according to per- + subscriber authorization data retrieved from a AAA or policy + server. + + R-83 The NAS must support reporting of 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. + + + + + + +Ooghe, et al. Informational [Page 38] + +RFC 5851 ANCP Framework May 2010 + + + * 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. + + 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) + such that the aggregation network between the NAS and the AN + can prioritize the Access Node Control Protocol 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. + + + + + + +Ooghe, et al. Informational [Page 39] + +RFC 5851 ANCP Framework May 2010 + + +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. + + + + + + + +Ooghe, et al. Informational [Page 40] + +RFC 5851 ANCP Framework May 2010 + + + 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. + + + + + + +Ooghe, et al. Informational [Page 41] + +RFC 5851 ANCP Framework May 2010 + + + 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 + + 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. In such a model, 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 the service providers. This + allows service providers to provide broadband services to retail + customers without having to own the access network infrastructure + itself. + + When applying the Access Node Control Mechanism to a wholesale + network architecture, a number of additional requirements apply. + + 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). + + + + + +Ooghe, et al. Informational [Page 42] + +RFC 5851 ANCP Framework May 2010 + + + 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 + + This section lists the management-related requirements for the AN and + NAS. 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. + + 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. + + + +Ooghe, et al. Informational [Page 43] + +RFC 5851 ANCP Framework May 2010 + + + 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 + + [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. + + 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. + + 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. + + 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. In particular, the authors acknowledge + the work done by the contributors to the activities related to the + Broadband Forum: 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 + + + +Ooghe, et al. Informational [Page 44] + +RFC 5851 ANCP Framework May 2010 + + + Toerless Eckert regarding multicast. 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. + + + + +Ooghe, et al. Informational [Page 45] + +RFC 5851 ANCP Framework May 2010 + + + [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 + + + + + + + + + + + + +Ooghe, et al. Informational [Page 46] + +RFC 5851 ANCP Framework May 2010 + + + 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 + + + + + + + + + + + + + + + + + + + + + + + +Ooghe, et al. Informational [Page 47] + |