idnits 2.17.1 draft-ietf-ancp-protocol-01.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 -(122): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(144): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(234): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(237): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(238): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(239): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(240): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(257): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(258): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(496): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(497): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(499): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(565): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(595): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(596): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(600): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(650): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(653): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(654): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(655): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(787): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(788): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(795): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(827): 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 -(891): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(901): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(902): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(943): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(955): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(956): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(957): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(959): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(982): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(983): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(984): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(986): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1020): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1069): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1087): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1089): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1104): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1329): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1331): 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 -(1352): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1378): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1383): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1384): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1385): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1386): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1400): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1425): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1428): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1435): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1437): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1451): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1534): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1543): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1544): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1545): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1552): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1562): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(1600): 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 3979, Section 5, paragraph 1 on line 1665. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1672. ** 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 seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- 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 80 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 1 longer page, the longest (page 1) being 59 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 664 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], [8]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 543: '...P implementation SHOULD always set the...' RFC 2119 keyword, line 548: '... implementation SHOULD set the I and ...' RFC 2119 keyword, line 643: '...sages is 10 sec for ANCP. It SHOULD be...' RFC 2119 keyword, line 827: '... value of 0x05 SHOULD be used by ANC...' RFC 2119 keyword, line 843: '... MUST be set to 0....' (31 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == Line 358 has weird spacing: '...scribed in...' == Line 462 has weird spacing: '...ication by l...' == Line 635 has weird spacing: '...dentity of ...' == Line 892 has weird spacing: '...uld not cons...' == Line 1170 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 (July 9, 2007) is 6107 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 128 -- Looks like a reference, but probably isn't: 'RFC3293' on line 1577 == Unused Reference: '2' is defined on line 1585, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1589, 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' -- Possible downref: Non-RFC (?) normative reference: ref. '7' == 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. '8') Summary: 10 errors (**), 0 flaws (~~), 14 warnings (==), 11 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: January 9, 2008 5 Jerome Moisand 6 Juniper Networks 8 Swami Subramanian 9 Juniper Networks 11 Thomas Haag 12 T-Systems 14 Norbert Voigt 15 Siemens 17 July 9, 2007 19 Protocol for Access Node Control Mechanism in Broadband Networks 21 draft-ietf-ancp-protocol-01.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 Jan 9, 2008. 46 Copyright Notice 48 Copyright (C) The IETF Trust (2007). 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 [8]. The resulting 57 protocol with the proposed extensions to GSMPv3 [4] is referred to as 58 �Access Node Control Protocol� (ANCP). This document currently 59 focuses on specific use cases of access node control mechanism for 60 topology discovery, line configuration, and OAM as described in ANCP 61 framework document [8]. It is intended to be augmented by additional 62 protocol specification for future use cases considered in scope by 63 the ANCP charter. 65 ANCP framework document [8] describes the ANCP use-cases in detail. 66 Illustrative text for the use-cases is included here to help the 67 protocol implementer understand the greater context of ANCP protocol 68 interactions. 70 Table of Contents 72 1 Specification Requirements 4 74 2 Introduction 4 76 3 Broadband Access Aggregation 5 78 3.1 ATM-based broadband aggregation..........................5 79 3.2 Ethernet-based broadband aggregation.....................6 80 4 Access Node Control Protocol 7 82 4.1 Overview.................................................7 83 4.2 ANCP based Access Topology Discovery.....................8 84 4.2.1 Goals..............................................8 85 4.2.2 Message Flow.......................................8 86 4.3 ANCP based Line Configuration............................9 87 4.3.1 Goals..............................................9 88 4.3.2 Message Flow......................................10 89 4.4 ANCP based Transactional Multicast......................12 90 4.5 ANCP based OAM..........................................13 91 4.5.1 Message Flow......................................13 92 5 Access Node Control Protocol (ANCP) 14 93 5.1 ANCP/TCP connection establishment.......................16 94 5.2 ANCP Connection keep-alive..............................16 95 5.3 Capability negotiation..................................17 96 5.4 GSMP Message Extensions for Access Node Control.........20 97 5.4.1 General Extensions................................20 98 5.4.2 Topology Discovery Extensions.....................23 99 5.4.3 Line Configuration Extensions.....................32 100 5.4.4 OAM Extensions....................................34 101 5.5 ATM-specific considerations.............................37 102 5.6 Ethernet-specific considerations........................38 103 6 IANA Considerations 38 105 7 Security Considerations 38 107 8 References 39 109 Author's Addresses 40 111 Full Copyright Statement 40 113 Copyright (C) The IETF Trust (2007). 40 115 Intellectual Property 41 117 Acknowledgment 41 119 1 Specification Requirements 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 122 NOT",�SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 123 this document are to be interpreted as described in RFC 2119. 125 2 Introduction 127 DSL is a widely deployed access technology for Broadband Access for 128 Next Generation Networks. Several specifications like [1-3] describe 129 possible architectures for these access networks. In the scope of 130 these specifications are the delivery of voice, video and data 131 services. 133 When deploying value-added services across DSL access networks, 134 special attention regarding quality of service and service control is 135 required, which implies a tighter coordination between network 136 elements in the broadband access network without burdening the OSS 137 layer. 139 This draft defines extensions and modifications to GSMPv3 (specified 140 in [4]) and certain new mechanisms to realize a control plane between 141 a service-oriented layer 3 edge device (the NAS) and a layer2 Access 142 Node (e.g. DSLAM) in order to perform QoS-related, service-related 143 and subscriber-related operations. The control protocol as a result 144 of these extensions and mechanisms is referred to as �Access Node 145 Control Protocol� (ANCP). 147 ANCP uses the option of transporting GSMPv3 over TCP/IP. TCP 148 encapsulation for GSMPv3 is defined in [5]. GSMPv3 encapsulation 149 directly over Ethernet and ATM as defined in [5] is not considered 150 for ANCP. 152 ANCP uses a subset of GSMPv3 messages to implement currently defined 153 use-cases. These relevant GSMPv3 messages are identified in section 154 5. GSMPv3 procedures with suitable extensions, as used by ANCP, are 155 described in sections 5.1, 5.2 and 5.3. GSMPv3 general extensions and 156 GSMPv3 message specific extensions required by ANCP are described in 157 sub-sections of 5.4. In addition to specifying extensions and 158 modifications to relevant GSMP messages applicable to ANCP, this 159 draft also defines the usage of these messages by ANCP, and indicates 160 the values that ANCP should set for relevant fields in these GSMP 161 messages. However, to understand the basic semantics of various 162 fields in GSMP messages, the reader is referred to [4]. 164 3 Broadband Access Aggregation 166 3.1 ATM-based broadband aggregation 168 End to end DSL network consists of network and application service 169 provider networks (NSP and ASP networks), regional/access network, 170 and customer premises network. Fig1. shows ATM broadband access 171 network components. 173 The Regional/Access Network consists of the Regional Network, Network 174 Access Server, and the Access Network as show in Fig 1. Its primary 175 function is to provide end-to-end transport between the customer 176 premises and the NSP or ASP. The Access Node terminates the DSL 177 signal. It could consist of DSLAM in the central office, or remote 178 DSLAM, or a Remote Access Multiplexer (RAM). Access node is the first 179 point in the network where traffic on multiple DSL lines will be 180 aggregated onto a single network. 182 The NAS performs multiple functions in the network. The NAS is the 183 aggregation point for the subscriber traffic. It provides aggregation 184 capabilities (e.g. IP, PPP, ATM) between the Regional/Access Network 185 and the NSP or ASP. These include traditional ATM-based offerings and 186 newer, more native IP-based services. This includes support for 187 Point-to-Point Protocol over ATM (PPPoA) and PPP over Ethernet 188 (PPPoE), as well as direct IP services encapsulated over an 189 appropriate layer 2 transport. 191 Beyond aggregation, NAS is also the injection point for policy 192 management and IP QoS in the Regional/Access Networks. In order to 193 allow IP QoS support over an existing non-IP-aware layer 2 access 194 network without using multiple layer 2 QoS classes, a mechanism based 195 on hierarchical scheduling is used. This mechanism defined in [1], 196 preserves IP QoS over the ATM network between the NAS and the RGs by 197 carefully controlling downstream traffic in the NAS, so that 198 significant queuing and congestion does not occur further down the 199 ATM network. This is achieved by using a diffserv-aware hierarchical 200 scheduler in the NAS that will account for downstream trunk 201 bandwidths and DSL synch rates. 202 [8] provides detailed definition and functions of each network 203 element in the broadband reference architecture. 205 Access Customer 206 <--- Aggregation ---> <------- Premises -------> 207 Network Network 209 +-------------------+ +--------------------------+ 210 +----------+ +-----+ | +-----+ +------+ |--|+-----+ +--+ +----------+ | 211 | | +-|NAS |---| |ATM |--|Access| | ||DSL |-|RG|-|Subscriber| | 212 NSP---+Regional | | +-----+ | +-----+ | Node | | ||Modem| +--+ |Devices | | 213 |Broadband | | +-----+ | +------+ | |+-----+ +----------+ | 214 |Network |-+-|NAS | +---------------|---+ +--------------------------+ 215 ASP---+ | | +-----+ | +--------------------------+ 216 | | | +-----+ | | +-----+ +--+ +----------+| 217 +----------+ +-|NAS | +------| | DSL |-|RG|-|Subscriber|| 218 +-----+ | |Modem| +--+ |Devices || 219 | +-----+ +----------+| 220 +--------------------------+ 221 RG : Routing Gateway 222 NAS : Network Access Server 224 Fig.1 ATM Broadband Aggregation Topology 226 3.2 Ethernet-based broadband aggregation 228 The Ethernet aggregation network architecture builds on the Ethernet 229 bridging/switching concepts defined in IEEE 802. The Ethernet 230 aggregation network provides traffic aggregation, class of service 231 distinction, and customer separation and traceability. VLAN tagging 232 defined in IEEE 802.1Q and being enhanced by IEEE 802.1ad is used as 233 standard virtualization mechanism in the Ethernet aggregation network. 234 The aggregation devices are �provider edge bridges� defined in IEEE 235 802.ad. 236 Stacked VLAN tags provide one possible way to create equivalent of 237 �virtual paths� and �virtual circuits� in the aggregation network. The 238 �outer� vlan could be used to create a form of �virtual path� between a 239 given DSLAM and a given NAS. And �inner� VLAN tags to create a form of 240 �virtual circuit� on a per DSL line basis. This is 1:1 VLAN allocation 241 model. An alternative model is to bridge sessions from multiple 242 subscribers behind a DSLAM into a single VLAN in the aggregation 243 network. This is N:1 VLAN allocation model. Architectural and 244 topological models of an Ethernet aggregation network in context of DSL 245 aggregation are defined in [7]. 247 4 Access Node Control Protocol 249 4.1 Overview 251 A dedicated control protocol between NAS and access nodes can 252 facilitate "NAS managed" tight QOS control in the access network, 253 simplified OSS infrastructure for service management, optimized 254 multicast replication to enable video services over DSL, subscriber 255 statistics retrieval on the NAS for accounting purposes, and fault 256 isolation capability on the NAS for the underlying access technology. 257 This dedicated control plane is referred to as �Access Node Control 258 Protocol� (ANCP). This document specifies relevant extensions to 259 GSMPv3 as defined [4] to realize ANCP. 261 Following sections discuss the use of ANCP for implementing: 263 . Dynamic discovery of access topology by the NAS to provide tight 264 QOS control in the access network. 266 . Pushing to the access-nodes, subscriber and service data 267 retrieved by the NAS from an OSS system (e.g. radius server), to 268 simplify OSS infrastructure for service management. 270 . Optimized, "NAS controlled and managed" multicast replication by 271 access-nodes at L2 layer. 273 . NAS controlled, on-demand access-line test capability 274 (rudimentary end-to-end OAM). 276 In addition to DSL, alternate broadband access technologies (e.g. 277 Metro-Ethernet, Passive Optical Networking, WiMax) will have similar 278 challenges to address, and could benefit from the same approach of a 279 control plane between a NAS and an Access Node (e.g. OLT), providing 280 a unified control and management architecture for multiple access 281 technologies, hence facilitating migration from one to the other 282 and/or parallel deployments. 284 GSMPv3 is an ideal fit for implementing ANCP. It is extensible and 285 can be run over TCP/IP, which makes it possible to run over different 286 access technologies. 288 4.2 ANCP based Access Topology Discovery 290 4.2.1 Goals 292 [1] discusses various queuing/scheduling mechanisms to avoid 293 congestion in the access network while dealing with multiple flows 294 with distinct QoS requirements. Such mechanisms require that the NAS 295 gains knowledge about the topology of the access network, the various 296 links being used and their respective rates. Some of the information 297 required is somewhat dynamic in nature (e.g. DSL sync rate), hence 298 cannot come from a provisioning and/or inventory management OSS 299 system. Some of the information varies less frequently (e.g. capacity 300 of a DSLAM uplink), but nevertheless needs to be kept strictly in 301 sync between the actual capacity of the uplink and the image the NAS 302 has of it. 304 Following section describes ANCP messages that allow the Access Node 305 (e.g. DSLAM) to communicate to the NAS, access network topology 306 information and any corresponding updates. 308 Some of the parameters that can be communicated from the DSLAM to the 309 NAS include DSL line state, actual upstream and downstream data rates 310 of a synchronized DSL link, maximum attainable upstream and 311 downstream data rates, interleaving delay etc. Topology discovery is 312 specifically important in case the net data rate of the DSL line 313 changes over time. The DSL net data rate may be different every time 314 the DSL modem is turned on. Additionally, during the time the DSL 315 modem is active, data rate changes can occur due to environmental 316 conditions (the DSL line can get "out of sync" and can retrain to a 317 lower value. 319 4.2.2 Message Flow 321 When a DSL line initially comes up or resynchronizes to a different 322 rate, the DSLAM generates and transmits a GSMP PORT UP EVENT message to 323 the NAS. The extension field in the message carries the TLVs containing 324 DSL line specific parameters. On a loss of signal on the DSL line, a 325 GSMP PORT DOWN message is generated by the DSLAM to the NAS. In order to 326 provide expected service level, NAS needs to learn the initial 327 attributes of the DSL line before the subscriber can log in and access 328 the provisioned services for the subscriber. 330 <----- Port UP(EVENT Message) <----- DSL 331 (default line parameters) Signal 333 1. NAS ----------------------- DSLAM ----------- Routing ----- Subscriber 334 Gateway 336 <----- Port UP (EVENT Message) <----- DSL 337 (updated line parameters) Resynch 338 2. NAS ----------------------- DSLAM ----------- Routing ------ Subscriber 339 Gateway 341 <--- Port DOWN (EVENT Message) <---- DSL 342 Loss of Signal 344 3. NAS ---------------------- DSLAM ------------- Routing ----- Subscriber 345 Gateway 347 Fig 2. Message flow (ANCP mapping) for topology discovery 349 The Event message with PORT UP message type (80) is used for 350 conveying DSL line attributes to the NAS. This message with relevant 351 extensions is defined in section 5.4.2. 353 4.3 ANCP based Line Configuration 355 4.3.1 Goals 357 Following dynamic discovery of access topology (identification of DSL 358 line and its attributes) as assisted by the mechanism described in 359 the previous section (topology discovery), the NAS could then query a 360 subscriber management OSS system (e.g. RADIUS server) to retrieve 361 subscriber authorization data (service profiles, aka user 362 entitlement). Most of such service mechanisms are typically enforced 363 by the NAS itself, but there are a few cases where it might be useful 364 to push such service parameter to the DSLAM for local enforcement of 365 a mechanism (e.g. DSL-related) on the corresponding subscriber line. 366 One such example of a service parameter that can be pushed to the 367 DSLAM for local enforcement is DSL "interleaving delay". Longer 368 interleaving delay (and hence stringent error correction) is required 369 for a video service to ensure better video "quality of experience", 370 whereas for a VoIP service or for "shoot first" gaming service, a 371 very short interleaving delay is more appropriate. Another relevant 372 application is downloading per subscriber multicast channel 373 entitlement information in IPTV applications where the DSLAM is 374 performing IGMP snooping or IGMP proxy function. Using ANCP, the NAS 375 could achieve the goal of pushing line configuration to the DSLAM by 376 an interoperable and standardized protocol. 378 If a subscriber wants to choose a different service, it can require 379 an OPEX intensive reconfiguration of the line via a network operator, 380 possibly implying a business-to-business transaction between an ISP 381 and an access provider. Using ANCP for line configuration from the 382 NAS dramatically simplifies the OSS infrastructure for service 383 management, allowing fully centralized subscriber-related service 384 data (e.g. RADIUS server back-end) and avoiding complex cross- 385 organization B2B interactions. 387 The best way to change line parameters would be by using profiles. 388 These profiles (DSL profiles for different services) are pre- 389 configured on the DSLAMs. The NAS can then indicate a reference to 390 the right DSL profile via ANCP. Alternatively, discrete DSL 391 parameters can also be conveyed by the NAS in ANCP. 393 4.3.2 Message Flow 395 Triggered by topology information reporting a new DSL line or triggered 396 by a subsequent user session establishment (PPP or DHCP), the NAS may 397 send line configuration information (e.g. reference to a DSL profile) to 398 the DSLAM using GSMP Port Management messages. The NAS may get such line 399 configuration data from a policy server (e.g. RADIUS). Figure 3 400 summarizes the interaction. 402 1.DSL Signal 403 <----------- 404 2. Port UP (EVENT Message) 405 (Access Topology Discovery) 406 <-------------------------- 407 3. PPP/DHCP Session 408 <----------------------------------------------------- 409 4. Authorization 410 & Authentication 411 <------------------- 412 Port Management Message 413 (Line Configuration) 414 5. ----------------> 415 +-------------+ +-----+ +-------+ +----------+ +-----------+ 416 |Radius/AAA |------|NAS |---------| DSLAM |------ | Routing |------ |Subscriber | 417 |Policy Server| +-----+ +-------+ | Gateway | +-----------+ 418 +-------------+ +----------+ 420 Fig 3. Message flow - ANCP mapping for Initial Line Configuration 422 The NAS may update the line configuration due to a subscriber service 423 change (e.g. triggered by the policy server). Figure 4 summarizes the 424 interaction 425 1. PPP/DHCP Session 426 <------------------------------------------ 428 +-------------+ 2. Service On Demand 429 | |<------------------------------------------------ 430 | Web portal | 431 | OSS etc | 3.Change of 4.Port Management 432 | | Authorization Message 433 | Radius AAA | --------> (Updated Line 434 | Policy | Config - New Profile) 435 | | -------------. 436 | | +------+ +-------+ +---------+ +----------+ 437 | |----| NAS |-----| DSLAM |---| Routing |--|Subscriber| 438 | | +------+ +-------+ | Gateway | +----------+ 439 +-------------+ +---------+ 441 Fig 4. Message flow - ANCP mapping for Updated Line Configuration 443 The format of relevant extensions to port management message is 444 defined in section 5.4.3. The line configuration models could be 445 viewed as a form of delegation of authorization from the NAS to the 446 DSLAM. 448 4.4 ANCP based Transactional Multicast 450 Typical IP multicast in access networks involves the NAS terminating 451 user requests for receiving multicast channels via IGMP. The NAS 452 authorizes the subscriber, and dynamically determines the multicast 453 subscription rights for the subscriber. Based on the user's 454 subscription, the NAS can replicate the same multicast stream to 455 multiple subscribers. This leads to a waste of access bandwidth if 456 multiple subscribers access network services via the same access-node 457 (e.g. DSLAM). The amount of multicast replication is of the order of 458 number of subscribers rather than the number of access-nodes. 460 It is ideal for NAS to send a single copy of the multicast stream to 461 a given access-node, and let the access-node perform multicast 462 replication by layer2 means (e.g. ATM point-to-multipoint cell 463 replication or ethernet data-link bridging) for subscribers behind 464 the access-node. However, operationally, NAS is the ideal choice to 465 handle subscriber management functions (authentication, 466 authorization, accounting and address management), multicast policies 467 such as per-channel authorization, and complex multicast routing 468 protocols. Therefore, some means is needed for the NAS to setup 469 multicast replication state in the access-nodes. In ATM access 470 networks, ANCP can be used by the NAS to setup P2MP cross-connects in 471 the DSLAMs. Protocol support for this use-case will be provided in 472 future. 474 4.5 ANCP based OAM 476 In a mixed Ethernet and ATM access network (including the local 477 loop), it is desirable to provide similar mechanisms for connectivity 478 checks and fault isolation, as those used in an ATM based 479 architecture. This can be achieved using an ANCP based mechanism 480 until end-to-end Ethernet OAM mechanisms are more widely implemented 481 in various network elements. 483 A simple solution based on ANCP can provide NAS with an access-line 484 test capability and to some extent fault isolation. Controlled by a 485 local management interface the NAS can use an ANCP operation to 486 trigger the access-node to perform a loopback test on the local-loop 487 (between the access-node and the CPE). The access-node can respond 488 via another ANCP operation the result of the triggered loopback test. 489 In case of ATM based local-loop the ANCP operation can trigger the 490 access-node to generate ATM (F4/F5) loopback cells on the local loop. 491 In case of Ethernet, the access-node can trigger an ethernet loopback 492 message(per EFM OAM) on the local-loop. 494 4.5.1 Message Flow 496 �Port Management� message can be used by the NAS to request access 497 node to trigger a �remote loopback� test on the local loop. The 498 result of the loopback test can be asynchronously conveyed by the 499 access node to the NAS in a �Port Management� response message. The 500 format of relevant extensions to port management message is defined 501 in section 5.4.4. 503 Port Management Message 504 (Remote Loopback ATM loopback 505 Trigger Request) OR EFM Loopback 506 1. ----------------> 2. ----------> 507 <---------+ 508 +-------------+ +-----+ +-------+ +-----------------+ 509 |Radius/AAA |------|NAS |---------| DSLAM |-------------| CPE | 510 |Policy Server| +-----+ +-------+ | (DSL Modem + | 511 +-------------+ | Routing Gateway)| 512 +-----------------+ 513 3. <--------------- 514 Port Management Message 515 (Remote Loopback Test Response) 517 5 Access Node Control Protocol (ANCP) 519 ANCP uses a subset of GSMPv3 messages described in [4] to implement 520 currently defined use-cases. GSMPv3 general message format, used by 521 all GSMP messages other than adjacency protocol messages, is defined 522 in section 3.1.1 of GSMPv3 RFC [4]. ANCP modifies this base GSMPv3 523 message format. The modified GSMPv3 message format is defined as 524 follows: 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Vers | Sub | Message Type | Result| Code | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Partition ID | Transaction Identifier | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 |I| SubMessage Number | Length | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | | 536 ~ Message Payload ~ 537 | | 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 540 The 8-bit version field in the base GSMPv3 message header is split 541 into two 4 bit fields for carrying the version and a sub-version of 542 the GSMP protocol. ANCP uses version 3 and sub-version 1 of the GSMP 543 protocol. An ANCP implementation SHOULD always set the version field 544 to 3, and the sub-version field to 1. The Result field in the message 545 header has been modified to be 4 bits long, and the Code field to be 546 12 bits long. The definition and semantics of all the fields in the 547 header are described in section 3.1.1 of GSMPv3 RFC [4]. An ANCP 548 implementation SHOULD set the I and subMessage fields to 1 to signify 549 no fragmentation. 551 Following are the relevant GSMPv3 messages defined in [4], that are 552 currently used by ANCP. Other than the message types explicitly 553 listed below, no other GSMPv3 messages are used by ANCP currently. 555 o Event Messages 557 o Port UP message 559 o Port DOWN message 561 These messages are used by ANCP topology discovery use-case. 563 o Port Management Messages 565 These messages are used by ANCP �line configuration� use-case and 566 ANCP OAM use-case. 568 o Adjacency Protocol Messages 570 These messages are used to bring up a protocol adjacency between a 571 NAS and an AN. 573 The basic format and semantics of various fields in these GSMPv3 574 messages identified above are described in GSMPv3 RFC [4]. However, 575 the usage of these messages by ANCP, along with relevant 576 modifications and extensions required by ANCP, are described in 577 sections 5.3, 5.4.1, 5.4.2 and 5.4.3 of this document. Messages used 578 by ANCP multicast use-case will be described in future versions of 579 this document. 581 ANCP modifies and extends few basic GSMPv3 procedures. These 582 modifications and extensions are summarized below, and described in 583 more detail in the succeeding sections. 585 o ANCP provides support for a capability negotiation mechanism 586 between ANCP peers by extending the GSMPv3 adjacency protocol. 587 This mechanism and corresponding adjacency message extensions 588 are defined in section 5.3. 590 o TCP connection establishment procedure in ANCP deviates 591 slightly from the connection establishment in GSMPv3 as 592 specified in [5]. This is described in section 5.1. 594 o ANCP makes GSMPv3 messages extensible and flexible by adding a 595 general �extension block� to the end of the relevant GSMPv3 596 messages. The �extension block� contains a TLV structure to 597 carry information relevant to each ANCP use-case. The format of 598 the �extension block� is defined in section 5.4.1.1. 600 o ANCP extends GSMPv3 message exchange with a �bulk transaction� 601 capability, where multiple GSMPv3 messages can be bundled into 602 a single GSMPv3 transaction. This is described in section 603 5.4.1.2. 605 5.1 ANCP/TCP connection establishment 607 ANCP will use TCP for exchanging protocol messages. [5] defines the 608 GSMP message encapsulation for TCP. The TCP session is initiated 609 from the DSLAM (access node) to the NAS (controller). This is 610 necessary to avoid static provisioning on the NAS for all the DSLAMs 611 that are being served by the NAS. It is easier to configure a given 612 DSLAM with the single IP address of the NAS that serves the DSLAM. 613 This is a deviation from [5] which indicates that the controller 614 initiates the TCP connection to the switch. 616 NAS listens for incoming connections from the access nodes. Port 6068 617 is used for TCP connection. Adjacency protocol messages, which are 618 used to synchronize the NAS and access-nodes and maintain handshakes, 619 are sent after the TCP connection is established. ANCP messages other 620 than adjacency protocol messages may be sent only after the adjacency 621 protocol has achieved synchronization. 623 In the case of ATM access, a separate PVC (control channel) capable 624 of transporting IP would be configured between NAS and the DSLAM for 625 ANCP messages. 627 5.2 ANCP Connection keep-alive 629 GSMPv3 defines an adjacency protocol. The adjacency protocol is used 630 to synchronize states across the link, to negotiate which version of 631 the GSMP protocol to use, to discover the identity of the entity at 632 the other end of a link, and to detect when it changes. GSMP is a 633 hard state protocol. It is therefore important to detect loss of 634 contact between switch and controller, and to detect any change of 635 identity of switch or controller. No protocol messages other than 636 those of the adjacency protocol may be sent across the link until the 637 adjacency protocol has achieved synchronization. There are no changes 638 to the base GSMP adjacency protocol for implementing ANCP. 640 The NAS will set the M-flag in the SYN message (signifying it is the 641 master). Once the adjacency is established, periodic adjacency 642 messages (type ACK) are exchanged. The default ACK interval as 643 advertised in the adjacency messages is 10 sec for ANCP. It SHOULD be 644 configurable and is an implementation choice. It is recommended that 645 both ends specify the same timer value. However, it is not necessary 646 for the timer values to match. 648 The GSMP adjacency message defined in [4] is extended for ANCP and is 649 shown in section 5.3 immediately following this section. The 8-bit 650 �version� field in the adjacency protocol messages is modified to 651 carry the version and sub-version of the GSMP protocol for version 652 negotiation. ANCP uses version 3 and sub-version 1 of GSMP protocol. 653 The semantics and suggested values for Code, �Sender Name�, �Receiver 654 Name�, �Sender Instance�, and �Receiver Instance� fields are as 655 defined in [4]. The �Sender Port�, and �Receiver Port� should be set 656 to 0 by both ends. The pType field should be set to 0. The pFlag 657 should be set to 1. 659 If the adjacency times out on either end, due to not receiving an 660 adjacency message for a duration of (3 * Timer value), where the 661 timer value is specified in the adjacency message, all the state 662 received from the ANCP neighbor should be cleaned up, and the TCP 663 connection should be closed. The NAS would continue to listen for new 664 connection requests. The DSLAM will try to re-establish the TCP 665 connection and both sides will attempt to re-establish the adjacency. 667 The handling defined above will need some modifications when ANCP 668 graceful restart procedures are defined. These procedures will be 669 defined in a separate draft. 671 5.3 Capability negotiation 673 The adjacency message as defined in [4] is extended to carry 674 technology specific "Capability TLVs". Both the NAS and the access 675 node will advertise supported capabilities in the originated 676 adjacency messages. If a received adjacency message indicates absence 677 of support for a capability that is supported by the receiving 678 device, it will turn off the capability locally and will send an 679 updated adjacency message with the capability turned off to match the 680 received capability set. This process will eventually result in both 681 sides agreeing on the minimal set of supported capabilities. The 682 adjacency will not come up unless the capabilities advertised by the 683 controller and the controlled device match. 685 After initial synchronization, if at anytime a capability mismatch is 686 detected, the adjacency will be brought down (RSTACK will be 687 generated by the device detecting the mismatch), and synchronization 688 will be re-attempted. 690 0 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Ver | Sub | Message Type | Timer |M| Code | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Sender Name | 696 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | | | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 699 | Receiver Name | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Sender Port | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Receiver Port | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | PType | PFlag | Sender Instance | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | Partition ID | Receiver Instance | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Tech Type | # of TLVs | Total Length | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | | 712 ~ Capability TLVs ~ 713 | | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 The format of capability TLV is: 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Capability Type | Capability Length | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | | 722 ~ ~ 723 ~ Capability Data ~ 724 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 The Tech Type field type indicates the technology to which the 727 capability extension applies. For access node control in case of DSL 728 networks, new type "DSL" is proposed. The value for this field is 729 0x05. This is the first available value in the range that is not 730 currently allocated. It will need to be reserved with IANA. 732 Capability length is the number of actual bytes contained in the 733 value portion of the TLV. The TLV is padded to a 4-octet alignment. 734 Therefore, a TLV with no data will contain a zero in the length field 735 (if capability data is three octets, the length field will contain a 736 three, but the size of the actual TLV is eight octets). 738 Capability data field can be empty if the capability is just a 739 boolean. In case the capability is a boolean, it is inferred from the 740 presence of the TLV (with no data). Capability data provides the 741 flexibility to advertise more than mere presence or absence of a 742 capability. Capability types can be registered with IANA. Following 743 capabilities are defined for ANCP as applied to DSL access: 745 1. Capability Type : Dynamic-Topology-Discovery = 0x01 747 Length (in bytes) : 0 749 Capability Data : NULL 751 2. Capability Type : Line-Configuration = 0x02 753 Length (in bytes) : 0 755 Capability Data : NULL 757 3. Capability Type : Transactional-Multicast = 0x03 (controller 758 i.e. NAS terminates IGMP messages from subscribers, and via l2 759 control protocol, signals state to the access-nodes (e.g. 761 DSLAMs) to enable layer2 replication of multicast streams. In 762 ATM access network this implies that NAS instructs the access- 763 node to setup a P2MP cross-connect. The details of this will be 764 covered in a separate ID [6]. 766 Length (in bytes) : 0 768 Capability Data : NULL 770 4. Capability Type : OAM = 0x04 772 Length (in bytes) : 0 774 Capability Data : NULL 776 5. Capability Type : Bulk Transaction = 0x05 (defined in section 777 5.4.1.2). 779 Length (in bytes) : 0 781 Capability Data : NULL 783 5.4 GSMP Message Extensions for Access Node Control 785 5.4.1 General Extensions 787 Extensions to GSMP messages for various use-cases of �Acess Node 788 Control� mechanism are defined in sections 5.4.2 to 5.4.4. However, 789 sub-sections 5.4.1.1 and 5.4.1.2 below define extensions to GSMP that 790 have general applicability. 792 5.4.1.1 Extension TLV 794 In order to provide flexibility and extensibility certain GSMP 795 messages such as �PORT MANAGEMENT� and �EVENT� messages defined in 796 [4] have been modified to include an extension block that follows a 797 TLV structure. Individual messages in the following sections describe 798 the usage and format of the extension block. 800 All Extension TLV's will be designated as follow: 802 0 1 2 3 803 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 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | | 808 ~ Extension Value ~ 809 | | 810 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 812 x: Reserved Flags 814 These are generally used by specific messages and will be 815 defined in those messages. 817 Message Type 819 An 8-bit field corresponding to the message type where the 820 extension block is used. 822 Tech Type 824 An 8-bit field indicating the applicable technology type value. 825 The Message Type plus the Tech Value uniquely define a single 826 Extension Type and can be treated as a single 16 bit extension 827 type. �Tech Type� value of 0x05 SHOULD be used by ANCP for DSL 828 technology. 830 0x00 Extension block not it use. 832 0x01 � 0x04 Already in use by various technologies 834 0x05 DSL 836 0x06 - 0xFE Reserved 838 0xFF Base Specification Use 840 Block Length 841 A 8-bit field indicating the length of the Extension Value 842 field in bytes. When the Tech Type = 0x00, the length value 843 MUST be set to 0. 845 Extension Value 847 A variable length field that is an integer number of 32 bit 848 words long. The Extension Value field is interpreted according 849 to the specific definitions provided by the messages in the 850 following sections. 852 5.4.1.2 Bulk Transaction Message 854 ANCP elements MAY support a bulk transaction capability. This 855 capability is negotiated during adjacency synchronization and follows 856 general ANCP capability negotiation rules. 858 In a bulk transaction, several messages can be bundled together in a 859 single transaction. Bulk transaction uses message type 13. Reception 860 of �Bulk Transaction Message� by a node that has not advertised bulk 861 transaction capability MUST silently discard the received message. 863 The Bulk Transaction message has the following format: 865 0 1 2 3 866 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 867 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 868 | Vers | Sub | Message Type | Result| Code | 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Partition ID | Transaction Identifier | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 |I| SubMessage Number | Length | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Reserved | Count | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | | 877 ~ Message Payload ~ 878 | | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 In a Bulk Transaction Message, each of the message in the payload is 882 framed with a complete header and is acted on individually. The 883 response to the Bulk Transaction message contains the response 884 message that would have been generated by each of the messages had it 885 been sent individually. Each response message will have the 886 appropriate result and code field filled. Any message can be included 887 in the bulk Transaction message except for adjacency message and 888 another bulk transaction message. If a prohibited message is included 889 in a bulk Transaction message, it MUST be included in the Bulk 890 response with a failure response. The response code for that failure 891 is 0x81 (�Message type prohibited in bulk Transaction�). While the 892 individual message would fail, this would not constitute a failure 893 for the Bulk Transaction message 895 5.4.2 Topology Discovery Extensions 897 The GSMP Event message with PORT UP message type (80) is used for 898 conveying DSL line attributes to the NAS. The version field should be 899 set to 3, and the sub field should be set to 1. The I and subMessage 900 fields SHOULD be set to 1 to signify no fragmentation. The Port and 901 Label fields should be set to 0. The �Port Session Number� should be set 902 to 0, and the �Event Sequence Number� should be 0. The Tech Type field 903 is extended with new type "DSL". The value for this field is 0x05. The 904 message SHOULD be generated when a line first comes UP, or any of the 905 attributes of the line change e.g. the line re-trains to a different 906 rate or one or more of the configured line attributes are 907 administratively modified. Also, when the ANCP session first comes up, 908 the DSLSM SHOULD transmit a PORT UP message to the NAS for each line 909 that is up. A DSLAM MAY use a Bulk Transaction message as defined in 910 5.4.1.2 to aggregate the transmission of PORT UP messages. 912 When a DSL line goes down (idle or silent), the DSLAM SHOULD transmit an 913 Event message with PORT DOWN message type (81) to the NAS. It is 914 recommended that the DSLAMs use a dampening mechanism per DSL line to 915 control the rate of state changes per DSL line, communicated to the NAS. 917 0 1 2 3 918 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 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Vers | Sub | Message Type | Result| Code | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Partition ID | Transaction Identifier | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 |I| SubMessage Number | Length | 925 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 | Port | 927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 928 | Port Session Number | 929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 930 | Event Sequence Number | 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 |x|S|x|x| | 933 +-+-+-+-+ Label | 934 ~ ~ 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 936 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | | 939 ~ Extension Value ~ 940 | | 941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 943 The format of the "Extension Value" field for Tech Type �DSL� is 944 as follows : 946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 947 | # of TLVs | Extension block length (bytes)| 948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 949 | | 950 ~ ~ 951 ~ TLVs ~ 952 | | 953 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 955 The �Extension Value� contains one or more TLVs to identify a DSL line 956 and define it�s characteristics. A TLV can consist of multiple sub-TLVs. 957 First 2 byte of the �Extension Value� contains the number of TLVs that 958 follow. The next 2 bytes contain the total length of the TLVs carried in 959 the extension block in bytes (existing �Block Length� field in the GSMP 960 message is limited to 255 bytes and is not sufficient). 962 General format of a TLV is : 964 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 965 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 966 | Type | Length | 967 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 968 | | 969 ~ ~ 970 ~ Value ~ 971 | | 972 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 The value field in each TLV is padded to a 4-octet alignment. The Length 975 field in each TLV contains the actual number of bytes in the TLV (not 976 including the padding if present). If a TLV is not understood by the 977 NAS, it is silently ignored. Currently defined types start from 0x01. 979 Following TLVs are currently defined: 981 1. Type (Access-Loop-Circuit-ID = 0x01): This is a mandatory TLV and 982 contains an identifier of the subscriber�s connection to the access 983 node (i.e. �local loop�). The �local loop� can be ATM based or 984 Ethernet based. The �Access Loop Circuit ID� has local significance 985 at the access node. The exact usage on the NAS is beyond the scope 986 of this document. The format used for �local loop� identification 987 in ANCP messages MUST be identical to what is used by the access 988 nodes in subscriber signaling messages when the access nodes act as 989 �signaling relay agents� as outlined in [6] and [7]. 991 Length : (upto 63 bytes) 993 Value : ASCII string. 995 For an ATM based local loop the string consists of slot/port and 996 VPI/VCI information corresponding to the subscriber�s DSL 997 connection. Default syntax for the string inserted by the access 998 node as per [7] is: 1000 �Access-Node-Identifier atm slot/port:vpi.vci� 1002 The Access-Node-Identifier uniquely identifies the access node in 1003 the access network. The slot/port and VPI/VCI uniquely identifies 1004 the DSL line on the access node. Also, there is one to one 1005 correspondence between DSL line and the VC between the access node 1006 and the NAS. 1008 For local loop which is Ethernet based (and tagged), the string 1009 consists of slot/port and VLAN tag corresponding to the 1010 subscriber. Default syntax for the string inserted by the access 1011 node as per [7] is: 1013 "Access-Node-Identifier eth slot/port[:vlan-id]" 1015 2. Type (Access-Loop-Remote-Id = 0x02): This is an optional TLV and 1016 contains an identifier to uniquely identify a user on a local loop 1017 on the access node. The exact usage on the NAS is out of scope of 1018 this document. It is desirable that the format used for the field 1019 is similar to what is used by the access nodes in subscriber 1020 signaling messages when the access nodes act as �signaling relay 1021 agents� as outlined in [6] and [7]. 1023 Length : (upto 63 bytes) 1025 Value : ASCII string 1027 3. Type (Access-Aggregation-Circuit-ID-Binary = 0x06) 1029 Length : (8 bytes) 1031 Value : two 32 bit integers. 1033 For ethernet access aggregation, where a per-subscriber (stacked) 1034 VLAN can be applied (1:1 model defined in [7]), the VLAN stack 1035 provides a convenient way to uniquely identify the DSL line. The 1036 outer VLAN is equivalent to virtual path between a DSLAM and the 1037 NAS and inner VLAN is equivalent to a virtual circuit on a per DSL 1038 line basis. In this scenario, any subscriber data received by the 1039 access node and transmitted out the uplink to the aggregation 1040 network will be tagged with the VLAN stack assigned by the access 1041 node 1043 This TLV can carry the VLAN tags assigned by the access node in the 1044 ANCP messages. The VLAN tags can uniquely identify the DSL line 1045 being referred to in the ANCP messages, assuming the VLAN tags are 1046 not in any way translated in the aggregation network and are unique 1047 across physical ports. Each 32 bit integer (least significant bits) 1048 contains a 12 bit VLAN identifier (which is part of the VLAN tag 1049 defined by IEEE 802.1Q). 1051 Also, in case of an ATM aggregation network, where the DSLAM is 1052 directly connected to the NAS (without an intermediate ATM switch), 1053 the two values can contain VPI and VCI on the DSLAM uplink (and can 1054 uniquely identify the DSL line on the DSLAM). 1056 This TLV is optional. 1058 4. Type (Access-Aggregation-Circuit-ID-ASCII = 0x03) 1060 Length : (upto 63 bytes) 1062 Value : ASCII string. 1064 This field contains information pertaining to an uplink on the 1065 access node. For Ethernet access aggregation, assuming the access 1066 node assigns VLAN tags (1:1 model), typical format for the string 1067 is: 1069 �Access-Node-Identifier eth slot/port [:inner-vlan-id][:outer-vlan-id]� 1071 The slot/port corresponds to the ethernet uplink on the access node 1072 towards the NAS. 1074 For an ATM aggregation network, typical format for the string is: 1076 �Access-Node-Identifier atm slot/port:vpi.vci� 1078 This TLV allows the NAS to associate the information contained in 1079 the ANCP messages to the DSL line on the access node. 1081 If the access node inserts this string in the ANCP messages, when 1082 referring to local loop characteristics (e.g. DSL line in case of a 1083 DSLAM), then it should be able to map the information contained in 1084 the string uniquely to the local loop (e.g. DSL line). 1086 On the NAS, the information contained in this string can be used to 1087 derive an �aggregation network� facing construct (e.g. an IP 1088 interface) corresponding to the local loop (e.g. DSL line). The 1089 association could be based on �local configuration� on the NAS. 1091 The access node can also convey to the NAS, the characteristics 1092 (e.g. bandwidth) of the uplink on the access node. This TLV then 1093 serves the purpose of uniquely identifying the uplink whose 1094 characteristics are being defined. A separate set of sub-TLVs will 1095 be defined for the uplink characteristics (TBD). 1097 This TLV is optional. 1099 5. Type (DSL Line Attributes = 0x04): 1101 Length : variable (up to 1024 bytes) 1103 Value : This consists of one or more Sub-TLVs corresponding to DSL 1104 line attributes. No sub-TLVs other than the �DSL type� and �DSL 1105 line state� SHOULD be included in a PORT DOWN message. 1107 The general format of the sub-TLVs is identical to the general TLV 1108 format. The value field in each sub-TLV is padded to a 4-octet 1109 alignment. The Length field in each sub-TLV contains the actual 1110 number of bytes in the TLV (not including the padding if present). 1111 Current defined sub-TLV types are start from 0x81. 1113 Following sub-TLVs are currently defined : 1115 . Type (DSL-Type = 0x91) : Defines the type of transmission system 1116 in use. This is a mandatory TLV. 1118 Length : (4 bytes) 1120 Value : (Transmission system : ADSL1 = 0x01, ADSL2 = 0x02, 1121 ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL = 0x06, UNKNOWN 1122 = 0x07). 1124 . Type (Actual-Data-Rate-Upstream = 0x81) : Actual data rate 1125 upstream of a synchronized DSL line. This is a mandatory TLV. 1126 This rate value and all the subsequent ones account for the DSL 1127 overhead (i.e. signify the net rate). 1129 Length : (4 bytes) 1131 Value : (Rate in Kb/sec) 1133 . Type (Actual-Data-Rate-Downstream = 0x82) : Actual data rate 1134 downstream of a synchronized DSL line. This is a mandatory TLV. 1136 Length : (4 bytes) 1137 Value : (Rate in Kb/sec) 1139 . Type (Minimum-Data-Rate-Upstream = 0x83) : Minimum data rate 1140 desired by the operator. This is optional. 1142 Length : (4 bytes) 1144 Value : (Rate in Kb/sec) 1146 . Type (Minimum-Data-Rate-Downstream = 0x84) : Minimum data rate 1147 desired by the operator. This is optional. 1149 Length : (4 bytes) 1151 Value : (Rate in Kb/sec) 1153 . Type (Attainable-Data-Rate-Upstream = 0x85) : Maximum upstream 1154 rate that can be attained on the DSL line. This is an optional 1155 TLV. 1157 Length : (4 bytes) 1159 Value : (Rate in Kb/sec) 1161 . Type (Attainable-Data-Rate-Downstream = 0x86) : Maximum 1162 downstream rate that can be attained on the DSL line. This is 1163 an optional TLV. 1165 Length : (4 bytes) 1167 Value : (Rate in Kb/sec) 1169 . Type (Maximum-Data-Rate-Upstream = 0x87) : Maximum data rate 1170 desired by the operator. This is optional. 1172 Length : (4 bytes) 1174 Value : (Rate in Kb/sec) 1176 . Type (Maximum-Data-Rate-Downstream = 0x88) : Maximum data rate 1177 desired by the operator. This is optional. 1179 Length : (4 bytes) 1181 Value : (Rate in Kb/sec) 1183 . Type (Minimum-Low-Power-Data-Rate-Upstream = 0x89) : Minimum 1184 data rate desired by the operator in low power state. This is 1185 optional. 1187 Length : (4 bytes) 1189 Value : (Rate in Kb/sec) 1191 . Type (Minimum-Low-Power-Data-Rate-Downstream = 0x8A) : Minimum 1192 data rate desired by the operator in low power state. This is 1193 optional. 1195 Length : (4 bytes) 1197 Value : (Rate in Kb/sec) 1199 . Type (Maximum-Interleaving-Delay-Upstream = 0x8B) : maximum one 1200 way interleaving delay. This is optional. 1202 Length : (4 bytes) 1204 Value : (Time in msec) 1206 . Type (Actual-Interleaving-Delay-Upstream = 0x8C) : Value 1207 corresponding to the interleaver setting. This is optional. 1209 Length : (4 bytes) 1211 Value : (Time in msec) 1213 . Type (Maximum-Interleaving-Delay-Downstream = 0x8D) : maximum 1214 one way interleaving delay. This is optional. 1216 Length : (4 bytes) 1218 Value : (Time in msec) 1220 . Type (Actual-Interleaving-Delay-Downstream = 0x8E) : Value 1221 corresponding to the interleaver setting. This is optional. 1223 Length : (4 bytes) 1225 Value : (Time in msec) 1227 . Type (DSL line state = 0x8F) : The state of the DSL line. For 1228 PORT UP message, at this time, the TLV is optional (since the 1229 message type implicitly conveys the state of the line). For PORT 1230 DOWN, the TLV is mandatory, since it further communicates the 1231 state of the line as IDLE or SILENT. 1233 Length : (4 bytes) 1235 Value : { SHOWTIME = 0x01, IDLE = 0x02, SILENT = 0x03 } 1237 . Type (Access Loop Encapsulation = 0x90) : The data link protocol 1238 and, optionally the encapsulation overhead on the access loop. 1239 This is an optional TLV. However, when this TLV is present, the 1240 data link protocol MUST minimally be indicated. The 1241 encapsulation overhead can be optionally indicated. 1243 Length : (3 bytes) 1245 Value : The three bytes (most to least significant) and valid 1246 set of values for each byte are defined below. 1248 Data Link (1 byte): {ATM AAL5 = 0, 1250 ETHERNET = 1} 1252 Encaps 1 (1 byte): {NA = 0, 1254 Untagged Ethernet = 1, 1256 Single-tagged Ethernet = 2} 1258 Encaps 2 (1 byte):{ NA = 0, 1260 PPPoA LLC = 1, 1262 PPPoA NULL = 2, 1264 IPoA LLC = 3, 1266 IPoA NuLL = 4, 1268 Ethernet over AAL5 LLC with FCS = 5, 1270 Ethernet over AAL5 LLC without FCS = 6, 1272 Ethernet over AAL5 NULL with FCS = 7, 1273 Ethernet over AAL5 NULL without FCS = 8} 1275 If this TLV is present, the Data Link protocol MUST be indicated as 1276 defined above. However, the Access Node can choose to not convey the 1277 encapsulation on the access loop by specifying a value of 0 (NA) for the 1278 two encapsulation fields. 1280 5.4.3 Line Configuration Extensions 1282 The NAS uses extension block in the Port Management messages to convey 1283 service attributes of the DSL lines to the DSLAM. TLVs are defined for 1284 DSL line identification and service data for the DSL lines. Port number 1285 is set to 0 in the message. A new action type "Configure Connection 1286 Service Data" (value 0x8) is defined. The "Function" field is set to the 1287 action type. This action type indicates to the device being controlled 1288 (access-node i.e. DSLAM) to apply service configuration data contained 1289 in the extension value (TLVs), to the DSL line (identified by one of the 1290 TLVs in the extension value). The Tech Type field is extended with new 1291 type "DSL". The value for this field is 0x05. 1293 0 1 2 3 1294 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 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 | Vers | Sub | Message Type | Result| Code | 1297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1298 | Partition ID | Transaction Identifier | 1299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1300 |I| SubMessage Number | Length | 1301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1302 | Port | 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Port Session Number | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Event Sequence Number | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 |R|x|x|x|x|x|x|x| Duration | Function | X-Function | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 | Event Flags | Flow Control Flags | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 |x|x|x|x|x|x|x|x| Message Type | Tech Type | Block Length | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | | 1315 ~ Extension Value ~ 1316 | | 1317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1318 The format of the "Extension Value" field is as follows: 1320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 | # of TLVs | Extension Block length (bytes)| 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 | | 1324 ~ ~ 1325 ~ TLVs ~ 1326 | | 1327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 The �Extension Value� field contains one or more TLVs containing DSL 1330 line identifier and desired service attributes of the the DSL line. 1331 First 2 byte of the �Extension Value� contains the number of TLVs 1332 that follow. The next 2 bytes contain the total length of the 1333 extension block in bytes (existing �Block Length� field in the GSMP 1334 message is limited to 255 bytes and is not sufficient). 1336 General format of a TLV is: 1338 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 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | Type | Length | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | | 1343 ~ ~ 1344 ~ Value ~ 1345 | | 1346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 The value field is padded to a 4-octet alignment. The Length field in 1349 each TLV contains the actual number of bytes in the TLV (not 1350 including the padding if present). If a TLV is not understood by the 1351 access-node, it is silently ignored. Depending upon the deployment 1352 scenario, the NAS may specify �Access Loop Circuit-ID� or the �Access 1353 Aggregation Circuit-ID) as defined in section 5.4.1. Following TLVs 1354 can appear in this message: 1356 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 1357 o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in 1358 section 5.4.1. 1360 o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in section 1361 5.4.1. 1363 o Type (Service-Profile-Name = 0x05): Reference to a pre-configured 1364 profile on the DSLAM that contains service specific data for the 1365 subscriber. 1367 Length : (upto 64 bytes) 1369 Value : ASCII string containing the profile name (NAS learns 1370 from a policy server after a subscriber is authorized). 1372 In future, more TLVs MAY be defined for individual service attributes 1373 of a DSL line (e.g. rates, interleaving delay, multicast channel 1374 entitlement access-list etc). 1376 5.4.4 OAM Extensions 1378 GSMP �Port Management� message (type 32) SHOULD be used by the NAS to 1379 trigger access node to run a loopback test on the local loop. The 1380 message format is defined in section 5.4.2. The version field SHOULD 1381 be set to 3 and sub-version field SHOULD be set to 1. The remaining 1382 fields in the GSMP header have standard semantics. The function type 1383 used in the request message SHOULD be set to �remote loopback� (type 1384 = 0x09). The port, �port session number�, �event sequence number�, 1385 duration, �event flags�, �flow control flags� and code fields SHOULD 1386 all be set to 0. The result field SHOULD be set to �AckAll� to 1387 indicate requirement for the access node to send a success for 1388 failure response. The transaction ID SHOULD contain a sequence number 1389 inserted by the NAS in each request that it generates. The extension 1390 field format is also defined above in section 5.4.2. The extension 1391 value field can contain one or more TLVs including the access-line 1392 identifier on the DSLAM and OAM test characteristics desired by the 1393 NAS. 1395 The TLV format is defined above in section 5.4.2. The value field is 1396 padded to a 4-octet alignment. The Length field in each TLV contains 1397 the actual number of bytes in the TLV (not including the padding if 1398 present). If a TLV is not understood by the NAS, it is silently 1399 ignored. Depending upon the deployment scenario, the NAS may specify 1400 �Access Loop Circuit-ID� or the �Access Aggregation Circuit-ID) as 1401 defined in section 5.4.1. Following TLVs can appear in this message: 1403 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 1405 o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in 1406 section 5.4.1. 1408 o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in section 1409 5.4.1. 1411 o Type (OAM-Loopback-Test-Parameters = 0x07): Parameters related to 1412 loopback test. This is an optional TLV. If this TLV is not present 1413 in the request message, the DSLAM SHOULD use locally determined 1414 default values for the test parameters. 1416 Length: 4 bytes 1418 Value : two 1 byte numbers described below (listed in order of 1419 most to least significant). Thus, the 4 bytes consist of 1 byte 1420 of Count, followed by 1 byte of Timeout, followed by two pad bytes 1421 of zero. 1423 o Count (1 byte) : Number of loopback cells/messages that should 1424 be generated on the local loop as part of the loopback test. 1425 The NAS SHOULD restrict the �count� to be greater than 0 and 1426 less than or equal to 32. The DSLAM SHOULD discard the request 1427 for a loopback test, if the received test parameters contain an 1428 out of range value for the �count� field. The DSLAM MAY 1429 optionally send a failure response to the NAS with the code 1430 �invalid test parameter�. 1432 o Timeout (1 byte) : Upper bound on the time in seconds that the 1433 NAS would wait for a response from the DSLAM. If the total time 1434 taken by the DSLAM to complete a test with requested 1435 parameters, exceeds the specified �timeout� value, it can 1436 choose to omit the generation of a response to the NAS. DSLAM 1437 SHOULD use a locally determined value for the �timeout�, if the 1438 received value of the �timeout� parameter is 0. 1440 o Type (Opaque-Data = 0x08) : This is an optional TLV. If present in 1441 the request message, the DSLAM SHOULD reflect it back in the 1442 response unmodified. 1444 Length : 8 bytes 1446 Value : Two 32 bit integers inserted by the NAS (not to be 1447 interpreted by the DSLAM, but just reflected back in the 1448 response). 1450 The access node generates a success or failure response when it deems 1451 the loopback test to be complete. �Port Management� message (type 32) 1452 is used. The result field SHOULD be set to success or failure. The 1453 function type SHOULD be set to 0x09. The transaction ID SHOULD be 1454 copied from the sequence number contained in the corresponding 1455 request. The other parameters not explicitly defined here SHOULD be 1456 set as specified in the request message above. The code field SHOULD 1457 be set to a value in the range 0x500 to 0x5ff (to be reserved with 1458 IANA) to indicate the status of the executed test. The valid values 1459 defined are (can be extended in future): 1461 0x500 : Specified access line does not exist. 1463 0x501 : Loopback test timed out. 1465 0x502 : Reserved 1467 0x503 : DSL line status showtime. 1469 0x504 : DSL line status idle. 1471 0x505 : DSL line status silent. 1473 0x506 : DSL line status training. 1475 0x507 : DSL line integrity error. 1477 0x508 : DSLAM resource not available. 1479 0x509 : Invalid test parameter. 1481 The Extension value can contain one or more TLVs including the TLV to 1482 identify the access line on which the test was performed, and details 1483 from executing the test. The access line identifier SHOULD be identical 1484 to what was contained in the request. The relevant TLVs are: 1486 o Type (Access-Loop-Circuit-ID = 0x01) : defined in section 5.4.1 1488 o Type (Access-Aggregation-Circuit-ID-Binary = 0x06): defined in 1489 section 5.4.1. 1491 o Type (Access-Aggregation-Circuit-ID-ASCII = 0x03): defined in section 1492 5.4.1. 1494 o Type (Opaque-Data = 0x08) : Data inserted by the NAS in the request 1495 reflected back by the DSLAM. 1497 Length : 8 bytes 1499 Value : Two 32 bit integers as received in the request (opaque to 1500 the DSLAM). 1502 o Type (OAM-Loopback-Test-Response-String = 0x09) 1504 Length (upto 128 bytes) 1506 Value : Suitably formatted ASCII string containing useful details 1507 about the test that the NAS will display for the operator, exactly 1508 as received from the DSLAM (no manipulation/interpretation by the 1509 NAS). This is an optional TLV, but it is strongly recommended, 1510 that in case of ATM based local loop, the DSLAM at the very least 1511 indicates via this TLV, the total loopback cells generated and the 1512 total loopback cells successfully received as part of executing 1513 the requested loopback test. 1515 5.5 ATM-specific considerations 1517 The topology discovery and line configuration involve the DSL line 1518 attributes. For ATM based access networks, the DSL line on the DSLAM 1519 is identified by the port and PVP/PVC corresponding to the 1520 subscriber. The DSLAMs are connected to the NAS via an ATM access 1521 aggregation network. Since, the DSLAM (access-node) is not directly 1522 connected to the NAS, the NAS needs a mechanism to learn the DSL line 1523 identifier (more generally referred to as "Access Loop Circuit-ID") 1524 corresponding to a subscriber. The "Access loop circuit-ID" has no 1525 local significance on the NAS. The ANCP messages for topology 1526 discovery and line configuration carry opaque "Access loop Circuit- 1527 ID" which has only local significance on the DSLAMs. 1529 The access loop circuit identifier can be carried as an ASCII string 1530 in the ANCP messages. This allows ANCP to be decoupled from the 1531 specifics of the underlying access technology being controlled. On 1532 the other hand, this requires a NAS mechanism by which such 1533 identifier can be correlated to the context of an �aggregation 1534 network� facing IP interface (corresponding to the subscriber) on the 1535 NAS. This would typically require local configuration of such IP 1536 interfaces, or of the underlying ATM interfaces. 1538 5.6 Ethernet-specific considerations 1540 One possible way of approaching the use of Ethernet technology in the 1541 access aggregation network is to recreate the equivalent of Virtual 1542 Paths (VPs) and Virtual Circuits (VCs) by using stacked Virtual LAN 1543 tags. As an example, one could use an �outer� VLAN to create a form of 1544 �virtual path� between a given DSLAM and a given NAS. And then use 1545 �inner� VLAN tags to create a form of �virtual circuit� on a per DSL 1546 line basis. In this case, VLAN tags conveyed in topology discovery and 1547 line configuration messages will allow to uniquely identify the DSL line 1548 in a straightforward manner, assuming the VLAN tags are not translated 1549 in some way by the aggregation network, and are unique across physical 1550 ports. 1552 However, some carriers do not wish to use this �connection oriented� 1553 approach. Therefore, an alternative model is to bridge sessions from 1554 multiple subscribers behind a DSLAM to a single VLAN in the aggregation 1555 network. This is the N:1 model. In this model, or in the case where user 1556 traffic is sent untagged, the access node needs to insert the exact 1557 identity of the DSL line in the topology discovery and line 1558 configuration messages, and then have a mechanism by which this can be 1559 correlated to the context of an �aggregation network� facing IP 1560 interface (for the subscriber) on the NAS. This can either be based on 1561 local configuration on the NAS, or on the fact that such DSLAM (access 1562 node) typically inserts the �Access Loop Circuit ID� in subscriber 1563 signaling messages relayed to the NAS (i.e. DHCP or PPPoE discovery 1564 messages). 1566 Section 5.4.1 defines �Access Loop Circuit ID�. 1568 6 IANA Considerations 1570 New Tech-Type, capability types, sub-TLV types related to topology 1571 discovery and line configuration will need to be reserved. 1573 7 Security Considerations 1575 The NAS and DSLAMs are implicitly in a trusted domain, so security 1576 for ANCP is not a strong requirement. However, if needed security can 1577 be provided using IP security as indicated in [RFC3293]. 1579 8 References 1581 [1] DSLForum TR-059, DSL Evolution - Architecture Requirements for 1582 the Support of QoS-Enabled IP Services, Tom Anschutz (BellSouth 1583 Telecommunications), 09/2003. 1585 [2] DSLForum TR-058, Multi-Service Architecture & Framework 1586 Requirements, Mark Elias (SBC) and Sven Ooghe (Alcatel), 1587 09/2003. 1589 [3] DSLForum TR-092, Broadband Remote access server requirements 1590 document. 1592 [4] Doria, A. et al, "General Switch Management Protocol- V3" (GSMP 1593 v3), RFC 3292, June 2002. 1595 [5] Worster, T., Doria, A. and J. Buerkle, "General Switch 1596 Management Protocol (GSMP) Packet Encapsulations for 1597 Asynchronous Transfer Mode (ATM), Ethernet and Transmission 1598 Control Protocol (TCP)", RFC 3293, June 2002. 1600 [6] �DHCP Relay Agent Information Option�, RFC 3046, January 2001. 1602 [7] Architecture & Transport: Migration to Ethernet Based DSL 1603 Aggregation, DSL Forum WT-101, Cohen et al. 1605 [8] Framework for Access Node Control Mechanism in Broadband 1606 Networks, draft-ietf-ancp-framework-00.txt. 1608 Author's Addresses 1610 Sanjay Wadhwa 1611 Juniper Networks 1612 10 Technology Park Drive 1613 Westford, MA 01886 1615 Email: swadhwa@juniper.net 1617 Jerome Moisand 1618 Juniper Networks 1619 10 Technology Park Drive 1620 Westford, MA 01886 1622 Email: jmoisand@juniper.net 1624 Swami Subramanian 1625 Juniper Networks 1626 10 Technology Park Drive 1627 Westford, MA 01886 1629 Email: ssubramanian@juniper.net 1631 Thomas Haag 1632 T-systems 1634 Email: thomas.haag@t-systems.com 1636 Norber Voigt 1637 Siemens 1639 Email: norbert.voigt@siemens.com 1641 Full Copyright Statement 1643 Copyright (C) The IETF Trust (2007). 1645 This document is subject to the rights, licenses and restrictions 1646 contained in BCP 78, and except as set forth therein, the authors 1647 retain all their rights. This document and the information contained 1648 herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE 1649 ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE 1650 INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK 1651 FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 1652 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 1653 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 1654 OR FITNESS FOR A PARTICULAR PURPOSE. 1656 Intellectual Property 1658 The IETF takes no position regarding the validity or scope of any 1659 Intellectual Property Rights or other rights that might be claimed to 1660 pertain to the implementation or use of the technology described in 1661 this document or the extent to which any license under such rights 1662 might or might not be available; nor does it represent that it has 1663 made any independent effort to identify any such rights. Information 1664 on the procedures with respect to rights in RFC documents can be 1665 found in BCP 78 and BCP 79. 1667 Copies of IPR disclosures made to the IETF Secretariat and any 1668 assurances of licenses to be made available, or the result of an 1669 attempt made to obtain a general license or permission for the use of 1670 such proprietary rights by implementers or users of this 1671 specification can be obtained from the IETF on-line IPR repository at 1672 http://www.ietf.org/ipr. 1674 The IETF invites any interested party to bring to its attention any 1675 copyrights, patents or patent applications, or other proprietary 1676 rights that may cover technology that may be required to implement 1677 this standard. Please address the information to the IETF at 1678 ietf-ipr@ietf.org 1680 Acknowledgment 1682 Thanks to Peter Arberg, Josef Froehler, Derek Harkness, Kim 1683 Hyldgaard, Sandy Ng, Robert Peschi, and Michel Platnic for their 1684 input to this document.