idnits 2.17.1 draft-mammoliti-l2tp-accessline-avp-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 23, 2009) is 5538 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-17) exists of draft-ietf-ancp-protocol-04 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force V. Mammoliti 3 Internet-Draft C. Pignataro 4 Intended status: Informational Cisco Systems 5 Expires: August 27, 2009 P. Arberg 6 Redback Networks 7 J. Gibbons 8 Juniper Networks 9 P. Howard 10 February 23, 2009 12 Layer 2 Tunneling Protocol (L2TP) Access Line Information 13 Attribute Value Pair (AVP) Extensions 14 draft-mammoliti-l2tp-accessline-avp-06 16 Status of this Memo 18 This Internet-Draft is submitted to IETF in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 27, 2009. 39 Copyright Notice 41 Copyright (c) 2009 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. 51 Abstract 53 This document describes a set of Layer 2 Tunneling Protocol (L2TP) 54 Attribute Value Pair (AVP) extensions designed to carry the 55 subscriber Access Line identification and characterization 56 information that arrives at the Broadband Remote Access Server (BRAS) 57 with L2TP Access Concentrator (LAC) functionality. It also describes 58 a mechanism to report connection speed changes, after the initial 59 connection speeds are sent during session establishment. The primary 60 purpose of this document is to provide a reference for DSL equipment 61 vendors wishing to interoperate with other vendors' products. The 62 L2TP AVPs defined in this document are applicable to both L2TPv2 and 63 L2TPv3. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 71 2.2. Technical Terms and Acronyms . . . . . . . . . . . . . . . 6 73 3. Access Line Information L2TP AVP Operation . . . . . . . . . . 7 75 4. Additional L2TP Messages . . . . . . . . . . . . . . . . . . . 8 76 4.1. Connect-Speed-Update-Notification (CSUN) . . . . . . . . . 9 77 4.2. Connect-Speed-Update-Request (CSURQ) . . . . . . . . . . . 10 79 5. Access Line Information L2TP Attribute Value Pair 80 Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 5.1. Access Line Agent-Circuit-Id AVP . . . . . . . . . . . . . 12 82 5.2. Access Line Agent-Remote-Id AVP . . . . . . . . . . . . . 13 83 5.3. Access Line Actual-Data-Rate-Upstream AVP . . . . . . . . 14 84 5.4. Access Line Actual-Data-Rate-Downstream AVP . . . . . . . 14 85 5.5. Access Line Minimum-Data-Rate-Upstream AVP . . . . . . . . 15 86 5.6. Access Line Minimum-Data-Rate-Downstream AVP . . . . . . . 15 87 5.7. Access Line Attainable-Data-Rate-Upstream AVP . . . . . . 16 88 5.8. Access Line Attainable-Data-Rate-Downstream AVP . . . . . 16 89 5.9. Access Line Maximum-Data-Rate-Upstream AVP . . . . . . . . 17 90 5.10. Access Line Maximum-Data-Rate-Downstream AVP . . . . . . . 17 91 5.11. Access Line Minimum-Data-Rate-Upstream-Low-Power AVP . . . 18 92 5.12. Access Line Minimum-Data-Rate-Downstream-Low-Power AVP . . 18 93 5.13. Access Line Maximum-Interleaving-Delay-Upstream AVP . . . 19 94 5.14. Access Line Actual-Interleaving-Delay-Upstream AVP . . . . 19 95 5.15. Access Line Maximum-Interleaving-Delay-Downstream AVP . . 20 96 5.16. Access Line Actual-Interleaving-Delay-Downstream AVP . . . 20 97 5.17. Access Line Access-Loop-Encapsulation AVP . . . . . . . . 21 98 5.18. ANCP Access Line Type AVP . . . . . . . . . . . . . . . . 22 99 5.19. Access Line IWF-Session AVP . . . . . . . . . . . . . . . 23 101 6. Connect Speed Update L2TP Attribute Value Pair Extensions . . 23 102 6.1. Connect Speed Update AVP (CSUN, CSURQ) . . . . . . . . . . 24 103 6.2. Connect Speed Update Enable AVP (ICRQ) . . . . . . . . . . 25 105 7. Access Line Information AVP Mapping . . . . . . . . . . . . . 25 106 7.1. Summary of Access Line AVPs . . . . . . . . . . . . . . . 25 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 109 8.1. Message Type AVP Values . . . . . . . . . . . . . . . . . 26 110 8.2. Control Message Attribute Value Pairs (AVPs) . . . . . . . 27 111 8.3. Values for Access Line Information AVPs . . . . . . . . . 27 113 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27 115 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 117 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 118 11.1. Normative References . . . . . . . . . . . . . . . . . . . 28 119 11.2. Informative References . . . . . . . . . . . . . . . . . . 28 121 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 123 1. Introduction 125 Access Nodes/Digital Subscriber Line Access Multiplexers (DSLAM) are 126 adding enhancement features to forward, via in-band signaling, 127 subscribers Access Line identification and characterization 128 information to their connected upstream Broadband Remote Access 129 Server (BRAS) with L2TP Access Concentrator (LAC) functionality. 131 The Access Node/DSLAM may forward the information via one or more of 132 the following methods: 134 o Vendor-Specific PPPoE Tags [RFC2516]. 136 o DHCP Relay Options [RFC3046] and Vendor-Specific Information 137 Suboptions [RFC4243]. 139 o ANCP [I-D.ietf-ancp-protocol]. 141 Currently this information is been collected on the BRAS and 142 forwarded to a radius server via [RFC4679]. 144 This document describes the new additional L2TP AVPs that were 145 created to forward the subscriber line identification and 146 characterization information received at the BRAS/LAC to the 147 terminating L2TP Network Server (LNS). It also describes a mechanism 148 by which the LAC may report connection speed changes to the LNS, 149 after the initial connection speeds are sent by the LAC during 150 session establishment. 152 The L2TP AVPs defined in this document MAY be used with either an 153 L2TPv2 [RFC2661] or L2TPv3 [RFC3931] implementation. 155 The information acquired may be used to provide authentication, 156 policy and accounting functionality. It may also be collected and 157 used for management and troubleshooting purposes. 159 2. Terminology 161 The following sections define the usage and meaning of certain 162 specialized terms in the context of this document. 164 2.1. Requirements Language 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [RFC2119]. 170 2.2. Technical Terms and Acronyms 172 Access Node/DSLAM 174 The Access Node/DSLAM is a DSL signal terminator that contains a 175 minimum of one Ethernet or ATM interface that serves as its 176 upstream interface into which it aggregates traffic from several 177 ATM-based (subscriber ports) or Ethernet-based downstream 178 interfaces. 180 BNG 182 Broadband Network Gateway. A BNG is an IP edge router where 183 bandwidth and QoS policies are applied; the functions performed by 184 a BRAS are a superset of those performed by a BNG. 186 BRAS 188 Broadband Remote Access Server. A BRAS is a BNG and is the 189 aggregation point for the subscriber traffic. It provides 190 aggregation capabilities (e.g., IP, PPP, Ethernet) between the 191 access network and the core network. Beyond its aggregation 192 function, the BRAS is also an injection point for policy 193 management and IP QoS in the access network. 195 DSL 197 Digital Subscriber Line. DSL is a technology that allows digital 198 data transmission over wires in the local telephone network. 200 DSLAM 202 Digital Subscriber Line Access Multiplexer. DSLAM is a device 203 that terminates DSL subscriber lines. The data is aggregated and 204 forwarded to ATM- or Ethernet-based aggregation networks. 206 IWF 208 Interworking Function. The set of functions required for 209 interconnecting two networks of different technologies (e.g., ATM 210 and Ethernet). IWF is utilized to enable the carriage of PPPoA 211 traffic over PPPoE. 213 LAC 215 L2TP Access Concentrator. If an L2TP Control Connection Endpoint 216 (LCCE) is being used to cross-connect an L2TP session directly to 217 a data link, we refer to it as an L2TP Access Concentrator (LAC). 219 (See [RFC2661] and [RFC3931].) 221 LCCE 223 L2TP Control Connection Endpoint. An L2TP node that exists at 224 either end of an L2TP control connection. May also be referred to 225 as an LAC or LNS, depending on whether tunneled frames are 226 processed at the data link (LAC) or network layer (LNS). (See 227 [RFC3931].) 229 LNS 231 L2TP Network Server. If a given L2TP session is terminated at the 232 L2TP node and the encapsulated network layer (L3) packet processed 233 on a virtual interface, we refer to this L2TP node as an L2TP 234 Network Server (LNS). (See [RFC2661] and [RFC3931].) 236 3. Access Line Information L2TP AVP Operation 238 When the BRAS with LAC functionality receives the Access Line 239 information from the Access Node and has determined that the session 240 will be established with an LNS, the LAC will forward the information 241 that it has collected in the newly defined L2TP AVPs. The LAC will 242 only forward the Access Line information AVPs that have populated 243 values. 245 Access Line information from any of the above methods must be 246 available at the BRAS prior to the start of session negotiation by 247 the LAC. This ensures Access Line parameters are reliably provided 248 to the LNS and avoids additional call set-up delays. Under the 249 condition that the LAC has not received any Access Line information 250 from any of the methods, as default behavior the LAC SHOULD establish 251 the L2TP session without waiting for the Access Line Information. In 252 this case, the LAC MUST NOT send any of the Access Line AVPs to the 253 LNS. The LAC MAY, as local policy, wait for the Access Line 254 information from one or more of the methods before forwarding the 255 information in the Access Line L2TP AVPs to the LNS. 257 It is possible that the Access Node will only send a subset of the 258 currently available line information defined. The LAC MUST be able 259 to limit and/or filter which AVPs, if any, are sent to the LNS. 261 It is also possible that the LAC may receive Access Line information 262 from multiple sources and at different time intervals. Local policy 263 SHOULD determine which source(s) the LAC will accept. The LAC SHOULD 264 default to accepting ANCP sourced parameters. 266 The Access Line AVPs are sent as part of the L2TP Incoming-Call- 267 Request (ICRQ) control message. Connect Speed Update AVPs are sent 268 as part of the Connect-Speed-Update-Notification (CSUN) or Connect- 269 Speed-Update-Request (CSURQ) L2TP messages (see Sections 4, 4.1, and 270 4.2). 272 It is possible for the LAC to send updated Connect Speed 273 characteristics to the LNS via the Connect Speed Update AVP in an 274 L2TP Connect-Speed-Update-Notification (CSUN) control message (see 275 Section 4.1). To avoid unnecessary L2TP Connect-Speed-Update-Request 276 and Connect-Speed-Update-Notification message exchanges between the 277 LAC and LNS (e.g., during failover protocol recovery and 278 resynchronization), the LAC signals in the session establishment 279 exchange its ability and desire to provide speed updates during the 280 life of the session. This is achieved using a new AVP, Connect Speed 281 Update Enable (see Section 6.2), sent in the L2TP Incoming-Call- 282 Request (ICRQ) control message. The absence of this AVP in the ICRQ 283 message implies that the LAC will not be sending any speed updates 284 during the life of the session. If the LAC is configured to accept 285 ANCP-sourced parameters, and supports providing speed updates during 286 the life of a session, it MUST send the Connect Speed Update Enable 287 AVP in the ICRQ, since this implies that speed updates may occur over 288 the life of the connection. If the LAC is configured to only accept 289 PPPoE vendor-specific tags, it MUST NOT send the Connect Speed Update 290 Enable AVP in the ICRQ, since the connection speed is only sent 291 during PPPoE discovery and no further updates will occur during the 292 life of the connection. 294 4. Additional L2TP Messages 296 If the Access Line information changes while the session is still 297 maintained, connection speed updates MAY be sent from the LAC to the 298 LNS via an L2TP Connect-Speed-Update-Notification (CSUN) Message (see 299 Section 4.1). A new AVP, Connect Speed Update AVP (see Section 6.1), 300 is included in the CSUN message to report connect speed updates for a 301 specific session after the initial connection speeds are established 302 (i.e., at session establishment via the Tx Connect Speed and Rx 303 Connect Speed AVPs, Attribute Types 24 and 38 respectively for L2TPv2 304 and 74 and 75 respectively for L2TPv3). The values established in 305 the Connect Speed Update AVP (as well as the values for the initial 306 Tx/Rx Connect Speeds AVPs) are based on LAC local policy. For 307 example, the LAC's local policy may use the Actual-Data-Rate-Upstream 308 and Actual-Data-Rate-Downstream as its policy to report connection 309 speed updates. For consistency, the same local policy SHOULD equally 310 apply both to the initial connect speeds (conveyed during session 311 establishment) and to the (optional) connect speed updates (sent 312 after the establishment of the session). The CSUN message MAY be 313 sent periodically to the LNS based on local policy and may include 314 more than one Connect Speed Update AVP. The bulking of more than one 315 Connect Speed Update AVP into the CSUN message serves the following 316 purposes: 318 o Dampen the rate of changes sent to the LNS when Access Line 319 parameter updates are received at a high rate for a given line. 321 o Efficiently forward speed updates when Access Line parameter 322 updates are received for many lines at the same time. 324 o Address failover [RFC4951] protocol recovery and 325 resynchronization. 327 During failover recovery and resynchronization, to ensure the correct 328 speeds have been applied to outstanding sessions on each tunnel, the 329 LNS MAY issue a Connect-Speed-Update-Request (CSURQ) message (see 330 Section 4.2) to the LAC containing one or more Session IDs. In 331 response to the CSURQ message, the LAC MUST issue a Connect-Speed- 332 Update-Notification (CSUN) message (see Section 4.1) containing a 333 Connect Speed Update AVP for each of the Session IDs requested in the 334 CSURQ. Note: In the CSUN response to the CSURQ, the LAC MUST NOT 335 respond to unknown sessions, or to known sessions for which it did 336 not issue a Connect Speed Update Enable AVP in the prior Incoming- 337 Call-Request (ICRQ) control message for the session (see Sections 3 338 and 6.2). 340 This section defines two new Messages that are used with the IETF 341 Vendor ID of 0 in the Message Type AVP. 343 The following message types will be assigned to these new messages 344 (see Section 8.1): 346 MSG-TBD1: (CSUN) Connect-Speed-Update-Notification 348 MSG-TBD2: (CSURQ) Connect-Speed-Update-Request 350 The Mandatory (M) bit within the Message Type AVP SHOULD be clear 351 (i.e., not set) for the CSUN and CSURQ control messages, to allow for 352 an L2TP Control Connection Endpoint (LCCE) to maintain the control 353 connection if the message type is unknown. 355 4.1. Connect-Speed-Update-Notification (CSUN) 357 The Connect-Speed-Update-Notification (CSUN) is an L2TP control 358 message sent by the LAC to the LNS to provide transmit and receive 359 connection speed update for one or more sessions. The connection 360 speed may change at any time during the life of the call, thus the 361 LNS SHOULD be able to update its connection speed on an active 362 session. 364 The following AVPs MUST be present in the CSUN: 366 Message Type 368 Connect Speed Update (more than one may be present in the CSUN) 370 Note that the LAC MUST NOT include a Connect Speed Update AVP for 371 which it did not send a Connect Speed Update Enable AVP in the prior 372 Incoming-Call-Request (ICRQ) control message for the session. 374 4.2. Connect-Speed-Update-Request (CSURQ) 376 The Connect-Speed-Update-Request (CSURQ) is an L2TP control message 377 sent by the LNS to the LAC to request the current transmit and 378 receive connection speed for one or more sessions. It MAY be issued 379 at any time during the life of the tunnel and MUST only be issued for 380 each outstanding session on each tunnel on which the LNS has already 381 received a Connect Speed Update Enable AVP in the prior Incoming- 382 Call-Request (ICRQ) control message for the session. It is typically 383 used as part of failover recovery and re-synchronization to allow the 384 LNS to verify it has the correct speeds for each outstanding session 385 on each tunnel. 387 The following AVPs MUST be present in the CSURQ: 389 Message Type 391 Connect Speed Update (more than one may be present in the CSURQ) 393 The Current Tx Connect Speed and Current Rx Connect Speed fields in 394 the Connect Speed Update AVP MUST be set to 0 when this AVP is used 395 in the CSURQ message. 397 In the CSUN response to the CSURQ, the LAC MUST NOT respond to 398 unknown sessions, or to known sessions for which it did not issue a 399 Connect Speed Update Enable AVP in the prior Incoming-Call-Request 400 (ICRQ) control message for the session. 402 5. Access Line Information L2TP Attribute Value Pair Extensions 404 The Access Line Information was initially defined in the DSL Forum 405 Technical Report TR-101 [TR-101]. TR-101 defines the line 406 characteristic that are sent from an Access Node. 408 The following sections contain a list of the Access Line Information 409 L2TP AVPs. Included with each of the listed AVPs is a short 410 description of the purpose of the AVPs. 412 The AVPs follow the standard method of encoding AVPs as follows: 414 0 1 2 3 415 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 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 |M|H| rsvd | Length | Vendor ID | 418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 419 | Attribute Type |Attribute Value, if Required ... 420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 ... (Until Length is reached) | 422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 The M bit for all the AVPs defined in this document SHOULD be set to 425 0, to allow for backwards compatibility with LNS that do not support 426 the Access Line Information AVP extensions hereby defined. However, 427 if it is desired to prevent the establishment of the L2TP session if 428 the peer LNS does not support the Access Line Information AVP 429 extensions, the M bit MAY be set to 1. See Section 4.2 of [RFC2661] 430 and Section 5.2 of [RFC3931]. 432 All the AVPs defined in this document MAY be hidden (the H bit MAY be 433 0 or 1). 435 The Length (before hiding) of all the listed AVPs is 6 plus the 436 length of the Attribute Value, if one is required, in octets. 438 The Vendor ID for all the listed AVP (Section 5.1 through 439 Section 5.19) is that of the IANA assigned ADSL Forum Vendor ID, 440 decimal 3561 [IANA.enterprise-numbers]. 442 All the listed AVPs (Section 5.1 through Section 5.19) MAY be present 443 in the following messages unless otherwise stipulated: 445 Incoming-Call-Request (ICRQ) 447 The Value of the AVP contains information about the Access line to 448 which the subscriber is attached. 450 With exception of the Connect Speed Update AVP (see Section 6.1), all 451 new AVPs specifying a data rate or speed expressed in bits per second 452 (bps) will be sent as 64-bits to provide extensibility to support 453 future increases in subscriber connection speeds. These new AVPs 454 that specify a 64-bit "Data-Rate" are defined from Section 5.3 to 455 Section 5.12, both inclusive. Whenever a speed value sent in an AVP 456 fits within 32 bits, the upper 32 bits MUST be transmitted as 0s. 458 The various Data-Rates and Interleaving-Delays used in the subsequent 459 Sections 5.3 through 5.16 are defined in Section 3.9.4 of [TR-101]. 460 The qualifiers used with these Data-Rates and Interleaving-Delays 461 have the following meanings: 463 o Actual Actual rate or delay of an access loop 465 o Attainable Maximum value that can be achieved by the equipment 467 o Minimum Minimum value configured by the operator 469 o Maximum Maximum value configured by the operator 471 5.1. Access Line Agent-Circuit-Id AVP 473 The Access Line Agent-Circuit-Id AVP, Attribute Type 1, contains 474 information describing the subscriber agent circuit ID corresponding 475 to the logical access loop port of the Access Node/DSLAM from which a 476 subscriber's requests are initiated. 478 The Attribute Value field for this AVP has the following format: 480 0 1 2 3 481 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 482 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 483 | Agent-Circuit-ID ... (two to sixty three octets) 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 The Agent-Circuit-Id is of arbitrary length, but MUST be greater than 487 1 octet and not greater than 63 octets. 489 The Length (before hiding) of this AVP is 6 plus the length of the 490 Agent-Circuit-ID. 492 The Agent-Circuit-ID contains information about the Access-Node/DSLAM 493 to which the subscriber is attached, along with a unique identifier 494 for the subscriber's DSL port on that Access-Node/DSLAM. The Agent- 495 Circuit-ID contains a locally administered string representing the 496 access loop logical port, and its syntax is defined in Section 3.9.3 497 of [TR-101]. The text string is encoded in the UTF-8 charset 498 [RFC3629]. 500 An exemplary description of the Agent-Circuit-Id string format 501 follows for background purposes. The LAC MUST treat the string as an 502 opaque value and MUST NOT manipulate or enforce the format of the 503 string based on the description here or in TR-101 [TR-101]. 505 Default syntax for the string is defined in [TR-101]. The examples 506 in this section are included only for illustrative purposes. The 507 exact syntax of the string is implementation dependant; however, a 508 typical practice is to subdivide it into two or more space-separated 509 components, one to identify the Access-Node and another the 510 subscriber line on that node, with perhaps an indication of whether 511 that line is Ethernet or ATM. Example formats for this string are 512 shown below. 514 "Access-Node-Identifier atm slot/port:vpi.vci" 515 (when ATM/DSL is used) 517 "Access-Node-Identifier eth slot/port[:vlan-id]" 518 (when Ethernet/DSL is used) 520 The syntax for the string is defined in [TR-101]. An example showing 521 the slot and port field encoding is given below: 523 "Relay-identifier atm 3/0:100.33" 524 (slot = 3, port = 0, vpi = 100, vci = 33) 526 The Access-Node-Identifier is a unique ASCII string which does not 527 include 'space' characters. The syntax of the slot and port fields 528 reflects typical practices currently in place. The slot identifier 529 does not exceed 6 characters in length and the port identifier does 530 not exceed 3 characters in length using a '/' as a delimiter. 532 The exact manner in which slots are identified is Access Node/DSLAM 533 implementation dependent. The vpi, vci and vlan-id fields (when 534 applicable) are related to a given access loop (U-interface). 536 5.2. Access Line Agent-Remote-Id AVP 538 The Access Line Agent-Remote-Id AVP, Attribute Type 2, contains an 539 operator-specific, statically configured string which uniquely 540 identifies the subscriber on the associated access loop of the Access 541 Node/DSLAM. 543 The Attribute Value field for this AVP has the following format: 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | Agent-Remote-Id ... (two to sixty three octets) 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 The Agent-Remote-Id is of arbitrary length, but MUST be greater than 552 1 octet and not greater than 63 octets. 554 The Length (before hiding) of this AVP is 6 plus the length of the 555 Agent-Remote-ID. 557 The Agent-Remote-ID contains information sent from the Access-Node/ 558 DSLAM from which the subscriber is attached, to further refine the 559 access loop logical port identification with a user. The content of 560 this message is entirely open to the service provider's discretion. 561 For example, it MAY contain a subscriber billing ID or telephone 562 number. The LAC MUST treat the string as an opaque value and MUST 563 NOT manipulate or enforce its format. The text string is defined in 564 [TR-101], and is encoded in the UTF-8 charset [RFC3629]. 566 5.3. Access Line Actual-Data-Rate-Upstream AVP 568 The Access Line Actual-Data-Rate-Upstream AVP, Attribute Type 129, 569 contains the actual upstream train rate of a subscriber's 570 synchronized Access link. 572 The Attribute Value field for this AVP has the following format: 574 0 1 2 3 575 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 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | Actual-Data-Rate-Upstream 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 579 ... in bps (64 bits) | 580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 582 The Actual-Data-Rate-Upstream is an 8-octet value. 584 The Actual-Data-Rate-Upstream AVP contains an 8-octet unsigned 585 integer, indicating the subscriber's actual data rate upstream of a 586 synchronized Access link. The rate is coded in bits per second. 588 The Length (before hiding) of this AVP is 14. 590 5.4. Access Line Actual-Data-Rate-Downstream AVP 592 The Access Line Actual-Data-Rate-Downstream AVP, Attribute Type 130, 593 contains the actual downstream train rate of a subscriber's 594 synchronized Access link. 596 The Attribute Value field for this AVP has the following format: 598 0 1 2 3 599 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 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | Actual-Data-Rate-Downstream 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 ... in bps (64 bits) | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 The Actual-Data-Rate-Downstream AVP contains an 8-octet unsigned 607 integer, indicating the subscriber's actual data rate downstream of a 608 synchronized Access link. The rate is coded in bits per second. 610 The Length (before hiding) of this AVP is 14. 612 5.5. Access Line Minimum-Data-Rate-Upstream AVP 614 The Access Line Minimum-Data-Rate-Upstream AVP, Attribute Type 131, 615 contains the subscriber's operator-configured minimum upstream data 616 rate. 618 The Attribute Value field for this AVP has the following format: 620 0 1 2 3 621 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 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | Minimum-Data-Rate-Upstream 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 ... in bps (64 bits) | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 The Minimum-Data-Rate-Upstream AVP contains an 8-octet unsigned 629 integer, indicating the subscriber's minimum upstream data rate (as 630 configured by the operator). The rate is coded in bits per second. 632 The Length (before hiding) of this AVP is 14. 634 5.6. Access Line Minimum-Data-Rate-Downstream AVP 636 The Access Line Minimum-Data-Rate-Downstream AVP, Attribute Type 132, 637 contains the subscriber's operator-configured minimum downstream data 638 rate. 640 The Attribute Value field for this AVP has the following format: 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Minimum-Data-Rate-Downstream 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 ... in bps (64 bits) | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 The Minimum-Data-Rate-Downstream AVP contains an 8-octet unsigned 651 integer, indicating the subscriber's minimum downstream data rate (as 652 configured by the operator). The rate is coded in bits per second. 654 The Length (before hiding) of this AVP is 14. 656 5.7. Access Line Attainable-Data-Rate-Upstream AVP 658 The Access Line Attainable-Data-Rate-Upstream AVP, Attribute Type 659 133, contains the subscriber's actual attainable upstream data rate. 661 The Attribute Value field for this AVP has the following format: 663 0 1 2 3 664 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 665 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 666 | Attainable-Data-Rate-Upstream 667 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 668 ... in bps (64 bits) | 669 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 The Attainable-Data-Rate-Upstream AVP contains an 8-octet unsigned 672 integer, indicating the subscriber's Access Line actual attainable 673 upstream data rate. The rate is coded in bits per second. 675 The Length (before hiding) of this AVP is 14. 677 5.8. Access Line Attainable-Data-Rate-Downstream AVP 679 The Access Line Attainable-Data-Rate-Downstream AVP, Attribute Type 680 134, contains the subscriber's actual attainable downstream data 681 rate. 683 The Attribute Value field for this AVP has the following format: 685 0 1 2 3 686 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 687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 688 | Attainable-Data-Rate-Downstream 689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 ... in bps (64 bits) | 691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 The Attainable-Data-Rate-Downstream AVP contains an 8-octet unsigned 694 integer, indicating the subscriber's Access Line actual DSL 695 attainable downstream data rate. The rate is coded in bits per 696 second. 698 The Length (before hiding) of this AVP is 14. 700 5.9. Access Line Maximum-Data-Rate-Upstream AVP 702 The Access Line Maximum-Data-Rate-Upstream AVP, Attribute Type 135, 703 contains the subscriber's maximum upstream data rate, as configured 704 by the operator. 706 The Attribute Value field for this AVP has the following format: 708 0 1 2 3 709 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 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Maximum-Data-Rate-Upstream 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 ... in bps (64 bits) | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 The Maximum-Data-Rate-Upstream AVP contains an 8-octet unsigned 717 integer, indicating the numeric value of the subscriber's Access Line 718 maximum upstream data rate. The rate is coded in bits per second. 720 The Length (before hiding) of this AVP is 14. 722 5.10. Access Line Maximum-Data-Rate-Downstream AVP 724 The Access Line Maximum-Data-Rate-Downstream AVP, Attribute Type 136, 725 contains the subscriber's maximum downstream data rate, as configured 726 by the operator. 728 The Attribute Value field for this AVP has the following format: 730 0 1 2 3 731 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 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | Maximum-Data-Rate-Downstream 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 ... in bps (64 bits) | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 738 The Maximum-Data-Rate-Downstream AVP contains an 8-octet unsigned 739 integer, indicating the numeric value of the subscriber's Access Line 740 maximum downstream data rate. The rate is coded in bits per second. 742 The Length (before hiding) of this AVP is 14. 744 5.11. Access Line Minimum-Data-Rate-Upstream-Low-Power AVP 746 The Access Line Minimum-Data-Rate-Upstream-Low-Power AVP, Attribute 747 Type 137, contains the subscriber's minimum upstream data rate in low 748 power state, as configured by the operator. 750 The Attribute Value field for this AVP has the following format: 752 0 1 2 3 753 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 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | Minimum-Data-Rate-Upstream-Low-Power 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 ... in bps (64 bits) | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 The Minimum-Data-Rate-Upstream-Low-Power AVP contains an 8-octet 761 unsigned integer, indicating the numeric value of the subscriber's 762 Access Line minimum upstream data rate when in low power state 763 (L1/L2). The rate is coded in bits per second. 765 The Length (before hiding) of this AVP is 14. 767 5.12. Access Line Minimum-Data-Rate-Downstream-Low-Power AVP 769 The Access Line Minimum-Data-Rate-Downstream-Low-Power AVP, Attribute 770 Type 138, contains the subscriber's minimum downstream data rate in 771 low power state, as configured by the operator. 773 The Attribute Value field for this AVP has the following format: 775 0 1 2 3 776 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 777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 778 | Minimum-Data-Rate-Downstream-Low-Power 779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 780 ... in bps (64 bits) | 781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 783 The Minimum-Data-Rate-Downstream-Low-Power AVP contains an 8-octet 784 unsigned integer, indicating the numeric value of the subscriber's 785 Access Line minimum downstream data rate when in low power state 786 (L1/L2). The rate is coded in bits per second. 788 The Length (before hiding) of this AVP is 14. 790 5.13. Access Line Maximum-Interleaving-Delay-Upstream AVP 792 The Access Line Maximum-Interleaving-Delay-Upstream AVP, Attribute 793 Type 139, contains the subscriber's maximum one-way upstream 794 interleaving delay, as configured by the operator. 796 The Attribute Value field for this AVP has the following format: 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Maximum-Interleaving-Delay-Upstream | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 804 The Maximum-Interleaving-Delay-Upstream AVP contains a 4-octet 805 unsigned integer, indicating the numeric value in milliseconds of the 806 subscriber's Access Line maximum one-way upstream interleaving delay. 808 The Length (before hiding) of this AVP is 10. 810 5.14. Access Line Actual-Interleaving-Delay-Upstream AVP 812 The Access Line Actual-Interleaving-Delay-Upstream AVP, Attribute 813 Type 140, contains the subscriber's actual one-way upstream 814 interleaving delay. 816 The Attribute Value field for this AVP has the following format: 818 0 1 2 3 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 | Actual-Interleaving-Delay-Upstream | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 The Actual-Interleaving-Delay-Upstream AVP contains a 4-octet 825 unsigned integer, indicating the numeric value in milliseconds of the 826 subscriber's Access Line actual upstream interleaving delay. 828 The Length (before hiding) of this AVP is 10. 830 5.15. Access Line Maximum-Interleaving-Delay-Downstream AVP 832 The Access Line Maximum-Interleaving-Delay-Downstream AVP, Attribute 833 Type 141, contains the subscriber's maximum one-way downstream 834 interleaving delay, as configured by the operator. 836 The Attribute Value field for this AVP has the following format: 838 0 1 2 3 839 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 840 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 841 | Maximum-Interleaving-Delay-Downstream | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 The Maximum-Interleaving-Delay-Downstream AVP contains a 4-octet 845 unsigned integer, indicating the numeric value in milliseconds of the 846 subscriber's Access Line maximum one-way downstream interleaving 847 delay. 849 The Length (before hiding) of this AVP is 10. 851 5.16. Access Line Actual-Interleaving-Delay-Downstream AVP 853 The Access Line Actual-Interleaving-Delay-Downstream AVP, Attribute 854 Type 142, contains the subscriber's actual one-way downstream 855 interleaving delay. 857 The Attribute Value field for this AVP has the following format: 859 0 1 2 3 860 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 861 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 862 | Actual-Interleaving-Delay-Downstream | 863 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 865 The Actual-Interleaving-Delay-Downstream AVP contains a 4-octet 866 unsigned integer, indicating the numeric value in milliseconds of the 867 subscriber's Access Line actual downstream interleaving delay. 869 The Length (before hiding) of this AVP is 10. 871 5.17. Access Line Access-Loop-Encapsulation AVP 873 The Access Line Access-Loop-Encapsulation AVP, Attribute Type 144, 874 describes the encapsulation(s) used by the subscriber on the access 875 loop. 877 The Length (before hiding) of this AVP is 9. 879 The Access-Loop-Encapsulation value is comprised of three 1-octet 880 values representing the Data Link, Encapsulation 1 and Encapsulation 881 2 respectively. 883 The Access-Loop-Encapsulation value is 3 octets in length, logically 884 divided into three 1-octet sub-fields, each containing its own 885 enumeration value, as shown in the following diagram: 887 0 1 2 888 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 890 | Data Link | Encaps 1 | Encaps 2 | 891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 893 Valid values for the sub-fields are as follows: 895 Data Link 897 0x00 ATM AAL5 899 0x01 Ethernet 901 Encaps 1 902 0x00 NA - Not Available 904 0x01 Untagged Ethernet 906 0x02 Single-Tagged Ethernet 908 Encaps 2 910 0x00 NA - Not Available 912 0x01 PPPoA LLC 914 0x02 PPPoA Null 916 0x03 IPoA LLC 918 0x04 IPoA Null 920 0x05 Ethernet over AAL5 LLC with FCS 922 0x06 Ethernet over AAL5 LLC without FCS 924 0x07 Ethernet over AAL5 Null with FCS 926 0x08 Ethernet over AAL5 Null without FCS 928 5.18. ANCP Access Line Type AVP 930 The ANCP Access Line Type AVP, Attribute Type 145, describes the 931 transmission systems on access loop to the subscriber. 933 The Attribute Value field for this AVP has the following format: 935 0 1 2 3 936 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 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 | ANCP-Access-Line-Type | 939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 941 The Length (before hiding) of this AVP is 10. The ANCP Access Line 942 Type AVP defines the type of transmission system used. 944 The ANCP Access Line Type AVP contains a 1-octet field encoding the 945 Transmission System, followed by a 3-octet reserved field (MUST be 946 zero), and is 4 octets in length. It indicates the transmission 947 systems on access loop to the subscriber. The current valid values 948 only utilize the single octet field. 950 Valid values are as follows: 952 Transmission system: 954 0x01 ADSL1 956 0x02 ADSL2 958 0x03 ADSL2+ 960 0x04 VDSL1 962 0x05 VDSL2 964 0x06 SDSL 966 0x07 UNKNOWN 968 5.19. Access Line IWF-Session AVP 970 The Access Line IWF-Session AVP, Attribute Type 254, indicates if an 971 Interworking Function has been performed with respect to the 972 subscriber's session. 974 The Attribute Value field for this AVP has the following format: 976 0 1 2 3 977 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 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | Inter-Working Function | 980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 The Inter-Working Function is a 4-octet value. 984 Valid values for this field are as follows: 986 0x00 IWF not performed 988 0x01 IWF performed 990 The Length (before hiding) of this AVP is 10. 992 6. Connect Speed Update L2TP Attribute Value Pair Extensions 994 The following sections define Connect Speed Update related AVPs. 995 These AVPs (Section 6.1 and Section 6.2) use the IETF Vendor ID of 0. 997 The M bit for these AVPs SHOULD be set to 0. However, if it is 998 desired to prevent the establishment or tear down the established 999 L2TP session if the peer LNS does not support the Connect Speed 1000 Update AVP extensions, the M bit MAY be set to 1. See Section 4.2 of 1001 [RFC2661] and Section 5.2 of [RFC3931]. 1003 6.1. Connect Speed Update AVP (CSUN, CSURQ) 1005 The Connect Speed Update AVP, Attribute Type AVP-TBD1, contains the 1006 updated connection speeds for this session. The format is consistent 1007 with that of the Tx Connect Speed and Rx Connect Speed AVPs for 1008 L2TPv2 (Attribute Types 24 and 38, respectively) and L2TPv3 1009 (Attribute Types 74 and 75, respectively). Hence, there is a 1010 separate format defined for L2TPv2 and L2TPv3. 1012 The Attribute Value field for this AVP has the following format for 1013 L2TPv2 Tunnels: 1015 0 1 2 3 1016 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 1017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1018 | Reserved | Remote Session Id | 1019 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1020 | Current Tx Connect Speed in bps | 1021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1022 | Current Rx Connect Speed in bps | 1023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1025 The Attribute Value field for this AVP has the following format for 1026 L2TPv3 Tunnels: 1028 0 1 2 3 1029 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 1030 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1031 | Remote Session Id | 1032 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1033 | Current Tx Connect Speed in bps... 1034 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1035 ...Current Tx Connect Speed in bps (64 bits) | 1036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1037 | Current Rx Connect Speed in bps... 1038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1039 ...Current Rx Connect Speed in bps (64 bits) | 1040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1042 The Remote Session Id is the remote session id relative to the sender 1043 (i.e., the identifier that was assigned to this session by the peer). 1044 The Current Tx Connect Speed is a 4-octet value (L2TPv2) or an 1045 8-octet value (L2TPv3) representing the current transmit connect 1046 speed, from the perspective of the LAC (e.g., data flowing from the 1047 LAC to the remote system). The rate is encoded in bits per second. 1048 The Current Rx Connect Speed is a 4-octet value (L2TPv2) or an 1049 8-octet value (L2TPv3) representing the current receive connect 1050 speed, from the perspective of the LAC (e.g., data flowing from the 1051 remote system to the LAC). The rate is encoded in bits per second. 1053 The Length (before hiding) of this AVP is 18 (L2TPv2) or 26 (L2TPv3). 1055 6.2. Connect Speed Update Enable AVP (ICRQ) 1057 The Connect Speed Update Enable AVP, Attribute Type AVP-TBD2, 1058 indicates whether the LAC intends to send speed updates to the LNS 1059 during the life of the session. The Connect Speed Update Enable AVP 1060 is a boolean AVP. Presence of this AVP indicates that the LAC MAY 1061 send speed updates using CSUN (see Section 4.1) during the life of 1062 the session, and the LNS SHOULD query for the current connection 1063 speed via the CSURQ (see Section 4.2) during failover 1064 synchronization. Absence of this AVP indicates that the LAC will not 1065 be sending speed updates using CSUN (see Section 4.1) during the life 1066 of the session, and the LNS MUST NOT query for the current connection 1067 speed via the CSURQ (see Section 4.2) during failover 1068 synchronization. 1070 The Length (before hiding) of this AVP is 6. 1072 7. Access Line Information AVP Mapping 1074 The Access Line information that is obtained from the Access Node/ 1075 DSLAM is required to be mapped into the Access Line AVPs. The Access 1076 Line information can be obtained via: 1078 o Vendor-Specific PPPoE Tags [RFC2516]. 1080 o DHCP Relay Options [RFC3046] and Vendor-Specific Information 1081 Suboptions [RFC4243]. 1083 o ANCP [I-D.ietf-ancp-protocol]. 1085 7.1. Summary of Access Line AVPs 1087 Table 1 summarizes the Access Line AVPs defined in Section 5.1 1088 through Section 5.19. 1090 +-----------------+----------------------------------------+ 1091 | Access Line AVP | Name | 1092 +-----------------+----------------------------------------+ 1093 | 1 (0x01) | Agent-Circuit-Id | 1094 | 2 (0x02) | Agent-Remote-Id | 1095 | 129 (0x81) | Actual-Data-Rate-Upstream | 1096 | 130 (0x82) | Actual-Data-Rate-Downstream | 1097 | 131 (0x83) | Minimum-Data-Rate-Upstream | 1098 | 132 (0x84) | Minimum-Data-Rate-Downstream | 1099 | 133 (0x85) | Attainable-Data-Rate-Upstream | 1100 | 134 (0x86) | Attainable-Data-Rate-Downstream | 1101 | 135 (0x87) | Maximum-Data-Rate-Upstream | 1102 | 136 (0x88) | Maximum-Data-Rate-Downstream | 1103 | 137 (0x89) | Minimum-Data-Rate-Upstream-Low-Power | 1104 | 138 (0x8A) | Minimum-Data-Rate-Downstream-Low-Power | 1105 | 139 (0x8B) | Maximum-Interleaving-Delay-Upstream | 1106 | 140 (0x8C) | Actual-Interleaving-Delay-Upstream | 1107 | 141 (0x8D) | Maximum-Interleaving-Delay-Downstream | 1108 | 142 (0x8E) | Actual-Interleaving-Delay-Downstream | 1109 | 144 (0x90) | Access-Loop-Encapsulation | 1110 | 145 (0x91) | ANCP Access Line Type | 1111 | 254 (0xFE) | IWF-Session | 1112 +-----------------+----------------------------------------+ 1114 Table 1: Access Line AVP Summary 1116 8. IANA Considerations 1118 Sections 8.1 and 8.2 describe request for new values in 1119 [IANA.l2tp-parameters], for registries already managed by IANA 1120 assignable through Expert Review according to [RFC3438]. Section 8.3 1121 describes number spaces not managed by IANA. 1123 8.1. Message Type AVP Values 1125 This number space is managed by IANA as per [RFC3438]. There are two 1126 new message types, defined in Section 4.1 and Section 4.2, to be 1127 allocated for this specification. 1129 Message Type AVP (Attribute Type 0) Values 1131 MSG-TBD1: (CSUN) Connect-Speed-Update-Notification 1133 MSG-TBD2: (CSURQ) Connect-Speed-Update-Request 1135 8.2. Control Message Attribute Value Pairs (AVPs) 1137 This number space is managed by IANA as per [RFC3438]. There are two 1138 new AVPs, defined in Section 6.1 and Section 6.2, to be allocated for 1139 this specification. 1141 Control Message Attribute Value Pairs (AVPs) 1143 AVP-TBD1: Connect Speed Update AVP 1145 AVP-TBD2: Connect Speed Update Enable AVP 1147 8.3. Values for Access Line Information AVPs 1149 The Access Line Information AVPs use the Vendor ID of 3561 for the 1150 ADSL Forum (now Broadband Forum). The number spaces in these Values 1151 and their new allocations (e.g., enumerated values for the Access 1152 Line Access-Loop-Encapsulation AVP and ANCP Access Line Type AVP) are 1153 managed by the Broadband Forum. 1155 9. Security Considerations 1157 The security of these AVP relies on an implied trust relationship 1158 between the Access Node/DSLAM and the BRAS/LAC, and between the LAC 1159 and the LNS. The identifiers which are inserted by the Access Node/ 1160 DSLAM are unconditionally trusted; the BRAS does not perform any 1161 validity check on the information received before forwarding the 1162 information. 1164 These AVPs are intended to be used in environments in which the 1165 network infrastructure (the Access Node/DSLAM, the BRAS/LAC, the LNS, 1166 and the entire network in which those devices reside) is trusted and 1167 secure. 1169 Careful consideration should be given to the potential security 1170 vulnerabilities that are present in this model before deploying this 1171 option in actual networks. 1173 The AVPs described in this document are used to carry identification 1174 and characterization of subscriber Access Line, and to report 1175 connection speed changes. If used in a non-secure environment, they 1176 could reveal such information. The Tunnel (Control Connection) 1177 security considerations are covered in Section 9.1 of [RFC2661] and 1178 Section 8.l of [RFC3931]. Additionally, the hiding of AVP attribute 1179 values mechanism can be used to hide the value of the AVPs described 1180 in this document, if they are deemed sensitive in some environments. 1181 AVP hiding is described in Section 4.3 of [RFC2661] and Section 5.3 1182 of [RFC3931]. 1184 The Attributes described in this document neither increase nor 1185 decrease the security of the L2TP protocol. 1187 It is possible to utilize [RFC3193] "Securing L2TP with IPsec" to 1188 increase the security by utilizing IPsec to provide for tunnel 1189 authentication, privacy protection, integrity checking and replay 1190 protection. 1192 10. Acknowledgements 1194 Many thanks to Wojciech Dec and the others of the Broadband Forum 1195 (previously the DSL Forum) Architecture and Transport Working Group 1196 for their help in putting together this document. 1198 11. References 1200 11.1. Normative References 1202 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1203 Requirement Levels", BCP 14, RFC 2119, March 1997. 1205 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 1206 G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", 1207 RFC 2661, August 1999. 1209 [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) 1210 Internet Assigned Numbers Authority (IANA) Considerations 1211 Update", BCP 68, RFC 3438, December 2002. 1213 [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling 1214 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 1216 [TR-101] DSL Forum, "Migration to Ethernet-Based DSL Aggregation", 1217 TR 101, April 2006, . 1220 11.2. Informative References 1222 [I-D.ietf-ancp-protocol] 1223 Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., Voigt, 1224 N., and R. Maglione, "Protocol for Access Node Control 1225 Mechanism in Broadband Networks", 1226 draft-ietf-ancp-protocol-04 (work in progress), 1227 November 2008. 1229 [IANA.enterprise-numbers] 1230 Internet Assigned Numbers Authority, "PRIVATE ENTERPRISE 1231 NUMBERS", November 2007, 1232 . 1234 [IANA.l2tp-parameters] 1235 Internet Assigned Numbers Authority, "Layer Two Tunneling 1236 Protocol "L2TP"", October 2007, 1237 . 1239 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 1240 and R. Wheeler, "A Method for Transmitting PPP Over 1241 Ethernet (PPPoE)", RFC 2516, February 1999. 1243 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 1244 RFC 3046, January 2001. 1246 [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, 1247 "Securing L2TP using IPsec", RFC 3193, November 2001. 1249 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1250 10646", STD 63, RFC 3629, November 2003. 1252 [RFC4243] Stapp, M., Johnson, R., and T. Palaniappan, "Vendor- 1253 Specific Information Suboption for the Dynamic Host 1254 Configuration Protocol (DHCP) Relay Agent Option", 1255 RFC 4243, December 2005. 1257 [RFC4679] Mammoliti, V., Zorn, G., Arberg, P., and R. Rennison, "DSL 1258 Forum Vendor-Specific RADIUS Attributes", RFC 4679, 1259 September 2006. 1261 [RFC4951] Jain, V., "Fail Over Extensions for Layer 2 Tunneling 1262 Protocol (L2TP) "failover"", RFC 4951, August 2007. 1264 Authors' Addresses 1266 Vince Mammoliti 1267 Cisco Systems 1268 181 Bay Street, Suite 3400 1269 Toronto, ON M5J 2T3 1270 Canada 1272 Email: vince@cisco.com 1273 Carlos Pignataro 1274 Cisco Systems 1275 7200 Kit Creek Road 1276 PO Box 14987 1277 Research Triangle Park, NC 27709 1278 USA 1280 Email: cpignata@cisco.com 1282 Peter Arberg 1283 Redback Networks 1284 300 Holger Way 1285 San Jose, CA 95134 1286 USA 1288 Email: parberg@redback.com 1290 John Gibbons 1291 Juniper Networks 1292 10 Technology Park Drive 1293 Westford, MA 01886 1294 USA 1296 Email: jgibbons@juniper.net 1298 Paul Howard 1300 Email: howsoft@mindspring.com