idnits 2.17.1 draft-ietf-ancp-protocol-00.txt: -(56): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(58): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(125): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(147): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(226): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(229): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(230): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(231): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(232): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(249): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(250): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(488): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(489): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(491): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(556): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(559): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(560): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(561): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(692): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(693): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(700): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(732): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(765): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(796): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(806): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(807): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(848): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(860): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(861): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(862): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(864): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(887): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(888): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(889): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(891): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(925): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(974): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(992): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(994): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1009): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1234): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1236): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1238): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1257): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1283): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1288): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1289): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1290): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1291): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1305): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1330): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1333): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1340): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1342): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1355): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1438): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1447): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1448): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1449): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1456): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1466): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1507): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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.a on line 28. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1586. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 48), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 48. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1, updated by RFC 4748 (on line 1550), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 48. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1, updated by RFC 4748 (on line 1550), which is fine, but *also* found old RFC 3978, Section 5.4, paragraph 1 text on line 48. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 75 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 39) being 100 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 609 instances of too long lines in the document, the longest one being 19 characters in excess of 72. ** The abstract seems to contain references ([4], [9], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 3 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 350 has weird spacing: '...scribed in...' == Line 454 has weird spacing: '...ication by l...' == Line 541 has weird spacing: '...dentity of ...' == Line 797 has weird spacing: '...uld not cons...' == Line 1075 has weird spacing: '... by the opera...' == (1 more instance...) -- 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 25, 2007) is 6270 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) -- Looks like a reference, but probably isn't: '1-3' on line 131 -- Looks like a reference, but probably isn't: 'RFC3293' on line 1481 == Unused Reference: '2' is defined on line 1489, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1493, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- No information found for draft-moisand-gsmp-ancp-multicast - is the name correct? -- Possible downref: Normative reference to a draft: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '8' == Outdated reference: A later version (-13) exists of draft-ietf-ancp-framework-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ancp-framework (ref. '9') Summary: 10 errors (**), 0 flaws (~~), 15 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Working Group Name Sanjay Wadhwa 3 Internet Draft Juniper Networks 4 Expires: August 25, 2007 5 Jerome Moisand 6 Juniper Networks 8 Swami Subramanian 9 Juniper Networks 11 Thomas Haag 12 T-Systems 14 Norbert Voigt 15 Siemens 17 February 25, 2007 19 Protocol for Access Node Control Mechanism in Broadband Networks 21 draft-ietf-ancp-protocol-00.txt 23 Status of this Memo 25 By submitting this Internet-Draft, each author represents that any 26 applicable patent or other IPR claims of which he or she is aware 27 have been or will be disclosed, and any of which he or she becomes 28 aware will be disclosed, in accordance with section 6 of BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. Internet-Drafts are draft documents valid for a maximum of 34 six months and may be updated, replaced, or obsoleted by other 35 documents at any time. It is inappropriate to use Internet-Drafts as 36 reference material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html 44 This Internet-Draft will expire on August 22, 2007. 46 Copyright Notice 48 Copyright (C) The Internet Society (2007). All Rights Reserved. 50 Abstract 52 This document describes proposed extensions to the GSMPv3 protocol to 53 allow its use in a broadband environment, as a control plane between 54 Access Nodes (e.g. DSLAM) and Broadband Network Gateways (e.g. NAS). 55 These proposed extensions are required to realize a protocol for 56 �Access Node Control� mechanism as described in [9]. The resulting 57 protocol with the proposed extensions to GSMPv3 [4] is referred to as 58 �Access Node Control Protocol� (ANCP). This document focuses on 59 specific use cases of access node control mechanism for topology 60 discovery, line configuration, and OAM. It is intended to be 61 augmented by additional protocol specification for future use cases 62 considered in scope by the ANCP charter. 64 Conventions used in this document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC-2119 [1]. 70 Table of Contents 72 1 Specification Requirements 4 74 2 Introduction4 76 3 Broadband Access Aggregation 4 78 3.1 ATM-based broadband aggregation..........................4 79 3.2 Ethernet-based broadband aggregation.....................6 81 4 Access Node Control Protocol 7 83 4.1 Overview.................................................7 84 4.2 ANCP based Access Topology Discovery.....................8 85 4.2.1 Goals..............................................8 86 4.2.2 Message Flow.......................................8 87 4.3 ANCP based Line Configuration............................9 88 4.3.1 Goals..............................................9 89 4.3.2 Message Flow......................................10 90 4.4 ANCP based Transactional Multicast......................12 91 4.5 ANCP based OAM..........................................13 92 4.5.1 Message Flow......................................13 94 5 Access Node Control Protocol (ANCP) 14 96 5.1 ANCP/TCP connection establishment.......................14 97 5.2 ANCP Connection keep-alive..............................15 98 5.3 Capability negotiation..................................16 99 5.4 GSMP Message Extensions for Access Node Control.........18 100 5.4.1 General Extensions................................18 101 5.4.2 Topology Discovery Extensions.....................21 102 5.4.3 Line Configuration Extensions.....................30 103 5.4.4 OAM Extensions....................................32 104 5.5 ATM-specific considerations.............................35 105 5.6 Ethernet-specific considerations........................36 106 6 IANA Considerations 36 108 7 Security Considerations 36 110 8 References 37 112 Author's Addresses38 114 Intellectual Property Statement 38 116 Disclaimer of Validity 39 118 Copyright Statement 39 120 Acknowledgment 39 122 1 Specification Requirements 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 �SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119. 128 2 Introduction 130 DSL is a widely deployed access technology for Broadband Access for 131 Next Generation Networks. Several specifications like [1-3] describe 132 possible architectures for these access networks. In the scope of 133 these specifications are the delivery of voice, video and data 134 services. 136 When deploying value-added services across DSL access networks, 137 special attention regarding quality of service and service control is 138 required, which implies a tighter coordination between network 139 elements in the broadband access network without burdening the OSS 140 layer. 142 This draft defines extensions and modifications to GSMPv3 (specified 143 in [4]) and certain new mechanisms to realize a control plane between 144 a service-oriented layer 3 edge device (the NAS) and a layer2 Access 145 Node (e.g. DSLAM) in order to perform QoS-related, service-related 146 and subscriber-related operations. The control protocol as a result 147 of these extensions and mechanisms is referred to as �Access Node 148 Control Protocol� (ANCP). 150 In addition to specifying extensions and modifications to relevant 151 GSMP messages applicable to access node control mechanism, this draft 152 also defines values that ANCP should set for relevant fields in these 153 GSMP messages. However, to understand the basic semantics of various 154 fields in GSMP messages, the reader is referred to [4]. 156 3 Broadband Access Aggregation 158 3.1 ATM-based broadband aggregation 160 End to end DSL network consists of network and application service 161 provider networks (NSP and ASP networks), regional/access network, 162 and customer premises network. Fig1. shows ATM broadband access 163 network components. 165 The Regional/Access Network consists of the Regional Network, Network 166 Access Server, and the Access Network as show in Fig 1. Its primary 167 function is to provide end-to-end transport between the customer 168 premises and the NSP or ASP. The Access Node terminates the DSL 169 signal. It could consist of DSLAM in the central office, or remote 170 DSLAM, or a Remote Access Multiplexer (RAM). Access node is the first 171 point in the network where traffic on multiple DSL lines will be 172 aggregated onto a single network. 174 The NAS performs multiple functions in the network. The NAS is the 175 aggregation point for the subscriber traffic. It provides aggregation 176 capabilities (e.g. IP, PPP, ATM) between the Regional/Access Network 177 and the NSP or ASP. These include traditional ATM-based offerings and 178 newer, more native IP-based services. This includes support for 179 Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet 180 (PPPoE), as well as direct IP services encapsulated over an 181 appropriate layer 2 transport. 183 Beyond aggregation, NAS is also the injection point for policy 184 management and IP QoS in the Regional/Access Networks. In order to 185 allow IP QoS support over an existing non-IP-aware layer 2 access 186 network without using multiple layer 2 QoS classes, a mechanism based 187 on hierarchical scheduling is used. This mechanism defined in [1], 188 preserves IP QoS over the ATM network between the NAS and the RGs by 189 carefully controlling downstream traffic in the NAS, so that 190 significant queuing and congestion does not occur further down the 191 ATM network. This is achieved by using a diffserv-aware hierarchical 192 scheduler in the NAS that will account for downstream trunk 193 bandwidths and DSL synch rates. 194 [9] provides detailed definition and functions of each network 195 element in the broadband reference architecture. 197 Access Customer 198 <--- Aggregation ---> <------- Premises -------> 199 Network Network 201 +-------------------+ +--------------------------+ 202 +----------+ +-----+ | +-----+ +------+ |--|+-----+ +--+ +----------+ | 203 | | +-|NAS |---| |ATM |--|Access| | ||DSL |-|RG|-|Subscriber| | 204 NSP---+Regional | | +-----+ | +-----+ | Node | | ||Modem| +--+ |Devices | | 205 |Broadband | | +-----+ | +------+ | |+-----+ +----------+ | 206 |Network |-+-|NAS | +---------------|---+ +--------------------------+ 207 ASP---+ | | +-----+ | +--------------------------+ 208 | | | +-----+ | | +-----+ +--+ +----------+| 209 +----------+ +-|NAS | +------| | DSL |-|RG|-|Subscriber|| 210 +-----+ | |Modem| +--+ |Devices || 211 | +-----+ +----------+| 212 +--------------------------+ 213 RG : Routing Gateway 214 NAS : Network Access Server 216 Fig.1 ATM Broadband Aggregation Topology 218 3.2 Ethernet-based broadband aggregation 220 The Ethernet aggregation network architecture builds on the Ethernet 221 bridging/switching concepts defined in IEEE 802. The Ethernet 222 aggregation network provides traffic aggregation, class of service 223 distinction, and customer separation and traceability. VLAN tagging 224 defined in IEEE 802.1Q and being enhanced by IEEE 802.1ad is used as 225 standard virtualization mechanism in the Ethernet aggregation network. 226 The aggregation devices are �provider edge bridges� defined in IEEE 227 802.ad. 228 Stacked VLAN tags provide one possible way to create equivalent of 229 �virtual paths� and �virtual circuits� in the aggregation network. The 230 �outer� vlan could be used to create a form of �virtual path� between a 231 given DSLAM and a given NAS. And �inner� VLAN tags to create a form of 232 �virtual circuit� on a per DSL line basis. This is 1:1 VLAN allocation 233 model. An alternative model is to bridge sessions from multiple 234 subscribers behind a DSLAM into a single VLAN in the aggregation 235 network. This is N:1 VLAN allocation model. Architectural and 236 topological models of an Ethernet aggregation network in context of DSL 237 aggregation are defined in [8]. 239 4 Access Node Control Protocol 241 4.1 Overview 243 A dedicated control protocol between NAS and access nodes can 244 facilitate "NAS managed" tight QOS control in the access network, 245 simplified OSS infrastructure for service management, optimized 246 multicast replication to enable video services over DSL, subscriber 247 statistics retrieval on the NAS for accounting purposes, and fault 248 isolation capability on the NAS for the underlying access technology. 249 This dedicated control plane is referred to as �Access Node Control 250 Protocol� (ANCP). This document specifies relevant extensions to 251 GSMPv3 as defined [4] to realize ANCP. 253 Following sections discuss the use of ANCP for implementing: 255 . Dynamic discovery of access topology by the NAS to provide tight 256 QOS control in the access network. 258 . Pushing to the access-nodes, subscriber and service data 259 retrieved by the NAS from an OSS system (e.g. radius server), to 260 simplify OSS infrastructure for service management. 262 . Optimized, "NAS controlled and managed" multicast replication by 263 access-nodes at L2 layer. 265 . NAS controlled, on-demand access-line test capability 266 (rudimentary end-to-end OAM). 268 In addition to DSL, alternate broadband access technologies (e.g. 269 Metro-Ethernet, Passive Optical Networking, WiMax) will have similar 270 challenges to address, and could benefit from the same approach of a 271 control plane between a NAS and an Access Node (e.g. OLT), providing 272 a unified control and management architecture for multiple access 273 technologies, hence facilitating migration from one to the other 274 and/or parallel deployments. 276 GSMPv3 is an ideal fit for implementing ANCP. It is extensible and 277 can be run over TCP/IP, which makes it possible to run over different 278 access technologies. 280 4.2 ANCP based Access Topology Discovery 282 4.2.1 Goals 284 [1] discusses various queuing/scheduling mechanisms to avoid 285 congestion in the access network while dealing with multiple flows 286 with distinct QoS requirements. Such mechanisms require that the NAS 287 gains knowledge about the topology of the access network, the various 288 links being used and their respective rates. Some of the information 289 required is somewhat dynamic in nature (e.g. DSL sync rate), hence 290 cannot come from a provisioning and/or inventory management OSS 291 system. Some of the information varies less frequently (e.g. capacity 292 of a DSLAM uplink), but nevertheless needs to be kept strictly in 293 sync between the actual capacity of the uplink and the image the NAS 294 has of it. 296 Following section describes ANCP messages that allow the Access Node 297 (e.g. DSLAM) to communicate to the NAS, access network topology 298 information and any corresponding updates. 300 Some of the parameters that can be communicated from the DSLAM to the 301 NAS include DSL line state, actual upstream and downstream data rates 302 of a synchronized DSL link, maximum attainable upstream and 303 downstream data rates, interleaving delay etc. Topology discovery is 304 specifically important in case the net data rate of the DSL line 305 changes over time. The DSL net data rate may be different every time 306 the DSL modem is turned on. Additionally, during the time the DSL 307 modem is active, data rate changes can occur due to environmental 308 conditions (the DSL line can get "out of sync" and can retrain to a 309 lower value. 311 4.2.2 Message Flow 313 When a DSL line initially comes up or resynchronizes to a different 314 rate, the DSLAM generates and transmits a GSMP PORT UP EVENT message to 315 the NAS. The extension field in the message carries the TLVs containing 316 DSL line specific parameters. On a loss of signal on the DSL line, a 317 GSMP PORT DOWN message is generated by the DSLAM to the NAS. In order to 318 provide expected service level, NAS needs to learn the initial 319 attributes of the DSL line before the subscriber can log in and access 320 the provisioned services for the subscriber. 322 <----- Port UP(EVENT Message) <----- DSL 323 (default line parameters) Signal 325 1. NAS ----------------------- DSLAM ----------- Routing ----- Subscriber 326 Gateway 328 <----- Port UP (EVENT Message) <----- DSL 329 (updated line parameters) Resynch 330 2. NAS ----------------------- DSLAM ----------- Routing ------ Subscriber 331 Gateway 333 <--- Port DOWN (EVENT Message) <---- DSL 334 Loss of Signal 336 3. NAS ---------------------- DSLAM ------------- Routing ----- Subscriber 337 Gateway 339 Fig 2. Message flow (ANCP mapping) for topology discovery 341 The Event message with PORT UP message type (80) is used for 342 conveying DSL line attributes to the NAS. This message with relevant 343 extensions is defined in section 5.4.2. 345 4.3 ANCP based Line Configuration 347 4.3.1 Goals 349 Following dynamic discovery of access topology (identification of DSL 350 line and its attributes) as assisted by the mechanism described in 351 the previous section (topology discovery), the NAS could then query a 352 subscriber management OSS system (e.g. RADIUS server) to retrieve 353 subscriber authorization data (service profiles, aka user 354 entitlement). Most of such service mechanisms are typically enforced 355 by the NAS itself, but there are a few cases where it might be useful 356 to push such service parameter to the DSLAM for local enforcement of 357 a mechanism (e.g. DSL-related) on the corresponding subscriber line. 358 One such example of a service parameter that can be pushed to the 359 DSLAM for local enforcement is DSL "interleaving delay". Longer 360 interleaving delay (and hence stringent error correction) is required 361 for a video service to ensure better video "quality of experience", 362 whereas for a VoIP service or for "shoot first" gaming service, a 363 very short interleaving delay is more appropriate. Another relevant 364 application is downloading per subscriber multicast channel 365 entitlement information in IPTV applications where the DSLAM is 366 performing IGMP snooping or IGMP proxy function. Using ANCP, the NAS 367 could achieve the goal of pushing line configuration to the DSLAM by 368 an interoperable and standardized protocol. 370 If a subscriber wants to choose a different service, it can require 371 an OPEX intensive reconfiguration of the line via a network operator, 372 possibly implying a business-to-business transaction between an ISP 373 and an access provider. Using ANCP for line configuration from the 374 NAS dramatically simplifies the OSS infrastructure for service 375 management, allowing fully centralized subscriber-related service 376 data (e.g. RADIUS server back-end) and avoiding complex cross- 377 organization B2B interactions. 379 The best way to change line parameters would be by using profiles. 380 These profiles (DSL profiles for different services) are pre- 381 configured on the DSLAMs. The NAS can then indicate a reference to 382 the right DSL profile via ANCP. Alternatively, discrete DSL 383 parameters can also be conveyed by the NAS in ANCP. 385 4.3.2 Message Flow 387 Triggered by topology information reporting a new DSL line or triggered 388 by a subsequent user session establishment (PPP or DHCP), the NAS may 389 send line configuration information (e.g. reference to a DSL profile) to 390 the DSLAM using GSMP Port Management messages. The NAS may get such line 391 configuration data from a policy server (e.g. RADIUS). Figure 3 392 summarizes the interaction. 394 1.DSL Signal 395 <----------- 396 2. Port UP (EVENT Message) 397 (Access Topology Discovery) 398 <-------------------------- 399 3. PPP/DHCP Session 400 <----------------------------------------------------- 401 4. Authorization 402 & Authentication 403 <------------------- 404 Port Management Message 405 (Line Configuration) 406 5. ----------------> 407 +-------------+ +-----+ +-------+ +----------+ +-----------+ 408 |Radius/AAA |------|NAS |---------| DSLAM |------ | Routing |------ |Subscriber | 409 |Policy Server| +-----+ +-------+ | Gateway | +-----------+ 410 +-------------+ +----------+ 412 Fig 3. Message flow - ANCP mapping for Initial Line Configuration 414 The NAS may update the line configuration due to a subscriber service 415 change (e.g. triggered by the policy server). Figure 4 summarizes the 416 interaction 417 1. PPP/DHCP Session 418 <------------------------------------------ 420 +-------------+ 2. Service On Demand 421 | |<------------------------------------------------ 422 | Web portal | 423 | OSS etc | 3.Change of 4.Port Management 424 | | Authorization Message 425 | Radius AAA | --------> (Updated Line 426 | Policy | Config - New Profile) 427 | | -------------. 428 | | +------+ +-------+ +---------+ +----------+ 429 | |----| NAS |-----| DSLAM |---| Routing |--|Subscriber| 430 | | +------+ +-------+ | Gateway | +----------+ 431 +-------------+ +---------+ 433 Fig 4. Message flow - ANCP mapping for Updated Line Configuration 435 The format of relevant extensions to port management message is 436 defined in section 5.4.3. The line configuration models could be 437 viewed as a form of delegation of authorization from the NAS to the 438 DSLAM. 440 4.4 ANCP based Transactional Multicast 442 Typical IP multicast in access networks involves the NAS terminating 443 user requests for receiving multicast channels via IGMP. The NAS 444 authorizes the subscriber, and dynamically determines the multicast 445 subscription rights for the subscriber. Based on the user's 446 subscription, the NAS can replicate the same multicast stream to 447 multiple subscribers. This leads to a waste of access bandwidth if 448 multiple subscribers access network services via the same access-node 449 (e.g. DSLAM). The amount of multicast replication is of the order of 450 number of subscribers rather than the number of access-nodes. 452 It is ideal for NAS to send a single copy of the multicast stream to 453 a given access-node, and let the access-node perform multicast 454 replication by layer2 means (e.g. ATM point-to-multipoint cell 455 replication or ethernet data-link bridging) for subscribers behind 456 the access-node. However, operationally, NAS is the ideal choice to 457 handle subscriber management functions (authentication, 458 authorization, accounting and address management), multicast policies 459 such as per-channel authorization, and complex multicast routing 460 protocols. Therefore, some means is needed for the NAS to setup 461 multicast replication state in the access-nodes. In ATM access 462 networks, ANCP can be used by the NAS to setup P2MP cross-connects in 463 the DSLAMs. Protocol support for this use-case will be provided in 464 future. 466 4.5 ANCP based OAM 468 In a mixed Ethernet and ATM access network (including the local 469 loop), it is desirable to provide similar mechanisms for connectivity 470 checks and fault isolation, as those used in an ATM based 471 architecture. This can be achieved using an ANCP based mechanism 472 until end-to-end Ethernet OAM mechanisms are more widely implemented 473 in various network elements. 475 A simple solution based on ANCP can provide NAS with an access-line 476 test capability and to some extent fault isolation. Controlled by a 477 local management interface the NAS can use an ANCP operation to 478 trigger the access-node to perform a loopback test on the local-loop 479 (between the access-node and the CPE). The access-node can respond 480 via another ANCP operation the result of the triggered loopback test. 481 In case of ATM based local-loop the ANCP operation can trigger the 482 access-node to generate ATM (F4/F5) loopback cells on the local loop. 483 In case of Ethernet, the access-node can trigger an ethernet loopback 484 message(per EFM OAM) on the local-loop. 486 4.5.1 Message Flow 488 �Port Management� message can be used by the NAS to request access 489 node to trigger a �remote loopback� test on the local loop. The 490 result of the loopback test can be asynchronously conveyed by the 491 access node to the NAS in a �Port Management� response message. The 492 format of relevant extensions to port management message is defined 493 in section 5.4.4. 495 Port Management Message 496 (Remote Loopback ATM loopback 497 Trigger Request) OR EFM Loopback 498 1. ----------------> 2. ----------> 499 <---------+ 500 +-------------+ +-----+ +-------+ +-----------------+ 501 |Radius/AAA |------|NAS |---------| DSLAM |-------------| CPE | 502 |Policy Server| +-----+ +-------+ | (DSL Modem + | 503 +-------------+ | Routing Gateway)| 504 +-----------------+ 505 3. <--------------- 506 Port Management Message 507 (Remote Loopback Test Response) 509 5 Access Node Control Protocol (ANCP) 511 5.1 ANCP/TCP connection establishment 513 ANCP will use TCP for exchanging protocol messages. [5] defines the 514 GSMP message encapsulation for TCP. The TCP session is initiated 515 from the DSLAM (access node) to the NAS (controller). This is 516 necessary to avoid static provisioning on the NAS for all the DSLAMs 517 that are being served by the NAS. It is easier to configure a given 518 DSLAM with the single IP address of the NAS that serves the DSLAM. 519 This is a deviation from [5] which indicates that the controller 520 initiates the TCP connection to the switch. 522 NAS listens for incoming connections from the access nodes. Port 6068 523 is used for TCP connection. Adjacency protocol messages, which are 524 used to synchronize the NAS and access-nodes and maintain handshakes, 525 are sent after the TCP connection is established. ANCP messages other 526 than adjacency protocol messages may be sent only after the adjacency 527 protocol has achieved synchronization. 529 In the case of ATM access, a separate PVC (control channel) capable 530 of transporting IP would be configured between NAS and the DSLAM for 531 ANCP messages. 533 5.2 ANCP Connection keep-alive 535 GSMPv3 defines an adjacency protocol. The adjacency protocol is used 536 to synchronize states across the link, to negotiate which version of 537 the GSMP protocol to use, to discover the identity of the entity at 538 the other end of a link, and to detect when it changes. GSMP is a 539 hard state protocol. It is therefore important to detect loss of 540 contact between switch and controller, and to detect any change of 541 identity of switch or controller. No protocol messages other than 542 those of the adjacency protocol may be sent across the link until the 543 adjacency protocol has achieved synchronization. There are no changes 544 to the base GSMP adjacency protocol for implementing ANCP. 546 The NAS will set the M-flag in the SYN message (signifying it is the 547 master). Once the adjacency is established, periodic adjacency 548 messages (type ACK) are exchanged. The default ACK interval as 549 advertised in the adjacency messages is 10 sec for ANCP. It SHOULD be 550 configurable and is an implementation choice. It is recommended that 551 both ends specify the same timer value. However, it is not necessary 552 for the timer values to match. 554 The GSMP adjacency message defined in [4] is extended for ANCP and is 555 shown in section 5.3 immediately following this section. The 8-bit 556 �version� field in the adjacency protocol messages is modified to 557 carry the version and sub-version of the GSMP protocol for version 558 negotiation. ANCP uses version 3 and sub-version 1 of GSMP protocol. 559 The semantics and suggested values for Code, �Sender Name�, �Receiver 560 Name�, �Sender Instance�, and �Receiver Instance� fields are as 561 defined in [4]. The �Sender Port�, and �Receiver Port� should be set 562 to 0 by both ends. The pType field should be set to 0. The pFlag 563 should be set to 1. 565 If the adjacency times out on either end, due to not receiving an 566 adjacency message for a duration of (3 * Timer value), where the 567 timer value is specified in the adjacency message, all the state 568 received from the ANCP neighbor should be cleaned up, and the TCP 569 connection should be closed. The NAS would continue to listen for new 570 connection requests. The DSLAM will try to re-establish the TCP 571 connection and both sides will attempt to re-establish the adjacency. 573 The handling defined above will need some modifications when ANCP 574 graceful restart procedures are defined. These procedures will be 575 defined in a separate draft. 577 5.3 Capability negotiation 579 The adjacency message as defined in [4] is extended to carry 580 technology specific "Capability TLVs". Both the NAS and the access 581 node will advertise supported capabilities in the originated 582 adjacency messages. If a received adjacency message indicates absence 583 of support for a capability that is supported by the receiving 584 device, it will turn off the capability locally and will send an 585 updated adjacency message with the capability turned off to match the 586 received capability set. This process will eventually result in both 587 sides agreeing on the minimal set of supported capabilities. The 588 adjacency will not come up unless the capabilities advertised by the 589 controller and the controlled device match. 591 After initial synchronization, if at anytime a capability mismatch is 592 detected, the adjacency will be brought down (RSTACK will be 593 generated by the device detecting the mismatch), and synchronization 594 will be re-attempted. 596 0 1 2 3 597 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 | Ver | Sub | Message Type | Timer |M| Code | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Sender Name | 602 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | | | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 605 | Receiver Name | 606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 | Sender Port | 608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 609 | Receiver Port | 610 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 611 | PType | PFlag | Sender Instance | 612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 613 | Partition ID | Receiver Instance | 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Tech Type | # of TLVs | Total Length | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | | 618 ~ Capability TLVs ~ 619 | | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 622 The format of capability TLV is: 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Capability Type | Capability Length | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | | 628 ~ ~ 629 ~ Capability Data ~ 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 632 The Tech Type field type indicates the technology to which the 633 capability extension applies. For access node control in case of DSL 634 networks, new type "DSL" is proposed. The value for this field is 635 0x05. This is the first available value in the range that is not 636 currently allocated. It will need to be reserved with IANA. 638 Capability length is the number of actual bytes contained in the 639 value portion of the TLV. The TLV is padded to a 4-octet alignment. 640 Therefore, a TLV with no data will contain a zero in the length field 641 (if capability data is three octets, the length field will contain a 642 three, but the size of the actual TLV is eight octets). 644 Capability data field can be empty if the capability is just a 645 boolean. In case the capability is a boolean, it is inferred from the 646 presence of the TLV (with no data). Capability data provides the 647 flexibility to advertise more than mere presence or absence of a 648 capability. Capability types can be registered with IANA. Following 649 capabilities are defined for ANCP as applied to DSL access: 651 1. Capability Type : Dynamic-Topology-Discovery = 0x01 653 Length (in bytes) : 0 655 Capability Data : NULL 657 2. Capability Type : Line-Configuration = 0x02 659 Length (in bytes) : 0 661 Capability Data : NULL 663 3. Capability Type : Transactional-Multicast = 0x03 (controller 664 i.e. NAS terminates IGMP messages from subscribers, and via l2 665 control protocol, signals state to the access-nodes (e.g. 666 DSLAMs) to enable layer2 replication of multicast streams. In 667 ATM access network this implies that NAS instructs the access- 668 node to setup a P2MP cross-connect. The details of this will be 669 covered in a separate ID [6]. 671 Length (in bytes) : 0 673 Capability Data : NULL 675 4. Capability Type : OAM = 0x04 677 Length (in bytes) : 0 679 Capability Data : NULL 681 5. Capability Type : Bulk Transaction = 0x05 (defined in section 682 5.4.1.2). 684 Length (in bytes) : 0 686 Capability Data : NULL 688 5.4 GSMP Message Extensions for Access Node Control 690 5.4.1 General Extensions 692 Extensions to GSMP messages for various use-cases of �Acess Node 693 Control� mechanism are defined in sections 5.4.2 to 5.4.4. However, 694 sub-sections 5.4.1.1 and 5.4.1.2 below define extensions to GSMP that 695 have general applicability. 697 5.4.1.1 Extension TLV 699 In order to provide flexibility and extensibility certain GSMP 700 messages such as �PORT MANAGEMENT� and �EVENT� messages defined in 701 [4] have been modified to include an extension block that follows a 702 TLV structure. Individual messages in the following sections describe 703 the usage and format of the extension block. 705 All Extension TLV's will be designated as follow: 707 0 1 2 3 708 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 710 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | 711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 | | 713 ~ Extension Value ~ 714 | | 715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 x: Reserved Flags 719 These are generally used by specific messages and will be 720 defined in those messages. 722 Message Type 724 An 8-bit field corresponding to the message type where the 725 extension block is used. 727 Tech Type 729 An 8-bit field indicating the applicable technology type value. 730 The Message Type plus the Tech Value uniquely define a single 731 Extension Type and can be treated as a single 16 bit extension 732 type. �Tech Type� value of 0x05 SHOULD be used by ANCP for DSL 733 technology. 735 0x00 Extension block not it use. 737 0x01 � 0x04 Already in use by various technologies 739 0x05 DSL 741 0x06 - 0xFE Reserved 742 0xFF Base Specification Use 744 Block Length 746 A 8-bit field indicating the length of the Extension Value 747 field in bytes. When the Tech Type = 0x00, the length value 748 MUST be set to 0. 750 Extension Value 752 A variable length field that is an integer number of 32 bit 753 words long. The Extension Value field is interpreted according 754 to the specific definitions provided by the messages in the 755 following sections. 757 5.4.1.2 Bulk Transaction Message 759 ANCP elements MAY support a bulk transaction capability. This 760 capability is negotiated during adjacency synchronization and follows 761 general ANCP capability negotiation rules. 763 In a bulk transaction, several messages can be bundled together in a 764 single transaction. Bulk transaction uses message type 13. Reception 765 of �Bulk Transaction Message� by a node that has not advertised bulk 766 transaction capability MUST silently discard the received message. 768 The Bulk Transaction message has the following format: 770 0 1 2 3 771 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 772 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 773 | Vers | Sub | Message Type | Result| Code | 774 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 775 | Partition ID | Transaction Identifier | 776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 777 |I| SubMessage Number | Length | 778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 779 | Reserved | Count | 780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 781 | | 782 ~ Message Payload ~ 783 | | 784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 786 In a Bulk Transaction Message, each of the message in the payload is 787 framed with a complete header and is acted on individually. The 788 response to the Bulk Transaction message contains the response 789 message that would have been generated by each of the messages had it 790 been sent individually. Each response message will have the 791 appropriate result and code field filled. Any message can be included 792 in the bulk Transaction message except for adjacency message and 793 another bulk transaction message. If a prohibited message is included 794 in a bulk Transaction message, it MUST be included in the Bulk 795 response with a failure response. The response code for that failure 796 is 0x81 (�Message type prohibited in bulk Transaction�). While the 797 individual message would fail, this would not constitute a failure 798 for the Bulk Transaction message 800 5.4.2 Topology Discovery Extensions 802 The GSMP Event message with PORT UP message type (80) is used for 803 conveying DSL line attributes to the NAS. The version field should be 804 set to 3, and the sub field should be set to 1. The I and subMessage 805 fields SHOULD be set to 1 to signify no fragmentation. The Port and 806 Label fields should be set to 0. The �Port Session Number� should be set 807 to 0, and the �Event Sequence Number� should be 0. The Tech Type field 808 is extended with new type "DSL". The value for this field is 0x05. The 809 message SHOULD be generated when a line first comes UP, or any of the 810 attributes of the line change e.g. the line re-trains to a different 811 rate or one or more of the configured line attributes are 812 administratively modified. Also, when the ANCP session first comes up, 813 the DSLSM SHOULD transmit a PORT UP message to the NAS for each line 814 that is up. A DSLAM MAY use a Bulk Transaction message as defined in 815 5.4.1.2 to aggregate the transmission of PORT UP messages. 817 When a DSL line goes down (idle or silent), the DSLAM SHOULD transmit an 818 Event message with PORT DOWN message type (81) to the NAS. It is 819 recommended that the DSLAMs use a dampening mechanism per DSL line to 820 control the rate of state changes per DSL line, communicated to the NAS. 822 0 1 2 3 823 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 | Vers | Sub | Message Type | Result| Code | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | Partition ID | Transaction Identifier | 828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 |I| SubMessage Number | Length | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 | Port | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | Port Session Number | 834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 835 | Event Sequence Number | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 |x|S|x|x| | 838 +-+-+-+-+ Label | 839 ~ ~ 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 843 | | 844 ~ Extension Value ~ 845 | | 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 The format of the "Extension Value" field for Tech Type �DSL� is 849 as follows : 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | # of TLVs | Extension block length (bytes)| 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | | 855 ~ ~ 856 ~ TLVs ~ 857 | | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 860 The �Extension Value� contains one or more TLVs to identify a DSL line 861 and define it�s characteristics. A TLV can consist of multiple sub-TLVs. 862 First 2 byte of the �Extension Value� contains the number of TLVs that 863 follow. The next 2 bytes contain the total length of the TLVs carried in 864 the extension block in bytes (existing �Block Length� field in the GSMP 865 message is limited to 255 bytes and is not sufficient). 867 General format of a TLV is : 869 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 871 | Type | Length | 872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 873 | | 874 ~ ~ 875 ~ Value ~ 876 | | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 The value field in each TLV is padded to a 4-octet alignment. The Length 880 field in each TLV contains the actual number of bytes in the TLV (not 881 including the padding if present). If a TLV is not understood by the 882 NAS, it is silently ignored. Currently defined types start from 0x01. 884 Following TLVs are currently defined: 886 1. Type (Access-Loop-Circuit-ID = 0x01): This is a mandatory TLV and 887 contains an identifier of the subscriber�s connection to the access 888 node (i.e. �local loop�). The �local loop� can be ATM based or 889 Ethernet based. The �Access Loop Circuit ID� has local significance 890 at the access node. The exact usage on the NAS is beyond the scope 891 of this document. The format used for �local loop� identification 892 in ANCP messages MUST be identical to what is used by the access 893 nodes in subscriber signaling messages when the access nodes act as 894 �signaling relay agents� as outlined in [7] and [8]. 896 Length : (upto 63 bytes) 898 Value : ASCII string. 900 For an ATM based local loop the string consists of slot/port and 901 VPI/VCI information corresponding to the subscriber�s DSL 902 connection. Default syntax for the string inserted by the access 903 node as per [8] is: 905 �Access-Node-Identifier atm slot/port:vpi.vci� 907 The Access-Node-Identifier uniquely identifies the access node in 908 the access network. The slot/port and VPI/VCI uniquely identifies 909 the DSL line on the access node. Also, there is one to one 910 correspondence between DSL line and the VC between the access node 911 and the NAS. 913 For local loop which is Ethernet based (and tagged), the string 914 consists of slot/port and VLAN tag corresponding to the 915 subscriber. Default syntax for the string inserted by the access 916 node as per [8] is: 918 "Access-Node-Identifier eth slot/port[:vlan-id]" 920 2. Type (Access-Loop-Remote-Id = 0x02): This is an optional TLV and 921 contains an identifier to uniquely identify a user on a local loop 922 on the access node. The exact usage on the NAS is out of scope of 923 this document. It is desirable that the format used for the field 924 is similar to what is used by the access nodes in subscriber 925 signaling messages when the access nodes act as �signaling relay 926 agents� as outlined in [7] and [8]. 928 Length : (upto 63 bytes) 930 Value : ASCII string 932 3. Type (Access-Aggregation-Circuit-ID-Binary = 0x06) 934 Length : (8 bytes) 936 Value : two 32 bit integers. 938 For ethernet access aggregation, where a per-subscriber (stacked) 939 VLAN can be applied (1:1 model defined in [8]), the VLAN stack 940 provides a convenient way to uniquely identify the DSL line. The 941 outer VLAN is equivalent to virtual path between a DSLAM and the 942 NAS and inner VLAN is equivalent to a virtual circuit on a per DSL 943 line basis. In this scenario, any subscriber data received by the 944 access node and transmitted out the uplink to the aggregation 945 network will be tagged with the VLAN stack assigned by the access 946 node 948 This TLV can carry the VLAN tags assigned by the access node in the 949 ANCP messages. The VLAN tags can uniquely identify the DSL line 950 being referred to in the ANCP messages, assuming the VLAN tags are 951 not in any way translated in the aggregation network and are unique 952 across physical ports. Each 32 bit integer (least significant bits) 953 contains a 12 bit VLAN identifier (which is part of the VLAN tag 954 defined by IEEE 802.1Q). 956 Also, in case of an ATM aggregation network, where the DSLAM is 957 directly connected to the NAS (without an intermediate ATM switch), 958 the two values can contain VPI and VCI on the DSLAM uplink (and can 959 uniquely identify the DSL line on the DSLAM). 961 This TLV is optional. 963 4. Type (Access-Aggregation-Circuit-ID-ASCII = 0x03) 965 Length : (upto 63 bytes) 967 Value : ASCII string. 969 This field contains information pertaining to an uplink on the 970 access node. For Ethernet access aggregation, assuming the access 971 node assigns VLAN tags (1:1 model), typical format for the string 972 is: 974 �Access-Node-Identifier eth slot/port [:inner-vlan-id][:outer-vlan-id]� 976 The slot/port corresponds to the ethernet uplink on the access node 977 towards the NAS. 979 For an ATM aggregation network, typical format for the string is: 981 �Access-Node-Identifier atm slot/port:vpi.vci� 983 This TLV allows the NAS to associate the information contained in 984 the ANCP messages to the DSL line on the access node. 986 If the access node inserts this string in the ANCP messages, when 987 referring to local loop characteristics (e.g. DSL line in case of a 988 DSLAM), then it should be able to map the information contained in 989 the string uniquely to the local loop (e.g. DSL line). 991 On the NAS, the information contained in this string can be used to 992 derive an �aggregation network� facing construct (e.g. an IP 993 interface) corresponding to the local loop (e.g. DSL line). The 994 association could be based on �local configuration� on the NAS. 996 The access node can also convey to the NAS, the characteristics 997 (e.g. bandwidth) of the uplink on the access node. This TLV then 998 serves the purpose of uniquely identifying the uplink whose 999 characteristics are being defined. A separate set of sub-TLVs will 1000 be defined for the uplink characteristics (TBD). 1002 This TLV is optional. 1004 5. Type (DSL Line Attributes = 0x04): 1006 Length : variable (up to 1024 bytes) 1008 Value : This consists of one or more Sub-TLVs corresponding to DSL 1009 line attributes. No sub-TLVs other than the �DSL type� and �DSL 1010 line state� SHOULD be included in a PORT DOWN message. 1012 The general format of the sub-TLVs is identical to the general TLV 1013 format. The value field in each sub-TLV is padded to a 4-octet 1014 alignment. The Length field in each sub-TLV contains the actual 1015 number of bytes in the TLV (not including the padding if present). 1016 Current defined sub-TLV types are start from 0x81. 1018 Following sub-TLVs are currently defined : 1020 . Type (DSL-Type = 0x91) : Defines the type of transmission system 1021 in use. This is a mandatory TLV. 1023 Length : (4 bytes) 1025 Value : (Transmission system : ADSL1 = 0x01, ADSL2 = 0x02, 1026 ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL = 0x06, UNKNOWN 1027 = 0x07). 1029 . Type (Actual-Data-Rate-Upstream = 0x81) : Actual data rate 1030 upstream of a synchronized DSL line. This is a mandatory TLV. 1031 This rate value and all the subsequent ones account for the DSL 1032 overhead (i.e. signify the net rate). 1034 Length : (4 bytes) 1036 Value : (Rate in Kb/sec) 1038 . Type (Actual-Data-Rate-Downstream = 0x82) : Actual data rate 1039 downstream of a synchronized DSL line. This is a mandatory TLV. 1041 Length : (4 bytes) 1042 Value : (Rate in Kb/sec) 1044 . Type (Minimum-Data-Rate-Upstream = 0x83) : Minimum data rate 1045 desired by the operator. This is optional. 1047 Length : (4 bytes) 1049 Value : (Rate in Kb/sec) 1051 . Type (Minimum-Data-Rate-Downstream = 0x84) : Minimum data rate 1052 desired by the operator. This is optional. 1054 Length : (4 bytes) 1056 Value : (Rate in Kb/sec) 1058 . Type (Attainable-Data-Rate-Upstream = 0x85) : Maximum upstream 1059 rate that can be attained on the DSL line. This is an optional 1060 TLV. 1062 Length : (4 bytes) 1064 Value : (Rate in Kb/sec) 1066 . Type (Attainable-Data-Rate-Downstream = 0x86) : Maximum 1067 downstream rate that can be attained on the DSL line. This is 1068 an optional TLV. 1070 Length : (4 bytes) 1072 Value : (Rate in Kb/sec) 1074 . Type (Maximum-Data-Rate-Upstream = 0x87) : Maximum data rate 1075 desired by the operator. This is optional. 1077 Length : (4 bytes) 1079 Value : (Rate in Kb/sec) 1081 . Type (Maximum-Data-Rate-Downstream = 0x88) : Maximum data rate 1082 desired by the operator. This is optional. 1084 Length : (4 bytes) 1086 Value : (Rate in Kb/sec) 1088 . Type (Minimum-Low-Power-Data-Rate-Upstream = 0x89) : Minimum 1089 data rate desired by the operator in low power state. This is 1090 optional. 1092 Length : (4 bytes) 1094 Value : (Rate in Kb/sec) 1096 . Type (Minimum-Low-Power-Data-Rate-Downstream = 0x8A) : Minimum 1097 data rate desired by the operator in low power state. This is 1098 optional. 1100 Length : (4 bytes) 1102 Value : (Rate in Kb/sec) 1104 . Type (Maximum-Interleaving-Delay-Upstream = 0x8B) : maximum one 1105 way interleaving delay. This is optional. 1107 Length : (4 bytes) 1109 Value : (Time in msec) 1111 . Type (Actual-Interleaving-Delay-Upstream = 0x8C) : Value 1112 corresponding to the interleaver setting. This is optional. 1114 Length : (4 bytes) 1116 Value : (Time in msec) 1118 . Type (Maximum-Interleaving-Delay-Downstream = 0x8D) : maximum 1119 one way interleaving delay. This is optional. 1121 Length : (4 bytes) 1123 Value : (Time in msec) 1125 . Type (Actual-Interleaving-Delay-Downstream = 0x8E) : Value 1126 corresponding to the interleaver setting. This is optional. 1128 Length : (4 bytes) 1130 Value : (Time in msec) 1132 . Type (DSL line state = 0x8F) : The state of the DSL line. For 1133 PORT UP message, at this time, the TLV is optional (since the 1134 message type implicitly conveys the state of the line). For PORT 1135 DOWN, the TLV is mandatory, since it further communicates the 1136 state of the line as IDLE or SILENT. 1138 Length : (4 bytes) 1140 Value : { SHOWTIME = 0x01, IDLE = 0x02, SILENT = 0x03 } 1142 . Type (Access Loop Encapsulation = 0x90) : The data link protocol 1143 and, optionally the encapsulation overhead on the access loop. 1144 This is an optional TLV. However, when this TLV is present, the 1145 data link protocol MUST minimally be indicated. The 1146 encapsulation overhead can be optionally indicated. 1148 Length : (3 bytes) 1150 Value : The three bytes (most to least significant) and valid 1151 set of values for each byte are defined below. 1153 Data Link (1 byte): {ATM AAL5 = 0, 1155 ETHERNET = 1} 1157 Encaps 1 (1 byte): {NA = 0, 1159 Untagged Ethernet = 1, 1161 Single-tagged Ethernet = 2} 1163 Encaps 2 (1 byte):{ NA = 0, 1165 PPPoA LLC = 1, 1167 PPPoA NULL = 2, 1169 IPoA LLC = 3, 1171 IPoA NuLL = 4, 1173 Ethernet over AAL5 LLC with FCS = 5, 1175 Ethernet over AAL5 LLC without FCS = 6, 1177 Ethernet over AAL5 NULL with FCS = 7, 1178 Ethernet over AAL5 NULL without FCS = 8} 1180 If this TLV is present, the Data Link protocol MUST be indicated as 1181 defined above. However, the Access Node can choose to not convey the 1182 encapsulation on the access loop by specifying a value of 0 (NA) for the 1183 two encapsulation fields. 1185 5.4.3 Line Configuration Extensions 1187 The NAS uses extension block in the Port Management messages to convey 1188 service attributes of the DSL lines to the DSLAM. TLVs are defined for 1189 DSL line identification and service data for the DSL lines. Port number 1190 is set to 0 in the message. A new action type "Configure Connection 1191 Service Data" (value 0x8) is defined. The "Function" field is set to the 1192 action type. This action type indicates to the device being controlled 1193 (access-node i.e. DSLAM) to apply service configuration data contained 1194 in the extension value (TLVs), to the DSL line (identified by one of the 1195 TLVs in the extension value). The Tech Type field is extended with new 1196 type "DSL". The value for this field is 0x05. 1198 0 1 2 3 1199 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Vers | Sub | Message Type | Result| Code | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | Partition ID | Transaction Identifier | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 |I| SubMessage Number | Length | 1206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1207 | Port | 1208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1209 | Port Session Number | 1210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1211 | Event Sequence Number | 1212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1213 |R|x|x|x|x|x|x|x| Duration | Function | X-Function | 1214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1215 | Event Flags | Flow Control Flags | 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 | | 1220 ~ Extension Value ~ 1221 | | 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 The format of the "Extension Value" field is as follows: 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | # of TLVs | Extension Block length (bytes)| 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | | 1229 ~ ~ 1230 ~ TLVs ~ 1231 | | 1232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 The �Extension Value� field contains one or more TLVs containing DSL 1235 line identifier and desired service attributes of the the DSL line. 1236 First 2 byte of the �Extension Value� contains the number of TLVs 1237 that follow. The next 2 bytes contain the total length of the 1238 extension block in bytes (existing �Block Length� field in the GSMP 1239 message is limited to 255 bytes and is not sufficient). 1241 General format of a TLV is: 1243 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | Type | Length | 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | | 1248 ~ ~ 1249 ~ Value ~ 1250 | | 1251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1253 The value field is padded to a 4-octet alignment. The Length field in 1254 each TLV contains the actual number of bytes in the TLV (not 1255 including the padding if present). If a TLV is not understood by the 1256 access-node, it is silently ignored. Depending upon the deployment 1257 scenario, the NAS may specify �Access Loop Circuit-ID� or the �Access 1258 Aggregation Circuit-ID) as defined in section 5.4.1. Following TLVs 1259 can appear in this message: 1261 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 1262 o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in 1263 section 5.4.1. 1265 o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in 1266 section 5.4.1. 1268 o Type (Service-Profile-Name = 0x05): Reference to a pre-configured 1269 profile on the DSLAM that contains service specific data for the 1270 subscriber. 1272 Length : (upto 64 bytes) 1274 Value : ASCII string containing the profile name (NAS learns 1275 from a policy server after a subscriber is authorized). 1277 In future, more TLVs MAY be defined for individual service attributes 1278 of a DSL line (e.g. rates, interleaving delay, multicast channel 1279 entitlement access-list etc). 1281 5.4.4 OAM Extensions 1283 GSMP �Port Management� message (type 32) SHOULD be used by the NAS to 1284 trigger access node to run a loopback test on the local loop. The 1285 message format is defined in section 5.4.2. The version field SHOULD 1286 be set to 3 and sub-version field SHOULD be set to 1. The remaining 1287 fields in the GSMP header have standard semantics. The function type 1288 used in the request message SHOULD be set to �remote loopback� (type 1289 = 0x09). The port, �port session number�, �event sequence number�, 1290 duration, �event flags�, �flow control flags� and code fields SHOULD 1291 all be set to 0. The result field SHOULD be set to �AckAll� to 1292 indicate requirement for the access node to send a success for 1293 failure response. The transaction ID SHOULD contain a sequence number 1294 inserted by the NAS in each request that it generates. The extension 1295 field format is also defined above in section 5.4.2. The extension 1296 value field can contain one or more TLVs including the access-line 1297 identifier on the DSLAM and OAM test characteristics desired by the 1298 NAS. 1300 The TLV format is defined above in section 5.4.2. The value field is 1301 padded to a 4-octet alignment. The Length field in each TLV contains 1302 the actual number of bytes in the TLV (not including the padding if 1303 present). If a TLV is not understood by the NAS, it is silently 1304 ignored. Depending upon the deployment scenario, the NAS may specify 1305 �Access Loop Circuit-ID� or the �Access Aggregation Circuit-ID) as 1306 defined in section 5.4.1. Following TLVs can appear in this message: 1308 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 1310 o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in 1311 section 5.4.1. 1313 o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in 1314 section 5.4.1. 1316 o Type (OAM-Loopback-Test-Parameters = 0x07): Parameters related to 1317 loopback test. This is an optional TLV. If this TLV is not present 1318 in the request message, the DSLAM SHOULD use locally determined 1319 default values for the test parameters. 1321 Length: 4 bytes 1323 Value : two 1 byte numbers described below (listed in order of 1324 most to least significant). Thus, the 4 bytes consist of 1 byte 1325 of Count, followed by 1 byte of Timeout, followed by two pad bytes 1326 of zero. 1328 o Count (1 byte) : Number of loopback cells/messages that should 1329 be generated on the local loop as part of the loopback test. 1330 The NAS SHOULD restrict the �count� to be greater than 0 and 1331 less than or equal to 32. The DSLAM SHOULD discard the request 1332 for a loopback test, if the received test parameters contain 1333 an out of range value for the �count� field. The DSLAM MAY 1334 optionally send a failure response to the NAS with the code 1335 �invalid test parameter�. 1337 o Timeout (1 byte) : Upper bound on the time in seconds that the 1338 NAS would wait for a response from the DSLAM. If the total 1339 time taken by the DSLAM to complete a test with requested 1340 parameters, exceeds the specified �timeout� value, it can 1341 choose to omit the generation of a response to the NAS. DSLAM 1342 SHOULD use a locally determined value for the �timeout�, if 1343 the received value of the �timeout� parameter is 0. 1345 o Type (Opaque-Data = 0x08) : This is an optional TLV. If present in 1346 the request message, the DSLAM SHOULD reflect it back in the 1347 response unmodified. 1349 Length : 8 bytes 1350 Value : Two 32 bit integers inserted by the NAS (not to be 1351 interpreted by the DSLAM, but just reflected back in the 1352 response). 1354 The access node generates a success or failure response when it deems 1355 the loopback test to be complete. �Port Management� message (type 32) 1356 is used. The result field SHOULD be set to success or failure. The 1357 function type SHOULD be set to 0x09. The transaction ID SHOULD be 1358 copied from the sequence number contained in the corresponding 1359 request. The other parameters not explicitly defined here SHOULD be 1360 set as specified in the request message above. The code field SHOULD 1361 be set to a value in the range 0x500 to 0x5ff (to be reserved with 1362 IANA) to indicate the status of the executed test. The valid values 1363 defined are (can be extended in future): 1365 0x500 : Specified access line does not exist. 1367 0x501 : Loopback test timed out. 1369 0x502 : Reserved 1371 0x503 : DSL line status showtime. 1373 0x504 : DSL line status idle. 1375 0x505 : DSL line status silent. 1377 0x506 : DSL line status training. 1379 0x507 : DSL line integrity error. 1381 0x508 : DSLAM resource not available. 1383 0x509 : Invalid test parameter. 1385 The Extension value can contain one or more TLVs including the TLV to 1386 identify the access line on which the test was performed, and details 1387 from executing the test. The access line identifier SHOULD be identical 1388 to what was contained in the request. The relevant TLVs are: 1390 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 1392 o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in 1393 section 5.4.1. 1395 o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in 1396 section 5.4.1. 1398 o Type (Opaque-Data = 0x08) : Data inserted by the NAS in the 1399 request reflected back by the DSLAM. 1401 Length : 8 bytes 1403 Value : Two 32 bit integers as received in the request (opaque to 1404 the DSLAM). 1406 o Type (OAM-Loopback-Test-Response-String = 0x09) 1408 Length (upto 128 bytes) 1410 Value : Suitably formatted ASCII string containing useful details 1411 about the test that the NAS will display for the operator, exactly 1412 as received from the DSLAM (no manipulation/interpretation by the 1413 NAS). This is an optional TLV, but it is strongly recommended, 1414 that in case of ATM based local loop, the DSLAM at the very least 1415 indicates via this TLV, the total loopback cells generated and the 1416 total loopback cells successfully received as part of executing 1417 the requested loopback test. 1419 5.5 ATM-specific considerations 1421 The topology discovery and line configuration involve the DSL line 1422 attributes. For ATM based access networks, the DSL line on the DSLAM 1423 is identified by the port and PVP/PVC corresponding to the 1424 subscriber. The DSLAMs are connected to the NAS via an ATM access 1425 aggregation network. Since, the DSLAM (access-node) is not directly 1426 connected to the NAS, the NAS needs a mechanism to learn the DSL line 1427 identifier (more generally referred to as "Access Loop Circuit-ID") 1428 corresponding to a subscriber. The "Access loop circuit-ID" has no 1429 local significance on the NAS. The ANCP messages for topology 1430 discovery and line configuration carry opaque "Access loop Circuit- 1431 ID" which has only local significance on the DSLAMs. 1433 The access loop circuit identifier can be carried as an ASCII string 1434 in the ANCP messages. This allows ANCP to be decoupled from the 1435 specifics of the underlying access technology being controlled. On 1436 the other hand, this requires a NAS mechanism by which such 1437 identifier can be correlated to the context of an �aggregation 1438 network� facing IP interface (corresponding to the subscriber) on the 1439 NAS. This would typically require local configuration of such IP 1440 interfaces, or of the underlying ATM interfaces. 1442 5.6 Ethernet-specific considerations 1444 One possible way of approaching the use of Ethernet technology in the 1445 access aggregation network is to recreate the equivalent of Virtual 1446 Paths (VPs) and Virtual Circuits (VCs) by using stacked Virtual LAN 1447 tags. As an example, one could use an �outer� VLAN to create a form of 1448 �virtual path� between a given DSLAM and a given NAS. And then use 1449 �inner� VLAN tags to create a form of �virtual circuit� on a per DSL 1450 line basis. In this case, VLAN tags conveyed in topology discovery and 1451 line configuration messages will allow to uniquely identify the DSL line 1452 in a straightforward manner, assuming the VLAN tags are not translated 1453 in some way by the aggregation network, and are unique across physical 1454 ports. 1456 However, some carriers do not wish to use this �connection oriented� 1457 approach. Therefore, an alternative model is to bridge sessions from 1458 multiple subscribers behind a DSLAM to a single VLAN in the aggregation 1459 network. This is the N:1 model. In this model, or in the case where user 1460 traffic is sent untagged, the access node needs to insert the exact 1461 identity of the DSL line in the topology discovery and line 1462 configuration messages, and then have a mechanism by which this can be 1463 correlated to the context of an �aggregation network� facing IP 1464 interface (for the subscriber) on the NAS. This can either be based on 1465 local configuration on the NAS, or on the fact that such DSLAM (access 1466 node) typically inserts the �Access Loop Circuit ID� in subscriber 1467 signaling messages relayed to the NAS (i.e. DHCP or PPPoE discovery 1468 messages). 1470 Section 5.4.1 defines �Access Loop Circuit ID�. 1472 6 IANA Considerations 1474 New Tech-Type, capability types, sub-TLV types related to topology 1475 discovery and line configuration will need to be reserved. 1477 7 Security Considerations 1479 The NAS and DSLAMs are implicitly in a trusted domain, so security 1480 for ANCP is not a strong requirement. However, if needed security can 1481 be provided using IP security as indicated in [RFC3293]. 1483 8 References 1485 [1] DSLForum TR-059, DSL Evolution - Architecture Requirements for 1486 the Support of QoS-Enabled IP Services, Tom Anschutz (BellSouth 1487 Telecommunications), 09/2003. 1489 [2] DSLForum TR-058, Multi-Service Architecture & Framework 1490 Requirements, Mark Elias (SBC) and Sven Ooghe (Alcatel), 1491 09/2003. 1493 [3] DSLForum TR-092, Broadband Remote access server requirements 1494 document. 1496 [4] Doria, A. et al, "General Switch Management Protocol- V3" (GSMP 1497 v3), RFC 3292, June 2002. 1499 [5] Worster, T., Doria, A. and J. Buerkle, "General Switch 1500 Management Protocol (GSMP) Packet Encapsulations for 1501 Asynchronous Transfer Mode (ATM), Ethernet and Transmission 1502 Control Protocol (TCP)", RFC 3293, June 2002. 1504 [6] GSMP extensions for ANCP - Transactional Multicast, draft- 1505 moisand-gsmp-ancp-multicast-00 (work in progress). 1507 [7] �DHCP Relay Agent Information Option�, RFC 3046, January 2001. 1509 [8] Architecture & Transport: Migration to Ethernet Based DSL 1510 Aggregation, DSL Forum WT-101, Cohen et al. 1512 [9] Framework for Access Node Control Mechanism in Broadband 1513 Networks, draft-ietf-ancp-framework-00.txt. 1515 Author's Addresses 1517 Sanjay Wadhwa 1518 Juniper Networks 1519 10 Technology Park Drive 1520 Westford, MA 01886 1522 Email: swadhwa@juniper.net 1524 Jerome Moisand 1525 Juniper Networks 1526 10 Technology Park Drive 1527 Westford, MA 01886 1529 Email: jmoisand@juniper.net 1531 Swami Subramanian 1532 Juniper Networks 1533 10 Technology Park Drive 1534 Westford, MA 01886 1536 Email: ssubramanian@juniper.net 1538 Thomas Haag 1539 T-systems 1541 Email: thomas.haag@t-systems.com 1543 Norber Voigt 1544 Siemens 1546 Email: norbert.voigt@siemens.com 1548 Full Copyright Statement 1550 Copyright (C) The IETF Trust (2007). 1552 This document is subject to the rights, licenses and restrictions 1553 contained in BCP 78, and except as set forth therein, the authors 1554 retain all their rights. 1556 This document and the information contained herein are provided on an 1557 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1558 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1559 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1560 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1561 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1562 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1564 Intellectual Property 1566 The IETF takes no position regarding the validity or scope of any 1567 Intellectual Property Rights or other rights that might be claimed to 1568 pertain to the implementation or use of the technology described in 1569 this document or the extent to which any license under such rights 1570 might or might not be available; nor does it represent that it has 1571 made any independent effort to identify any such rights. Information 1572 on the procedures with respect to rights in RFC documents can be 1573 found in BCP 78 and BCP 79. 1575 Copies of IPR disclosures made to the IETF Secretariat and any 1576 assurances of licenses to be made available, or the result of an 1577 attempt made to obtain a general license or permission for the use of 1578 such proprietary rights by implementers or users of this 1579 specification can be obtained from the IETF on-line IPR repository at 1580 http://www.ietf.org/ipr. 1582 The IETF invites any interested party to bring to its attention any 1583 copyrights, patents or patent applications, or other proprietary 1584 rights that may cover technology that may be required to implement 1585 this standard. Please address the information to the IETF at 1586 ietf-ipr@ietf.org. 1588 Acknowledgment 1590 Thanks to Peter Arberg, Josef Froehler, Derek Harkness, Kim 1591 Hyldgaard, Sandy Ng, Robert Peschi, and Michel Platnic for their 1592 input to this document.