idnits 2.17.1 draft-ietf-ancp-framework-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1318. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 13, 2007) is 6280 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Ooghe 3 Internet-Draft Alcatel-Lucent 4 Intended status: Standards Track N. Voigt 5 Expires: August 17, 2007 Siemens Networks GmbH & Co. KG 6 M. Platnic 7 ECI Telecom 8 T. Haag 9 T-Systems 10 S. Wadhwa 11 Juniper Networks 12 February 13, 2007 14 Framework and Requirements for an Access Node Control Mechanism in 15 Broadband Multi-Service Networks 16 draft-ietf-ancp-framework-01.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on August 17, 2007. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 47 Abstract 49 The purpose of this document is to define a framework for an Access 50 Node Control Mechanism between a Network Access Server (NAS) and an 51 Access Node (e.g. a Digital Subscriber Line Access Multiplexer 52 (DSLAM)) in a multi-service reference architecture in order to 53 perform QoS-related, service-related and Subscriber-related 54 operations. The Access Node Control Mechanism will ensure that the 55 transmission of the information does not need to go through distinct 56 element managers but rather using a direct device-device 57 communication. This allows for performing access link related 58 operations within those network elements, while avoiding impact on 59 the existing OSS systems. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 5 65 1.2. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. General Architecture Aspects . . . . . . . . . . . . . . . . . 7 67 2.1. Concept of an Access Node Control Mechanism . . . . . . . 7 68 2.2. Reference Architecture . . . . . . . . . . . . . . . . . . 8 69 2.2.1. Home Gateway . . . . . . . . . . . . . . . . . . . . . 9 70 2.2.2. Access Loop . . . . . . . . . . . . . . . . . . . . . 9 71 2.2.3. Access Node . . . . . . . . . . . . . . . . . . . . . 9 72 2.2.4. Access Node Uplink . . . . . . . . . . . . . . . . . . 9 73 2.2.5. Aggregation Network . . . . . . . . . . . . . . . . . 10 74 2.2.6. Network Access Server . . . . . . . . . . . . . . . . 10 75 2.2.7. Regional Network . . . . . . . . . . . . . . . . . . . 10 76 2.3. Access Node Control Mechanism Transport Methods . . . . . 10 77 2.4. Operation and Management . . . . . . . . . . . . . . . . . 11 78 2.4.1. Circuit Addressing Scheme . . . . . . . . . . . . . . 12 79 3. Use Cases for Access Node Control Mechanism . . . . . . . . . 13 80 3.1. Dynamic Access Loop Attributes . . . . . . . . . . . . . . 13 81 3.2. Access Loop Configuration . . . . . . . . . . . . . . . . 15 82 3.3. Remote Connectivity Test . . . . . . . . . . . . . . . . . 16 83 3.4. Multicast . . . . . . . . . . . . . . . . . . . . . . . . 17 84 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 18 85 4.1. ANCP Functional Requirements . . . . . . . . . . . . . . . 18 86 4.2. Protocol Design Requirements . . . . . . . . . . . . . . . 19 87 4.3. Access Node Control Adjacency Requirements . . . . . . . . 19 88 4.4. ANCP Transport Requirements . . . . . . . . . . . . . . . 20 89 4.5. Access Node Requirements . . . . . . . . . . . . . . . . . 20 90 4.5.1. General Architecture . . . . . . . . . . . . . . . . . 20 91 4.5.2. Control Channel Attributes . . . . . . . . . . . . . . 21 92 4.5.3. Capability Negotiation . . . . . . . . . . . . . . . . 22 93 4.5.4. Adjacency . . . . . . . . . . . . . . . . . . . . . . 22 94 4.5.5. Identification . . . . . . . . . . . . . . . . . . . . 22 95 4.5.6. Message Handling . . . . . . . . . . . . . . . . . . . 22 96 4.5.7. Parameter Control . . . . . . . . . . . . . . . . . . 22 97 4.5.8. Security . . . . . . . . . . . . . . . . . . . . . . . 23 98 4.6. Network Access Server Requirements . . . . . . . . . . . . 23 99 4.6.1. General Architecture . . . . . . . . . . . . . . . . . 23 100 4.6.2. Control Channel Attributes . . . . . . . . . . . . . . 25 101 4.6.3. Capability Negotiation . . . . . . . . . . . . . . . . 25 102 4.6.4. Adjacency . . . . . . . . . . . . . . . . . . . . . . 25 103 4.6.5. Identification . . . . . . . . . . . . . . . . . . . . 25 104 4.6.6. Message Handling . . . . . . . . . . . . . . . . . . . 26 105 4.6.7. Wholesale Model . . . . . . . . . . . . . . . . . . . 26 106 4.6.8. Security . . . . . . . . . . . . . . . . . . . . . . . 26 107 5. Policy Server Interaction . . . . . . . . . . . . . . . . . . 27 108 6. Management Related Requirements . . . . . . . . . . . . . . . 28 109 7. Security Considerations . . . . . . . . . . . . . . . . . . . 29 110 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30 111 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 112 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31 113 9.2. Informative References . . . . . . . . . . . . . . . . . . 31 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 32 115 Intellectual Property and Copyright Statements . . . . . . . . . . 34 117 1. Introduction 119 Digital Subscriber Line (DSL) technology is widely deployed for 120 Broadband Access for Next Generation Networks. Several documents 121 like DSL Forum TR-058 [TR-058], DSL Forum TR-059 [TR-059] and DSL 122 Forum TR-101 [TR-101] describe possible architectures for these 123 access networks. The scope of these specifications consists of the 124 delivery of voice, video and data services. The framework defined by 125 this document is targeted at DSL-based access (either by means of 126 ATM/DSL or as Ethernet/DSL). 128 Traditional architectures require Permanent Virtual Circuit(s) per 129 Subscriber. Such virtual circuit is configured on layer 2 and 130 terminated at the first layer 3 device (e.g. Broadband Remote Access 131 Server (BRAS)). Beside the data plane, the models define the 132 architectures for element, network and service management. 133 Interworking at the management plane is not always possible because 134 of the organizational boundaries between departments operating the 135 local loop, departments operating the ATM network and departments 136 operating the IP network. Besides, management networks are usually 137 not designed to transmit management data between the different 138 entities in real time. 140 When deploying value-added services across DSL access networks, 141 special attention regarding quality of service and service control is 142 required, which implies a tighter coordination between Network Nodes 143 (e.g. Access Nodes and NAS), without burdening the OSS layer with 144 unpractical expectations. 146 Therefore, there is a need for an Access Node Control Mechanism 147 between a Network Access Server (NAS) and an Access Node (e.g. a 148 Digital Subscriber Line Access Multiplexer (DSLAM)) in a multi- 149 service reference architecture in order to perform QoS-related, 150 service-related and Subscriber-related operations. The Access Node 151 Control Mechanism will ensure that the transmission of the 152 information does not need to go through distinct element managers but 153 rather using a direct device-device communication. This allows for 154 performing access link related operations within those network 155 elements, while avoiding impact on the existing OSS systems. 157 This document provides a framework for such an Access Node Control 158 Mechanism and identifies a number of use cases for which this 159 mechanism can be justified. Next, it presents a number of 160 requirements for the Access Node Control Protocol (ANCP) and the 161 network elements that need to support it. 163 The requirements spelled out in this document are based on the work 164 that is performed by the DSL Forum ([WT-147]). 166 1.1. Requirements Notation 168 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 169 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 170 document are to be interpreted as described in [RFC2119]. 172 1.2. Definitions 174 o Access Node (AN): Network device, usually located at a service 175 provider central office or street cabinet, that terminates Access 176 Loop connections from Subscribers. In case the Access Loop is a 177 Digital Subscriber Line (DSL), this is often referred to as a DSL 178 Access Multiplexer (DSLAM). 180 o Network Access Server (NAS): Network device which aggregates 181 multiplexed Subscriber traffic from a number of Access Nodes. The 182 NAS plays a central role in per-subscriber policy enforcement and 183 QoS. Often referred to as a Broadband Network Gateway (BNG) or 184 Broadband Remote Access Server (BRAS). A detailed definition of 185 the NAS is given in [RFC2881]. 187 o Net Data Rate: defined by ITU-T G.993.2, section 3.39, i.e. the 188 portion of the total data rate that can be used to transmit user 189 information (e.g. ATM cells or Ethernet frames). It excludes 190 overhead that pertains to the physical transmission mechanism 191 (e.g. trellis coding in case of DSL) 193 o Line Rate: the total data rate including overhead 195 o Access Node Control Mechanism: a method for multiple network 196 scenarios with an extensible communication scheme that conveys 197 status and control information between one or more ANs and one or 198 more NASs without using intermediate element managers. 200 o Control Channel: a bidirectional IP communication interface 201 between the controller function (in the NAS) and the reporting/ 202 enforcement function (in the AN). It is assumed that this 203 interface is configured (rather than discovered) on the AN and the 204 NAS. 206 o Access Node Control adjacency: the relationship between an Access 207 Node and a NAS for the purpose of exchanging Access Node Control 208 Messages. The adjacency may either be up or down, depending on 209 the result of the Access Node Control adjacency protocol 210 operation. 212 o Access Node Control Session: an instantiation of ANCP running on 213 top of the Control Channel. The Access Node Control Session 214 covers all message exchanges that relate to the actual use cases. 216 2. General Architecture Aspects 218 In this section first the concept of the Access Node Control 219 Mechanism is described. Then, the reference architecture is 220 described where the Access Node Control Mechanism is introduced. 222 2.1. Concept of an Access Node Control Mechanism 224 The high-level communication framework for an Access Node Control 225 Mechanism is defined in Figure 1. The Access Node Control Mechanism 226 defines a quasi-realtime, general-purpose method for multiple network 227 scenarios with an extensible communication scheme, addressing the 228 different use cases that are described throughout this document. 230 +--------+ 231 | Policy | 232 | Server | 233 +--------+ 234 | 235 | 236 +-----+ +-----+ +--------+ +-----+ +----------+ 237 | CPE |---| HGW |---| | | | | | 238 +-----+ +-----+ | Access | +---------+ | | | Regional | 239 | Node |---| Aggreg. |---| NAS |---| Network | 240 +-----+ +-----+ | | | Node | | | | | 241 | CPE |---| HGW |---| | +---------+ | | | | 242 +-----+ +-----+ +--------+ +-----+ +----------+ 243 Information Reports 244 --------------------------> 245 Control Requests 246 <-------------------------- 247 Control Responses 248 --------------------------> 250 Access Node Control Mechanism 251 <-------------------------> 252 PPP, DHCP, IP 253 <---------><-------------------------------------> 255 Figure 1 257 From a functional perspective, a number of functions can be 258 identified: 260 o A controller function: this function is used to either send out 261 requests for information to be used by the network element where 262 the controller function resides, or to trigger a certain behavior 263 in the network element where the reporting and/or enforcement 264 function resides; 266 o A reporting and/or enforcement function: the reporting function is 267 used to convey status information to the controller function that 268 requires the information for executing local functions. An 269 example of this is the transmission of an Access Loop data rate 270 from an Access Node to a Network Access Server (NAS) tasked with 271 shaping traffic to that rate. The enforcement function can be 272 contacted by the controller function to trigger a local action. 273 An example of this is the initiation of a port testing mechanism 274 on an Access Node. 276 The messages shown in Figure 1 show the conceptual message flow. The 277 actual use of these flows, and the times or frequencies when these 278 messages are generated depends on the actual use case, which are 279 described in Section 3. 281 The use cases in this document are described in an abstract way, 282 independent from any actual protocol mapping. The actual protocol 283 specification is out of scope of this document, but there are certain 284 characteristics of the protocol required such as to simplify 285 specification, implementation, debugging & troubleshooting, but also 286 to be easily extensible in order to support additional use cases. 288 2.2. Reference Architecture 290 The reference architecture used in this document can be based on ATM 291 or Ethernet access/aggregation. Specifically: 293 o In case of a legacy ATM aggregation network that is to be used for 294 the introduction of new QoS-enabled IP services, the architecture 295 builds on the reference architecture specified in DSL Forum 296 [TR-059]; 298 o In case of an Ethernet aggregation network that supports new QoS- 299 enabled IP services (including Ethernet multicast replication), 300 the architecture builds on the reference architecture specified in 301 DSL Forum [TR-101]. 303 Given the industry's move towards Ethernet as the new access and 304 aggregation technology for triple play services, the primary focus 305 throughout this document is on a TR-101 architecture. However the 306 concepts are equally applicable to an ATM architecture based on TR- 307 059. 309 2.2.1. Home Gateway 311 The Home Gateway (HGW) connects the different Customer Premises 312 Equipment (CPE) to the Access Node and the access network. In case 313 of DSL, the HGW is a DSL Network Termination (NT) that could either 314 operate as a layer 2 bridge or as a layer 3 router. In the latter 315 case, such a device is also referred to as a Routing Gateway (RG). 317 2.2.2. Access Loop 319 The Access Loop ensures physical connectivity between the Network 320 Interface Device (NID) at the customer premises, and the Access Node. 321 Legacy protocol encapsulations use multi-protocol encapsulation over 322 AAL5, defined in RFC2684. This covers PPP over Ethernet (PPPoE, 323 defined in RFC2516), bridged IP (IPoE) and routed IP (IPoA, defined 324 in RFC2225). Next to this, PPPoA as defined in RFC2364 can be used. 325 Future scenarios include cases where the Access Loop supports direct 326 Ethernet encapsulation (e.g. when using VDSL). 328 2.2.3. Access Node 330 The Access Node (AN) is a network device, usually located at a 331 service provider central office or street cabinet, that terminates 332 Access Loop connections from Subscribers. In case the Access Loop is 333 a Digital Subscriber Line (DSL), this is often referred to as a DSL 334 Access Multiplexer (DSLAM). The AN may support one or more Access 335 Loop technologies and allow them to inter-work with a common 336 aggregation network technology. 338 Besides the Access Loop termination the AN can also aggregate traffic 339 from other Access Nodes using ATM or Ethernet. 341 The framework defined by this document is targeted at DSL-based 342 access (either by means of ATM/DSL or as Ethernet/DSL). The 343 framework shall be open to non-DSL technologies, like Passive Optical 344 Networks (PON) and IEEE 802.16 (WiMAX), but the details of this are 345 outside the scope of this document. 347 The reporting and/or enforcement function defined in Section 2.1 348 typically resides in an Access Node. 350 2.2.4. Access Node Uplink 352 The fundamental requirements for the Access Node uplink are to 353 provide traffic aggregation, Class of Service distinction and 354 customer separation and traceability. This can be achieved using an 355 ATM or an Ethernet based technology. 357 2.2.5. Aggregation Network 359 The aggregation network provides traffic aggregation towards the NAS. 360 The aggregation technology can be based on ATM (in case of a TR-059 361 architecture) or Ethernet (in case of a TR-101 architecture). 363 2.2.6. Network Access Server 365 The NAS is a network device which aggregates multiplexed Subscriber 366 traffic from a number of Access Nodes. The NAS plays a central role 367 in per-subscriber policy enforcement and QoS. It is often referred 368 to as a Broadband Network Gateway (BNG) or Broadband Remote Access 369 Server (BRAS). A detailed definition of the NAS is given in RFC2881. 371 The NAS interfaces to the aggregation network by means of standard 372 ATM or Ethernet interfaces, and towards the regional broadband 373 network by means of transport interfaces for Ethernet frames (e.g. 374 GigE, Ethernet over SONET). The NAS functionality correpsonds to the 375 BNG functionality described in DSL Forum TR-101. In addition to 376 this, the NAS supports the Access Node Control functionality defined 377 for the respective use cases throughout this document. 379 The controller function defined in Section 2.1 typically resides in a 380 NAS. 382 2.2.7. Regional Network 384 The Regional Network connects one or more NAS and associated Access 385 Networks to Network Service Providers (NSPs) and Application Service 386 Providers (ASPs). The NSP authenticates access and provides and 387 manages the IP address to Subscribers. It is responsible for overall 388 service assurance and includes Internet Service Providers (ISPs). 389 The ASP provides application services to the application Subscriber 390 (gaming, video, content on demand, IP telephony etc.). 392 The Regional Network supports aggregation of traffic from multiple 393 Access Networks and hands off larger geographic locations to NSPs and 394 ASPs - relieving a potential requirement for them to build 395 infrastructure to attach more directly to the various Access 396 Networks. 398 2.3. Access Node Control Mechanism Transport Methods 400 The connectivity between the Access Node and the NAS may differ 401 depending on the actual layer 2 technology used (ATM or Ethernet). 402 Therefore the identification of unicast & multicast flows/channels 403 will also differ (see also Section 2.4.1). 405 In case of an ATM access/aggregation network, a typical practice is 406 to send the Access Node Control Messages over a dedicated Permanent 407 Virtual Circuit (PVC) configured between the AN and the NAS. These 408 ATM PVCs would then be given a high priority (e.g. by using a 409 Constant Bitrate (CBR) connection) so that the ATM cells carrying the 410 Access Node Control Messages are not lost in the event of congestion. 411 It is discouraged to route the Access Node Control Messages within 412 the VP that also carries the customer connections, if that VP is 413 configured with a best effort QoS class (e.g. Unspecified Bitrate 414 (UBR)). The PVCs of multiple Access Node Control sessions can be 415 routed into a Virtual Path (VP) that is given a high priority and 416 runs across the aggregation network. This requires the presence of a 417 VC cross-connect in the aggregation node that terminates the VP. 419 In case of an Ethernet access/aggregation network, a typical practice 420 is to send the Access Node Control Messages over a dedicated Ethernet 421 Virtual LAN (VLAN) using a separate VLAN identifier (VLAN ID). This 422 can be achieved using a different VLAN ID for each Access Node, or, 423 in networks with many Access Nodes and high degree of aggregation, 424 one Customer VLAN (C-VLAN) per Access Node and one Service VLAN 425 (S-VLAN) for the Access Node Control Sessions of all Access Nodes. 426 These VLANs should be given a high priority (e.g. by using a high 427 Class of Service (CoS) value) so that the Ethernet frames carrying 428 the Access Node Control Messages are not lost in the event of 429 congestion. 431 In both cases, the Control Channel between NAS and Access Node can 432 use the same physical network- and routing resources as the 433 Subscriber traffic. This means that the connection is an inband 434 connection between the involved network elements. Therefore there is 435 no need for an additional physical interface to establish the Control 436 Channel. 438 Note that these methods for transporting Access Node Control Messages 439 are typical examples; they do not rule out other methods that achieve 440 the same behavior. 442 The Access Node Control adjacency interactions must be reliable. In 443 addition to this, some of the use cases described in Section 3 444 require the interactions to be performed in a transactional fashion, 445 i.e. using a "request/response" mechanism. In case the response is 446 negative, the state of the peer must then be rolled back to the state 447 prior to the transaction. 449 2.4. Operation and Management 451 When introducing an Access Node Control Mechanism, care is needed to 452 ensure that the existing management mechanisms remain operational as 453 before. 455 Specifically when using the Access Node Control Mechanism for 456 performing a configuration action on a network element, one gets 457 confronted with the challenge of supporting multiple managers for the 458 same network element: both the Element Manager as well as the Access 459 Node Control Mechanism may now perform configuration actions on the 460 same network element. Conflicts therefore need to be avoided. 462 Also, when using the Access Node Control Mechanism for performing a 463 reporting action, there is a possibility to integrate this with a 464 Subscriber policy system that keeps track of the different Subscriber 465 related parameters. 467 2.4.1. Circuit Addressing Scheme 469 In deployments using an ATM aggregation network, the ATM PVC on an 470 Access Loop connects the Subscriber to a NAS. Based on this 471 property, the NAS typically includes a NAS-Port-Id or a NAS-Port 472 attribute in RADIUS authentication & accounting packets sent to the 473 RADIUS server(s). Such attribute includes the identification of the 474 ATM VC for this Subscriber, which allows in turn identifying the 475 Access Loop. 477 In an Ethernet-based aggregation network, a new addressing scheme is 478 defined in TR-101. Two mechanisms can be used: 480 o A first approach is to use a one-to-one VLAN assignment model for 481 all Access Ports (e.g. a DSL port) and circuits on an Access Port 482 (e.g. an ATM PVC on an ADSL port). This enables directly deriving 483 the port and circuit identification from the VLAN tagging 484 information, i.e. S-VLAN ID or pair; 486 o A second approach is to use a many-to-one VLAN assignment model 487 and to encode the Access Port and circuit identification in the 488 "Agent Circuit ID" sub-option to be added to a DHCP or PPPoE 489 message. The details of this approach are specified in TR-101. 491 This document reuses the addressing scheme specified in TR-101. It 492 should be noted however that the use of such a scheme does not imply 493 the actual existence of a PPPoE or DHCP session, nor on the specific 494 interworking function present in the Access Node. In some cases, no 495 PPPoE or DHCP session may be present, while port and circuit 496 addressing would still be desirable. 498 3. Use Cases for Access Node Control Mechanism 500 3.1. Dynamic Access Loop Attributes 502 [TR-059] and [TR-101] discuss various queuing/scheduling mechanisms 503 to avoid congestion in the access network while dealing with multiple 504 flows with distinct QoS requirements. One technique that can be used 505 on a NAS is known as "Hierarchal Scheduling" (HS). This option is 506 applicable in a single NAS scenario (in which case the NAS manages 507 all the bandwidth available on the Access Loop) or in a dual NAS 508 scenario (in which case the NAS manages some fraction of the Access 509 Loop's bandwidth). The HS must, at a minimum, support 3 levels 510 modelling the NAS port, Access Node uplink, and Access Loop sync 511 rate. The rationale for the support of HS is as follows: 513 o Provide fairness of network resources within a class. 515 o Better utilization of network resources. Drop traffic early at 516 the NAS rather than letting it traverse the aggregation network 517 just to be dropped at the Access Node. 519 o Enable more flexible Class of Service (CoS) behaviors other than 520 only strict priority. 522 o The HS system could be augmented to provide per application 523 admission control. 525 o Allow fully dynamic bandwidth partitioning between the various 526 applications (as opposed to static bandwidth partitioning). 528 o Support "per user weighted scheduling" to allow differentiated 529 SLAs (e.g. business services) within a given traffic class. 531 Such mechanisms require that the NAS gains knowledge about the 532 topology of the access network, the various links being used and 533 their respective rates. Some of the information required is somewhat 534 dynamic in nature (e.g. DSL actual data rate, also known as the "DSL 535 sync rate"), hence cannot come from a provisioning and/or inventory 536 management OSS system. Some of the information varies less 537 frequently (e.g. capacity of a DSLAM uplink), but nevertheless needs 538 to be kept strictly in sync between the actual capacity of the uplink 539 and the image the BRAS has of it. 541 OSS systems are rarely able to enforce in a reliable and scalable 542 manner the consistency of such data, notably across organizational 543 boundaries. The Access Port Discovery function allows the NAS to 544 perform these advanced functions without having to depend on an 545 error-prone & possibly complex integration with an OSS system. 547 Communicating Access Loop attributes is specifically important in 548 case the rate of the Access Loop changes overtime. The DSL actual 549 data rate may be different every time the DSL NT is turned on. In 550 this case, the Access Node sends an Information Report message to the 551 NAS after the DSL sync rate has become stable. 553 Additionally, during the time the DSL NT is active, data rate changes 554 can occur due to environmental conditions (the DSL Access Loop can 555 get "out of sync" and can retrain to a lower value, or the DSL Access 556 Loop could use Seamless Rate Adaptation making the actual data rate 557 fluctuate while the line is active). In this case, the Access Node 558 sends an additional Information Report to the NAS each time the 559 Access Loop attributes change. 561 The hierarchy and the rates of the various links to enable the NAS 562 hierarchical scheduling and policing mechanisms are the following: 564 o The identification and speed (data rate) of the DSL Access Loop 565 (also known as the "DSL sync rate") 567 o The identification and speed (data rate) of the Remote 568 Terminal(RT)/Access Node link (when relevant) 570 The NAS can adjust downstream shaping to current Access Loop actual 571 data rate, and more generally re-configure the appropriate nodes of 572 its hierarchical scheduler (support of advanced capabilities 573 according to TR-101). 575 This use case may actually include more information than link 576 identification and corresponding data rates. In case of DSL Access 577 Loops, the following Access Loop characteristics can be sent to the 578 NAS (cf. ITU-T Recommendation G.997.1 [G.997.1]): 580 o DSL Type (e.g. ADSL1, ADSL2, SDSL, ADSL2+, VDSL, VDSL2) 582 o Framing mode (e.g. ATM, ITU-T Packet Transfer Mode (PTM), IEEE 583 802.3 Ethernet in the First Mile (EFM)) 585 o DSL port state (e.g. synchronized/showtime, low power, no power/ 586 idle) 588 o Actual net data rate (upstream/downstream) 590 o Maximum achievable/attainable data rate (upstream/downstream) 592 o Minimum data rate configured for the Access Loop (upstream/ 593 downstream) 595 o Maximum data rate configured for the Access Loop (upstream/ 596 downstream) 598 o Minimum data rate in low power state configured for the Access 599 Loop (upstream/downstream) 601 o Maximum achievable interleaving delay (upstream/downstream) 603 o Actual interleaving delay (upstream/downstream) 605 The NAS MUST be able to receive Access Loop characteristics 606 information, and share such information with AAA/policy servers. 608 3.2. Access Loop Configuration 610 Access Loop rates are typically configured in a static way. If a 611 Subscriber wants to change its Access Loop rate, this requires an 612 OPEX intensive reconfiguration of the Access Port configuration via 613 the network operator, possibly implying a business-to-business 614 transaction between an Internet Service Provider (ISP) and an Access 615 Provider. 617 Using the Access Node Control Mechanism to change the Access Loop 618 rate from the NAS avoids those cross-organization business-to- 619 business interactions and allows to centralize Subscriber-related 620 service data in e.g. a policy server. More generally, several Access 621 Loop parameters (e.g. minimum data rate, interleaving delay) could be 622 changed by means of the Access Node Control Mechanism. 624 Triggered by the communication of the Access Loop attributes 625 described in Section 3.1, the NAS could query a policy server (e.g. 626 RADIUS server) to retrieve Access Loop configuration data. The best 627 way to change Access Loop parameters is by using profiles. These 628 profiles (e.g. DSL profiles for different services) are pre- 629 configured by the Element Manager managing the Access Nodes. The NAS 630 may then use the Configure Request message to send a reference to the 631 right profile to the Access Node. The NAS may also update the Access 632 Loop configuration due to a Subscriber service change (e.g. triggered 633 by the policy server). 635 The Access Loop Configuration mechanism may also be useful for 636 configuration of parameters that are not specific to the Access Loop 637 technology. Examples include the QoS profile to be used for an 638 Access Loop, or the per-Subscriber multicast channel entitlement 639 information, used for IPTV applications where the Access Node is 640 performing IGMP snooping or IGMP proxy function. The latter is also 641 discussed in Section 3.4. 643 It may be possible that a Subscriber wants to change its Access Loop 644 rate, but that the Access Node Control adjacency is down. In such a 645 case, the NAS will not be able to request the configuration change on 646 the Access Node. The NAS should then report this failure to the OSS 647 system, which could use application specific signaling to notify the 648 Subscriber of the fact that the change could not be performed at this 649 time. 651 3.3. Remote Connectivity Test 653 Traditionally, ATM circuits are point to point connections between 654 the BRAS and the DSLAM or DSL NT. In order to test the connectivity 655 on layer 2, appropriate OAM functionality is used for operation and 656 troubleshooting. An end-to-end OAM loopback is performed between the 657 edge devices (NAS and HGW) of the broadband access network. 659 When migrating to an Ethernet-based aggregation network (as defined 660 by TR-101), end to end ATM OAM functionality is no longer applicable. 661 Ideally in an Ethernet aggregation network, end-to-end Ethernet OAM 662 as specified in IEEE 802.1ag and ITU-T Recommendation Y.1730/1731 can 663 provide Access Loop connectivity testing and fault isolation. 664 However, most HGWs do not yet support these standard Ethernet OAM 665 procedures. Also, various access technologies exist such as ATM/DSL, 666 Ethernet in the First Mile (EFM) etc. Each of these access 667 technologies have their own link-based OAM mechanisms that have been 668 or are being standardized in different standard bodies. 670 In a mixed Ethernet and ATM access network (including the local 671 loop), it is desirable to keep the same ways to test and troubleshoot 672 connectivity as those used in an ATM based architecture. To reach 673 consistency with the ATM based approach, an Access Node Control 674 Mechanism between NAS and Access Node can be used until end-to-end 675 Ethernet OAM mechanisms are more widely available. 677 Triggered by a local management interface, the NAS can use the Access 678 Node Control Mechanism to initiate an Access Loop test between Access 679 Node and HGW. In case of an ATM based Access Loop the Access Node 680 Control Mechanism can trigger the Access Node to generate ATM (F4/F5) 681 loopback cells on the Access Loop. In case of Ethernet, the Access 682 Node can perform a port synchronization and administrative test for 683 the access loop. The Access Node can send the result of the test to 684 the NAS via a Subscriber Response message. The NAS may then send the 685 result via a local management interface. Thus, the connectivity 686 between the NAS and the HGW can be monitored by a single trigger 687 event. 689 3.4. Multicast 691 With the rise of supporting IPTV services in a resource efficient 692 way, multicast services are getting increasingly important. This 693 especially holds for an Ethernet-based access/aggregation 694 architecture. In such a architecture, the Access Node, aggregation 695 node(s) and the NAS are involved in the multicast replication 696 process, thereby avoiding that several copies of the same stream are 697 sent within the network. 699 Typically IGMP is used to control the multicast content replication 700 process within the access/aggregation network. This is achieved by 701 means of IGMP snooping or IGMP proxy in the Access Node, aggregation 702 node(s) and the NAS. However, a Subscriber's policy and 703 configuration for multicast traffic might only be known at the NAS. 704 The Access Node Control Mechanism could be used to exchange the 705 necessary information between the Access Node and the NAS so as to 706 allow the Access Node to perform multicast replication in line with 707 the Subscriber's policy and configuration, and also allow the NAS to 708 follow each Subscriber's multicast group membership. 710 4. Requirements 712 4.1. ANCP Functional Requirements 714 o The ANCP MUST address all use cases described in this document, 715 and be general-purpose and extensible enough to foresee additional 716 use cases (including the use of other Access Nodes than a DSLAM, 717 e.g. a PON Access Node). 719 o The ANCP must be flexible enough to accommodate the various 720 technologies that can be used in an access network and in the 721 Access Node. 723 o The Access Node Control interactions MUST be reliable (using 724 either a reliable transport protocol (e.g. TCP) for the Access 725 Node Control Messages, or by designing ANCP to be reliable). 727 o The ANCP MUST be able to recover from loss of ANCP messages. 729 o The ANCP MUST support "request/response" transaction-based 730 interactions for the NAS to communicate control decisions to the 731 Access Node, or for the NAS to request information from the Access 732 Node. Transactions MUST be atomic, i.e. they are either fully 733 completed, or rolled-back to the previous state. 735 o The ANCP MUST allow fast-paced transactions, in order to provide 736 real time transactions between a NAS an a fully populated Access 737 Node. 739 o The ANCP MUST allow fast completion of a given operation, in the 740 order of magnitude of tens of milliseconds. 742 o In large scale networks, Access Nodes are provisioned but not 743 always fully populated. Therefore the ANCP MUST be scalable 744 enough to allow a given NAS to control thousands of Access Nodes 745 (e.g. typically 5000 to 10000). 747 o The ANCP SHOULD minimize sources of configuration mismatch, help 748 automation of the overall operation of the systems involved 749 (Access Nodes and NAS) and be easy to troubleshoot. 751 o The implementation of the ANCP in the NAS and Access Nodes MUST be 752 manageable via an element management interface. This MUST allow 753 to retrieve statistics and alarms (e.g. via SNMP) about the 754 operation of the ANCP, as well as initiate OAM operations and 755 retrieve corresponding results. 757 o The ANCP SHOULD support a means to handle sending/receiving a 758 large burst of messages efficiently (e.g. using "message 759 bundling"). 761 The ANCP must also support the security requirements as described in 762 Section 7. 764 4.2. Protocol Design Requirements 766 o The ANCP MUST be simple and lightweight enough to allow an 767 implementation on Access Nodes with limited control plane 768 resources (e.g. CPU and memory). 770 o The ANCP SHOULD provide a "shutdown" sequence allowing to inform 771 the peer that the system is gracefully shutting down. 773 o The ANCP SHOULD include a "report" model for the Access Node to 774 spontaneously communicate to the NAS changes of states. 776 o The ANCP SHOULD support a graceful restart mechanism to enable it 777 to be resilient to network failures between the AN and NAS. 779 o The ANCP MUST provide a means for the AN and the NAS to perform 780 capability negotiation and negotiate a common subset. 782 4.3. Access Node Control Adjacency Requirements 784 o The ANCP MUST support an adjacency protocol in order to 785 automatically synchronize states between its peers, to agree on 786 which version of the protocol to use, to discover the identity of 787 its peers, and detect when they change. 789 o The Access Node Control adjacency MUST be designed such that loss 790 or malfunction of the adjacency can be automatically detected by 791 its peers. 793 o The ANCP SHOULD include a "keep-alive" mechanism to automatically 794 detect adjacency loss. 796 o A loss of the Access Node Control adjacency MUST NOT affect 797 Subscriber connectivity, nor network element operation. 799 o If the Access Node Control adjacency is lost, it MUST NOT lead to 800 undefined states on the network elements. 802 o The ANCP MUST be able to recover from loss of the Access Node 803 Control adjacency (e.g. due to link or node failure) and 804 automatically resynchronize state upon re-establishing the Access 805 Node Control adjacency. 807 4.4. ANCP Transport Requirements 809 o The Access Node Control Mechanism MUST be defined in a way that is 810 independent of the underlying layer 2 transport technology. 811 Specifically, the Access Node Control Mechanism MUST support 812 transmission over an ATM as well as over an Ethernet aggregation 813 network. 815 o The ANCP MUST be mapped on top of the IP network layer. 817 o If the layer 2 transport technology is based on ATM, then the 818 encapsulation MUST be according to RFC2684 routed (IPoA). 820 o If the layer 2 transport technology is based on Ethernet, then the 821 encapsulation MUST be according to RFC894 (IPoE). 823 4.5. Access Node Requirements 825 This section lists the requirements for an AN that supports the use 826 cases defined in this document. 828 4.5.1. General Architecture 830 The Access Node Control Mechanism is defined by a dedicated relation 831 between the Access Node (AN) and the NAS. If one service provider 832 has multiple physical NAS devices which represent one logical device 833 (single edge architecture), then one AN can be connected to more than 834 one NAS. Therefore the physical AN needs to be split in virtual ANs 835 each having its own Access Node Control reporting and/or enforcement 836 function. 838 o An Access Node as physical device can be split in logical 839 partitions. Each partition MAY have its independent NAS. 840 Therefore the Access Node MUST support at least 2 partitions. The 841 Access Node SHOULD support 8 partitions. 843 o One partition is grouped of several Access Ports. Each Access 844 Port on an Access Node MUST be assigned uniquely to one partition. 846 It is assumed that all circuits (i.e. ATM PVCs or Ethernet VLANs) on 847 top of the same physical Access Port are associated with the same 848 partition. In other words, partitioning is performed at the level of 849 the physical Access Port only. 851 o Each AN partition MUST have a separate Access Node Control Session 852 to a NAS and SHOULD be able to enforce access control on the 853 controllers to only designated partitions being bound to one 854 controller. 856 o The Access Node SHOULD be able to work with redundant controllers. 858 4.5.2. Control Channel Attributes 860 The Control Channel is a bidirectional IP communication interface 861 between the controller function (in the NAS) and the reporting/ 862 enforcement function (in the AN). It is assumed that this interface 863 is configured (rather than discovered) on the AN and the NAS. 865 Depending on the network topology, the Access Node can be located in 866 a street cabinet or in a central office. If an Access Node in a 867 street cabinet is connected to a NAS, all user traffic and Access 868 Node Control data can use the same physical link. 870 o The Control Channel SHOULD use the same facilities as the ones 871 used for the data traffic. 873 o The Control Channel MUST be terminated at the Access Node. 875 o For security purposes, the Access Node Control Messages sent over 876 the channel MUST NOT be sent towards the customer premises. 878 o The Access Node MUST NOT support the capability to configure 879 sending Access Node Control Messages towards the customer 880 premises. 882 o The Access Node SHOULD process control transactions in a timely 883 fashion. 885 o The Access Node SHOULD mark Access Node Control Messages with a 886 high priority (e.g. VBR-rt or CBR for ATM cells, p-bit 6 or 7 for 887 Ethernet packets) in order for the packets not to be dropped in 888 case of congestion. 890 o If ATM interfaces are used, VPI as well as VCI value MUST be 891 configurable in the full range. 893 o If Ethernet interfaces are used, C-Tag as well as S-Tag MUST be 894 configurable in the full range. 896 4.5.3. Capability Negotiation 898 o In case the Access Node and NAS cannot agree on a common set of 899 capabilities, as part of the ANCP capability negotiation 900 procedure, the Access Node MUST report this to network management. 902 4.5.4. Adjacency 904 o The Access Node SHOULD support generating an alarm to a management 905 station upon loss or malfunctioning of the Access Node Control 906 adjacency with the NAS. 908 4.5.5. Identification 910 o To identify the Access Node and Access Port within a control 911 domain a unique identifier is required. This identifier MUST be 912 in line with the addressing scheme principles specified in section 913 3.9.3 of TR-101. 915 o To allow for correlation in the NAS, the AN MUST use the same ACI 916 format for identifying the AN and Access Port in Access Node 917 Control Messages, PPPoE and DHCP messages. 919 4.5.6. Message Handling 921 o The Access Node SHOULD dampen notifications related to line 922 attributes or line state. 924 4.5.7. Parameter Control 926 Naturally the Access Node Control Mechanism is not designed to 927 replace an Element Manager managing the Access Node. There are 928 parameters in the Access Node, such as the DSL noise margin and DSL 929 Power Spectral Densities (PSD), which are not allowed to be changed 930 via ANCP or any other control session, but only via the Element 931 Manager. This has to be ensured and protected by the Access Node. 933 When using ANCP for Access Loop Configuration, the EMS needs to 934 configure on the Access Node which parameters may or may not be 935 modified using the Access Node Control Mechanism. Furthermore, for 936 those parameters that may be modified using ANCP, the EMS needs to 937 specify the default values to be used when an Access Node comes up 938 after recovery. 940 o When Access Loop Configuration via ANCP is required, the EMS MUST 941 configure on the Access Node which parameter set(s) may be 942 changed/controlled using ANCP. 944 o Upon receiving an Access Node Control Request message, the Access 945 Node MUST NOT apply changes to the parameter set(s) that have not 946 been enabled by the EMS. 948 4.5.8. Security 950 The ANCP related security threats that could be encountered on the 951 Access Node are described in 952 [draft-ietf-ancp-security-threats-00.txt]. This document develops a 953 threat model for ANCP security, aiming to decide which security 954 functions are required at the ANCP level. 956 4.6. Network Access Server Requirements 958 This section lists the requirements for a NAS that supports the use 959 cases defined in this document. 961 4.6.1. General Architecture 963 o The NAS MUST only communicate to authorized Access Node Control 964 peers. 966 o The NAS MUST support the capability to simultaneously run ANCP 967 with multiple ANs in a network. 969 o The NAS MUST be able to establish an Access Node Control Session 970 to a particular partition on an AN and control the access loops 971 belonging to such a partition. 973 o The NAS MUST support learning of access loop attributes (e.g. DSL 974 sync rate), from its peer Access Node partitions via the Access 975 Node Control Mechanism. 977 o The NAS MUST support shaping traffic directed towards a particular 978 access loop to not exceed the DSL sync rate learnt from the AN via 979 the Access Node Control Mechanism. 981 o The NAS SHOULD support a reduction or disabling of such shaping 982 limit, derived from Policy/Radius per-subscriber authorization 983 data. 985 o The NAS MUST support reporting of access loop attributes learned 986 via the Access Node Control Mechanism to a Radius server using 987 RADIUS VSAs. 989 o The NAS MUST correlate Access Node Control information with the 990 RADIUS authorization process and related subscriber data. 992 o The NAS SHOULD support shaping traffic directed towards a 993 particular access loop to include layer-1 and layer-2 994 encapsulation overhead information received for a specific access 995 loop from the AN via the Access Node Control Mechanism. 997 o The NAS SHOULD support dynamically configuring and re-configuring 998 discrete service parameters for access loops that are controlled 999 by the NAS. The configurable service parameters for access loops 1000 could be driven by local configuration on the NAS or by a radius/ 1001 policy server. 1003 o The NAS SHOULD support triggering an AN via the Access Node 1004 Control Mechanism to execute local OAM procedures on an access 1005 loop that is controlled by the NAS. If the NAS supports this 1006 capability, then the following applies: 1008 * The NAS MUST identify the access loop on which OAM procedures 1009 need to be executed by specifying an ACI in the request message 1010 to the AN; 1012 * The NAS SHOULD support processing and reporting of the remote 1013 OAM results learned via the Access Node Control Mechanism. 1015 * As part of the parameters conveyed within the OAM message to 1016 the AN, the NAS SHOULD send the list of test parameters 1017 pertinent to the OAM procedure. The AN will then execute the 1018 OAM procedure on the specified access loop according to the 1019 specified parameters. In case no test parameters are conveyed, 1020 the AN and NAS MUST use default and/or appropriately computed 1021 values. 1023 * After issuing an OAM request, the NAS will consider the request 1024 to have failed if no response is received after a certain 1025 period of time. The timeout value SHOULD be either the one 1026 sent within the OAM message to the AN, or the computed timeout 1027 value when no parameter was sent. 1029 The exact set of test parameters mentioned above depends on the 1030 particular OAM procedure executed on the access loop. An example 1031 of a set of test parameters is the number of loopbacks to be 1032 performed on the access loop and the timeout value for the overall 1033 test. In this case, and assuming an ATM based access loop, the 1034 default value for the timeout parameter would be equal to the 1035 number of F5 loopbacks to be performed, multiplied by the F5 1036 loopback timeout (i.e. 5 seconds per the ITU-T I.610 standard). 1038 o The NAS MUST treat PPP or DHCP session state independently from 1039 any Access Node Control adjacency state. The NAS MUST NOT bring 1040 down the PPP or DHCP sessions just because the Access Node Control 1041 adjacency goes down. 1043 o The NAS SHOULD internally treat Access Node Control traffic in a 1044 timely and scalable fashion. 1046 o The NAS SHOULD support protection of Access Node Control 1047 communication to an Access Node in case of line card failure. 1049 4.6.2. Control Channel Attributes 1051 o The NAS MUST mark Access Node Control Messages as high priority 1052 (e.g. appropriately set DSCP, Ethernet priority bits or ATM CLP 1053 bit) such that the aggregation network between the NAS and the AN 1054 can prioritize the Access Node Control Messages over user traffic 1055 in case of congestion. 1057 4.6.3. Capability Negotiation 1059 o In case the NAS and Access Node cannot agree on a common set of 1060 capabilities, as part of the ANCP capability negotiation 1061 procedure, the NAS MUST report this to network management. 1063 o The NAS MUST only commence Access Node Control information 1064 exchange and state synchronization with the AN when there is a 1065 non-empty common set of capabilities with that AN. 1067 4.6.4. Adjacency 1069 o The NAS MUST support generating an alarm to a management station 1070 upon loss or malfunctioning of the Access Node Control adjacency 1071 with the Access Node. 1073 4.6.5. Identification 1075 o The NAS MUST support correlating Access Node Control Messages 1076 pertaining to a given access loop with subscriber session(s) over 1077 that access loop. This correlation MUST be achieved by either: 1079 * Matching an ACI inserted by the AN in Access Node Control 1080 Messages with corresponding ACI value received in subscriber 1081 signaling (e.g. PPPoE and DHCP) messages as inserted by the 1082 AN. The format of ACI is defined in [TR-101]; 1084 * Matching an ACI inserted by the AN in Access Node Control 1085 Messages with an ACI value locally configured for a static 1086 subscriber on the NAS. 1088 4.6.6. Message Handling 1090 o The NAS SHOULD protect its resources from misbehaved Access Node 1091 Control peers by providing a mechanism to dampen information 1092 related to an Access Node partition. 1094 4.6.7. Wholesale Model 1096 o In case of wholesale access, the network provider's NAS SHOULD 1097 support reporting of access loop attributes learned from AN via 1098 the Access Node Control Mechanism (or values derived from such 1099 attributes), to a retail provider's network gateway owning the 1100 corresponding subscriber(s). 1102 o In case of L2TP wholesale, the NAS MUST support a proxy 1103 architecture that enables filtering and conditional access for 1104 different providers to dedicated Access Node Control resources on 1105 an Access Node. 1107 o The NAS when acting as a LAC MUST communicate generic access line 1108 related information to the LNS in a timely fashion. 1110 o The NAS when acting as a LAC MAY asynchronously notify the LNS of 1111 updates to generic access line related information. 1113 4.6.8. Security 1115 The ANCP related security threats that could be encountered on the 1116 NAS are described in [draft-ietf-ancp-security-threats-00.txt]. This 1117 document develops a threat model for ANCP security, aiming to decide 1118 which security functions are required at the ANCP level. 1120 5. Policy Server Interaction 1122 This document does not consider the specific details of the 1123 communication with a policy server (e.g. using RADIUS). 1125 6. Management Related Requirements 1127 o It MUST be possible to configure the following parameters on the 1128 Access Node and the NAS: 1130 * Parameters related to the Control Channel transport method: 1131 these include the VPI/VCI and transport characteristics (e.g. 1132 VBR-rt or CBR) for ATM networks or the C-VLAN ID and S-VLAN ID 1133 and p-bit marking for Ethernet networks; 1135 * Parameters related to the Control Channel itself: these include 1136 the IP address of the IP interface on the Access Node and the 1137 NAS. 1139 o When the operational status of the Control Channel is changed 1140 (up>down, down>up) a linkdown/linkup trap SHOULD be sent towards 1141 the EMS. This requirement applies to both the AN and the NAS. 1143 o The Access Node MUST provide the possibility using SNMP to 1144 associate individual DSL lines with specific Access Node Control 1145 Sessions. 1147 o The Access Node MUST notify the EMS of Access Node Control 1148 configuration changes in a timely manner. 1150 o The Access Node MUST provide a mechanism that allows the 1151 concurrent access on the same resource from several managers (EMS 1152 via SNMP, NAS via ANCP). Only one manager may perform a change at 1153 a certain time. 1155 7. Security Considerations 1157 [draft-ietf-ancp-security-threats-00.txt] investigates the ANCP 1158 related security threats that could be encountered on the Access Node 1159 and the NAS. It develops a threat model for ANCP security, aiming to 1160 decide which security functions are required at the ANCP level. 1161 Based on this, the following security requirements are required: 1163 o The ANCP MUST offer authentication of the Access Node to the NAS. 1165 o The integrity of the Access Node Control interactions MUST be 1166 ensured using either integrity with a separate protocol (e.g. 1167 IPSec) or by designing message integrity into ANCP. 1169 o The ANCP MUST offer authentication of the NAS to the Access Node. 1171 o The ANCP MUST allow authorization to take place at the NAS and the 1172 Access Node. 1174 o The ANCP MUST offer replay protection. 1176 o The ANCP MUST provide data origin authentication. 1178 o The ANCP MUST be robust against denial of service attacks. 1180 o The ANCP SHOULD provide mutual authentication between different 1181 communicating entities. 1183 o The ANCP SHOULD offer confidentiality protection. 1185 o The ANCP SHOULD distinguish the control messages from the data. 1187 o The ANCP SHOULD provide privacy protection. 1189 8. Acknowledgements 1191 The authors would like to thank everyone that has provided comments 1192 or input to this document. In particular, the authors acknowledge 1193 the work done by the contributors to the DSL Forum related 1194 activities: Jerome Moisand, Wojciech Dec, Peter Arberg and Ole 1195 Helleberg Andersen. The authors also thank Bharat Joshi for 1196 commenting on this document. 1198 9. References 1200 9.1. Normative References 1202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1203 Requirement Levels", RFC 2119, March 1997. 1205 9.2. Informative References 1207 [G.997.1] ITU-T, "Physical layer management for digital subscriber 1208 line (DSL) transceivers", ITU-T Rec. G.997.1, Sep 2005. 1210 [RFC2881] Mitton, D. and M. Beadles, "Network Access Server 1211 Requirements Next Generation (NASREQNG) NAS Model", 1212 RFC 2881, Jul 2000. 1214 [TR-058] Elias, M. and S. Ooghe, "Multi-Service Architecture & 1215 Framework Requirements", DSL Forum TR-058, September 2003. 1217 [TR-059] Anschutz, T., "DSL Evolution - Architecture Requirements 1218 for the Support of QoS-Enabled IP Services", DSL Forum TR- 1219 059, September 2003. 1221 [TR-101] Cohen, A. and E. Shrum, "Migration to Ethernet-Based DSL 1222 Aggregation", DSL Forum TR-101, May 2006. 1224 [WT-147] Voigt, N., Ooghe, S., and M. Platnic, "Layer 2 Control 1225 Mechanism For Broadband Multi-Service Architectures", DSL 1226 Forum WT-147, Oct 2006. 1228 [draft-ietf-ancp-security-threats-00.txt] 1229 Moustafa, H., Tschofenig, H., and S. De Cnodder, "Security 1230 Threats and Security Requirements for the Access Node 1231 Control Protocol (ANCP)", 1232 draft-moustafa-ancp-security-threats-00.txt, Dec 2006. 1234 Authors' Addresses 1236 Sven Ooghe 1237 Alcatel-Lucent 1238 Copernicuslaan 50 1239 B-2018 Antwerpen 1240 Belgium 1242 Phone: +32 3 240 42 26 1243 Email: sven.ooghe@alcatel-lucent.be 1245 Norbert Voigt 1246 Siemens Networks GmbH & Co. KG 1247 Siemensallee 1 1248 17489 Greifswald 1249 Germany 1251 Phone: +49 3834 555 771 1252 Email: norbert.voigt@siemens.com 1254 Michel Platnic 1255 ECI Telecom 1256 30 Hasivim Street 1257 49517 Petakh Tikva 1258 Israel 1260 Phone: + 972 3 926 85 35 1261 Email: michel.platnic@ecitele.com 1263 Thomas Haag 1264 T-Systems 1265 Deutsche Telekom Allee 7 1266 64295 Darmstadt 1267 Germany 1269 Phone: +49 6151 937 5347 1270 Email: thomas.haag@t-systems.com 1271 Sanjay Wadhwa 1272 Juniper Networks 1273 10 Technology Park Drive 1274 Westford, MA 01886 1275 US 1277 Phone: 1278 Email: swadhwa@juniper.net 1280 Full Copyright Statement 1282 Copyright (C) The IETF Trust (2007). 1284 This document is subject to the rights, licenses and restrictions 1285 contained in BCP 78, and except as set forth therein, the authors 1286 retain all their rights. 1288 This document and the information contained herein are provided on an 1289 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1290 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1291 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1292 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1293 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1294 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1296 Intellectual Property 1298 The IETF takes no position regarding the validity or scope of any 1299 Intellectual Property Rights or other rights that might be claimed to 1300 pertain to the implementation or use of the technology described in 1301 this document or the extent to which any license under such rights 1302 might or might not be available; nor does it represent that it has 1303 made any independent effort to identify any such rights. Information 1304 on the procedures with respect to rights in RFC documents can be 1305 found in BCP 78 and BCP 79. 1307 Copies of IPR disclosures made to the IETF Secretariat and any 1308 assurances of licenses to be made available, or the result of an 1309 attempt made to obtain a general license or permission for the use of 1310 such proprietary rights by implementers or users of this 1311 specification can be obtained from the IETF on-line IPR repository at 1312 http://www.ietf.org/ipr. 1314 The IETF invites any interested party to bring to its attention any 1315 copyrights, patents or patent applications, or other proprietary 1316 rights that may cover technology that may be required to implement 1317 this standard. Please address the information to the IETF at 1318 ietf-ipr@ietf.org. 1320 Acknowledgment 1322 Funding for the RFC Editor function is provided by the IETF 1323 Administrative Support Activity (IASA).