RFC 5515

Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions

📅 published May 2009, from ietf

Layer 2 Tunneling Protocol (L2TP) Access Line Information Attribute Value Pair (AVP) Extensions 🎀

Okay bestie, this is RFC 5515 📄 from the Network Working Group, dated May 2009. It's filed as Informational, so it's a reference doc, not a standard. The authors are V. Mammoliti and C. Pignataro (both Cisco Systems), P. Arberg (Redback Networks), J. Gibbons (Juniper Networks), and P. Howard (no affiliation is listed in this copy). The header doesn't list anything it obsoletes or updates, so it's standing on its own ✨

Status of This Memo 📜

This memo gives information to the Internet community. It is not an Internet standard of any kind, and distribution of this memo is unlimited 🌸

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved 💜

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, as they stand on the date this document was published (http://trustee.ietf.org/license-info). Please read these carefully, because they spell out your rights and restrictions for this document 🫶

Abstract 💭

Okay, the main vibe here is a set of Layer 2 Tunneling Protocol (L2TP) Attribute Value Pair (AVP) extensions 🦋 They're built to carry the subscriber Access Line identification and characterization info that shows up at the Broadband Remote Access Server (BRAS) with L2TP Access Concentrator (LAC) functionality.

It also covers a way to report connection speed changes after the first connection speeds get sent during session establishment. The main goal is to give DSL equipment vendors a reference so their gear can interoperate with other vendors' products 🤝 And the L2TP AVPs here work with both L2TPv2 and L2TPv3 🔥

Table of Contents 📑

   1. Introduction ....................................................3
   2. Terminology .....................................................3
      2.1. Requirements Language ......................................3
      2.2. Technical Terms and Acronyms ...............................4
   3. Access Line Information L2TP AVP Operation ......................5
   4. Additional L2TP Messages ........................................6
      4.1. Connect-Speed-Update-Notification (CSUN) ...................8
      4.2. Connect-Speed-Update-Request (CSURQ) .......................8
   5. Access Line Information L2TP Attribute Value Pair Extensions ....9
      5.1. Access Line Agent-Circuit-Id AVP ..........................10
      5.2. Access Line Agent-Remote-Id AVP ...........................11
      5.3. Access Line Actual-Data-Rate-Upstream AVP .................12
      5.4. Access Line Actual-Data-Rate-Downstream AVP ...............13
      5.5. Access Line Minimum-Data-Rate-Upstream AVP ................13
      5.6. Access Line Minimum-Data-Rate-Downstream AVP ..............14
      5.7. Access Line Attainable-Data-Rate-Upstream AVP .............14
      5.8. Access Line Attainable-Data-Rate-Downstream AVP ...........14
      5.9. Access Line Maximum-Data-Rate-Upstream AVP ................15
      5.10. Access Line Maximum-Data-Rate-Downstream AVP .............15
      5.11. Access Line Minimum-Data-Rate-Upstream-Low-Power AVP .....16
      5.12. Access Line Minimum-Data-Rate-Downstream-Low-Power AVP ...16
      5.13. Access Line Maximum-Interleaving-Delay-Upstream AVP ......17
      5.14. Access Line Actual-Interleaving-Delay-Upstream AVP .......17
      5.15. Access Line Maximum-Interleaving-Delay-Downstream AVP ....18
      5.16. Access Line Actual-Interleaving-Delay-Downstream AVP .....18
      5.17. Access Line Access-Loop-Encapsulation AVP ................19
      5.18. ANCP Access Line Type AVP ................................20
      5.19. Access Line IWF-Session AVP ..............................21
   6. Connect Speed Update L2TP Attribute Value Pair Extensions ......22
      6.1. Connect Speed Update AVP (CSUN, CSURQ) ....................22
      6.2. Connect Speed Update Enable AVP (ICRQ) ....................23
   7. Access Line Information AVP Mapping ............................24
      7.1. Summary of Access Line AVPs ...............................24
   8. IANA Considerations ............................................25
      8.1. Message Type AVP Values ...................................25
      8.2. Control Message Attribute Value Pairs (AVPs) ..............25
      8.3. Values for Access Line Information AVPs ...................25
   9. Security Considerations ........................................25
   10. Acknowledgements ..............................................26
   11. References ....................................................26
      11.1. Normative References .....................................26
      11.2. Informative References ...................................27

1. Introduction ✨

Okay so Access Nodes (ANs), which are called Digital Subscriber Line Access Multiplexers (DSLAMs) in DSL, are getting upgrades 💅 They're learning to pass subscriber Access Line identification and characterization info, using in-band signaling, up to the BRAS that has LAC functionality.

The Access Node/DSLAM may forward that info through one or more of these methods:

  • Vendor-Specific Point-to-Point Protocol over Ethernet (PPPoE) Tags [RFC2516].
  • DHCP Relay Options [RFC3046] and Vendor-Specific Information Suboptions [RFC4243].
  • Access Node Control Protocol [ANCP].

Right now, this info is being collected on the BRAS and forwarded to a radius server via [RFC4679] 🧚

This document describes the new extra L2TP AVPs that were made to forward that subscriber line identification and characterization info from the BRAS/LAC to the terminating L2TP Network Server (LNS) 🌈 It also describes how the LAC can report connection speed changes to the LNS after the initial connection speeds are sent by the LAC during session establishment.

The L2TP AVPs defined in this document MAY be used with either an L2TPv2 [RFC2661] or L2TPv3 [RFC3931] implementation.

The info can be used for authentication, policy, and accounting functionality. It can also be collected and used for management and troubleshooting 🔥

2. Terminology 💅

The following sections define the usage and meaning of certain specialized terms in the context of this document 🎀

2.1. Requirements Language 📏

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].

2.2. Technical Terms and Acronyms 🧠

Access Node/DSLAM

The Access Node/DSLAM is a DSL signal terminator that contains a minimum of one Ethernet or ATM interface that serves as its upstream interface into which it aggregates traffic from several ATM-based (subscriber ports) or Ethernet-based downstream interfaces 🌸

BNG

Broadband Network Gateway. A BNG is an IP edge router where bandwidth and Quality-of-Service (QoS) policies are applied. The functions performed by a BRAS are a superset of those performed by a BNG 💖

BRAS

Broadband Remote Access Server. A BRAS is a BNG and is the aggregation point for the subscriber traffic. It provides aggregation capabilities (e.g., IP, PPP, Ethernet) between the access network and the core network. Beyond its aggregation function, the BRAS is also an injection point for policy management and IP QoS in the access network 👑

DSL

Digital Subscriber Line. DSL is a technology that allows digital data transmission over wires in the local telephone network 📞

DSLAM

Digital Subscriber Line Access Multiplexer. DSLAM is a device that terminates DSL subscriber lines. The data is aggregated and forwarded to ATM- or Ethernet-based aggregation networks 🦋

IWF

Interworking Function. The set of functions required for interconnecting two networks of different technologies (e.g., ATM and Ethernet). IWF is utilized to enable the carriage of Point-to-Point Protocol over ATM (PPPoA) traffic over PPPoE 🍓

LAC

L2TP Access Concentrator. If an L2TP Control Connection Endpoint (LCCE) is being used to cross-connect an L2TP session directly to a data link, we refer to it as an L2TP Access Concentrator (LAC). (See [RFC2661] and [RFC3931].) 🫶

LCCE

L2TP Control Connection Endpoint. An L2TP node that exists at either end of an L2TP control connection. It's also called an LAC or LNS, depending on whether tunneled frames are processed at the data link (LAC) or network layer (LNS). (See [RFC3931].) ✨

LNS

L2TP Network Server. If a given L2TP session is terminated at the L2TP node and the encapsulated network layer (L3) packet is processed on a virtual interface, we refer to this L2TP node as an L2TP Network Server (LNS). (See [RFC2661] and [RFC3931].) 💜

3. Access Line Information L2TP AVP Operation ✨

okay so, the BRAS with LAC functionality gets the Access Line info from the Access Node, and once it figures out the session is going to an LNS, the LAC forwards everything it collected in the newly defined L2TP AVPs 💖 it only forwards the Access Line Information AVPs that actually have values in them, so no empty ones floating around 🫶

the Access Line info from any of the methods must be available at the BRAS before the LAC starts session negotiation 🦋 that way the Access Line parameters reach the LNS reliably and nobody has to wait around for extra call setup delays 😭 now, if the LAC hasn't gotten any Access Line info from any method, the default is that the LAC SHOULD establish the L2TP session without waiting for it 💅 in that case the LAC MUST NOT send any Access Line AVPs to the LNS. the LAC MAY, as local policy, wait for Access Line info from one or more of the methods before forwarding it in the Access Line L2TP AVPs to the LNS 🌸

the Access Node might only send a subset of the line info that's currently defined, which is totally fine 🎀 the LAC MUST be able to limit and/or filter which AVPs, if any, get sent to the LNS. no oversharing, bestie 🙈

the LAC could also get Access Line info from multiple sources at different times ✨ local policy SHOULD decide which source(s) the LAC accepts. the LAC SHOULD default to accepting ANCP-sourced parameters 🧚

the Access Line AVPs ride along in the L2TP Incoming-Call-Request (ICRQ) control message 💜 and Connect Speed Update AVPs go in the Connect-Speed-Update-Notification (CSUN) or Connect-Speed-Update-Request (CSURQ) L2TP messages (see Sections 4, 4.1, and 4.2) 🌈

the LAC can send updated Connect Speed characteristics to the LNS through the Connect Speed Update AVP in an L2TP Connect-Speed-Update-Notification (CSUN) control message (see Section 4.1) 🔥 but here's the lowkey genius part: to avoid pointless CSURQ and CSUN exchanges between the LAC and LNS (like during failover protocol recovery and resynchronization), the LAC announces in the session establishment exchange whether it can and wants to send speed updates during the life of the session 👑 it does this with a new AVP, Connect Speed Update Enable (see Section 6.2), sent in the ICRQ message. no Connect Speed Update Enable in the ICRQ means the LAC won't be sending any speed updates for the whole session 💀

so, if the LAC is set up to accept ANCP-sourced parameters AND it supports sending speed updates during the session, it MUST send the Connect Speed Update Enable AVP in the ICRQ, because that means speed updates may happen over the life of the connection 🦋 but if the LAC only accepts PPPoE vendor-specific tags, it MUST NOT send the Connect Speed Update Enable AVP in the ICRQ 🙅‍♀️ since the connection speed only gets sent during PPPoE discovery and nothing else changes for the life of the connection 🌸

4. Additional L2TP Messages 🎀

if the Access Line info changes while the session is still up, connection speed updates MAY be sent from the LAC to the LNS in an L2TP Connect-Speed-Update-Notification (CSUN) Message (see Section 4.1) 💖 a new AVP, Connect Speed Update (see Section 6.1), goes in the CSUN message to report connect speed updates for a specific session after the initial connection speeds are set up (that's at session establishment via the Tx Connect Speed and Rx Connect Speed AVPs, Attribute Types 24 and 38 respectively for L2TPv2, and 74 and 75 respectively for L2TPv3) ✨

the values in the Connect Speed Update AVP (and the values for the initial Tx/Rx Connect Speed AVPs) are based on LAC local policy 🧚 for example, the LAC's local policy might use Actual-Data-Rate-Upstream and Actual-Data-Rate-Downstream to report connection speed updates 💜 for consistency, the same local policy SHOULD equally apply to both the initial connect speeds (sent during session establishment) and the (optional) connect speed updates (sent after the session is established) 🌈 the CSUN message MAY be sent periodically to the LNS based on local policy, and it may include more than one Connect Speed Update AVP 🔥 bundling several of them into one CSUN is super useful for a few reasons:

  • It dampens the rate of changes sent to the LNS when Access Line parameter updates come in at a high rate for a given line 🫶
  • It efficiently forwards speed updates when Access Line parameter updates come in for many lines at the same time 👑
  • It supports failover [RFC4951] protocol recovery and resynchronization 💅

during failover recovery and resynchronization, the LNS MAY send a Connect-Speed-Update-Request (CSURQ) message (see Section 4.2) to the LAC with one or more Session IDs, just to make sure the correct speeds have been applied to outstanding sessions on each tunnel 🦋 in response to the CSURQ, the LAC MUST issue a Connect-Speed-Update-Notification (CSUN) message (see Section 4.1) with a Connect Speed Update AVP for each of the Session IDs requested in the CSURQ 🌸

Note: In the CSUN response to the CSURQ, the LAC MUST NOT respond to unknown sessions, or to known sessions for which it did not issue a Connect Speed Update Enable AVP in the prior Incoming-Call-Request (ICRQ) control message for the session (see Sections 3 and 6.2). 🙈

this section defines two new Messages that use the IETF Vendor ID of 0 in the Message Type AVP 🍓 these new message types get assigned as follows (see Section 8.1):

28: (CSUN) Connect-Speed-Update-Notification
29: (CSURQ) Connect-Speed-Update-Request

the Mandatory (M) bit within the Message Type AVP SHOULD be clear (i.e., not set) for the CSUN and CSURQ control messages 🫶 that lets an L2TP Control Connection Endpoint (LCCE) keep the control connection up even if it doesn't recognise the message type ✨

4.1. Connect-Speed-Update-Notification (CSUN) 💖

the Connect-Speed-Update-Notification (CSUN) is an L2TP control message that the LAC sends to the LNS to provide transmit and receive connection speed updates for one or more sessions 🦋 the connection speed can change at any time during the life of the call, so the LNS SHOULD be able to update its connection speed on an active session 🔥

the following AVPs MUST be present in the CSUN:

Message Type

Connect Speed Update (more than one may be present in the CSUN)

note that the LAC MUST NOT include a Connect Speed Update AVP for which it did not send a Connect Speed Update Enable AVP in the prior Incoming-Call-Request (ICRQ) control message for the session 💅

4.2. Connect-Speed-Update-Request (CSURQ) 🌈

the Connect-Speed-Update-Request (CSURQ) is an L2TP control message that the LNS sends to the LAC to request the current transmit and receive connection speed for one or more sessions 🧚 it MAY be issued at any time during the life of the tunnel, and it MUST only be issued for each outstanding session on each tunnel where the LNS has already received a Connect Speed Update Enable AVP in the prior Incoming-Call-Request (ICRQ) control message for the session 👑 it's typically used as part of failover recovery and resynchronization so the LNS can double check it has the correct speeds for each outstanding session on each tunnel 🌸

the following AVPs MUST be present in the CSURQ:

Message Type

Connect Speed Update (more than one may be present in the CSURQ)

the Current Tx Connect Speed and Current Rx Connect Speed fields in the Connect Speed Update AVP MUST be set to 0 when this AVP is used in the CSURQ message 🎀

in the CSUN response to the CSURQ, the LAC MUST NOT respond to unknown sessions, or to known sessions for which it did not issue a Connect Speed Update Enable AVP in the prior Incoming-Call-Request (ICRQ) control message for the session 🙈

5. Access Line Information L2TP Attribute Value Pair Extensions 💜

the Access Line information was first defined in the DSL Forum Technical Report TR-101 [TR-101] ✨ TR-101 defines the line characteristics that get sent from an Access Node 🫶

the sections below have a list of the Access Line Information L2TP AVPs 🦋 each listed AVP comes with a short description of what it's for 💖

the AVPs follow the standard way of encoding AVPs, which looks like this 🌈

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |M|H| rsvd  |      Length       |           Vendor ID           |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |         Attribute Type        |Attribute Value, if Required ...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                  ... (Until Length is reached)                   |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

the M bit for all the AVPs defined in this document SHOULD be set to 0, so they stay backwards compatible with LNSs that don't support the Access Line Information AVP extensions defined here 🔥 but if you want to stop the L2TP session from being established when the peer LNS doesn't support these extensions, the M bit MAY be set to 1 👑 see Section 4.2 of [RFC2661] and Section 5.2 of [RFC3931] 💅

all the AVPs defined in this document MAY be hidden (the H bit MAY be 0 or 1) 🌸

the Length (before hiding) of all the listed AVPs is 6 plus the length of the Attribute Value, if one is required, in octets 🧚

the Vendor ID for all the listed AVPs (Sections 5.1 through 5.19) is the IANA assigned ADSL Forum Vendor ID, decimal 3561 [IANA.enterprise-numbers] 🎀

all the listed AVPs (Section 5.1 through Section 5.19) MAY be present in the following messages unless otherwise stated:

  • Incoming-Call-Request (ICRQ)

the Value of the AVP contains information about the Access Line that the subscriber is attached to 🍓

with the exception of the Connect Speed Update AVP (see Section 6.1), all new AVPs that specify a data rate or speed in bits per second (bps) will be sent as 64 bits, so they can handle future increases in subscriber connection speeds 🦋 these new AVPs with a 64-bit "Data-Rate" are defined from Section 5.3 to Section 5.12, both inclusive ✨ whenever a speed value sent in an AVP fits within 32 bits, the upper 32 bits MUST be transmitted as 0s 💖

the various Data-Rates and Interleaving-Delays used in the following Sections 5.3 through 5.16 are defined in Section 3.9.4 of [TR-101] 🌈 the qualifiers used with these Data-Rates and Interleaving-Delays mean the following 👑

  • Actual: Actual rate or delay of an access loop
  • Attainable: Maximum value that can be achieved by the equipment
  • Minimum: Minimum value configured by the operator
  • Maximum: Maximum value configured by the operator

5.1. Access Line Agent-Circuit-Id AVP 🎀

Okay so this one is Attribute Type 1 and it's giving "where exactly did this request come from?" 🦋 It describes the subscriber agent circuit ID for the logical access loop port on the Access Node/DSLAM where the subscriber's requests start ✨

The Attribute Value field for this AVP has the following format:

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Agent-Circuit-Id ... (2 to 63 octets)
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Agent-Circuit-Id can be any length, but it MUST be greater than 1 octet and no greater than 63 octets 🙈 So it's flexible, but there are firm limits, bestie.

The Length (before hiding) of this AVP is 6 plus the length of the Agent-Circuit-Id 🧚

The Agent-Circuit-Id tells you about the Access Node/DSLAM the subscriber is plugged into, plus a unique identifier for their DSL port on that node 💜 It's a locally administered string for the access loop logical port, and its syntax is defined in Section 3.9.3 of [TR-101]. The text string is encoded in the UTF-8 charset [RFC3629] 🌸

Here's an exemplary format for the string, just for background vibes ✨

The LAC MUST treat the string as an opaque value, and it MUST NOT manipulate or enforce the format of the string based on the description here or in TR-101 [TR-101]. Read that twice, it's important 💀

The default syntax is defined in [TR-101]. The examples in this section are only there to illustrate things. The exact syntax is implementation dependent, but a typical practice is to split it into two or more space-separated components: one to identify the Access Node, and another for the subscriber line on that node, maybe with an indication of whether the line is Ethernet or ATM 🍓 Example formats are below:

"Access-Node-Identifier atm slot/port:vpi.vci"
(when ATM/DSL is used)

"Access-Node-Identifier eth slot/port[:vlan-id]"
(when Ethernet/DSL is used)

The syntax for the string is defined in [TR-101]. Here's an example showing the slot and port field encoding:

"Relay-identifier atm 3/0:100.33"
(slot = 3, port = 0, vpi = 100, vci = 33)

The Access-Node-Identifier is a unique ASCII string that does not include 'space' characters. The slot and port fields follow typical practices that are already in place. The slot identifier does not exceed 6 characters in length, and the port identifier does not exceed 3 characters in length, using a '/' as the delimiter 🫶

How slots get identified is up to the Access Node/DSLAM implementation, so it varies 🦋 The vpi, vci, and vlan-id fields (when applicable) are all related to a given access loop (U-interface) 💅

5.2. Access Line Agent-Remote-Id AVP 🌈

This AVP is Attribute Type 2 and it's the operator-specific, statically configured string that uniquely identifies the subscriber on the associated access loop of the Access Node/DSLAM 👑

The Attribute Value field for this AVP has the following format:

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Agent-Remote-Id ... (2 to 63 octets)
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Agent-Remote-Id can be any length, but it MUST be greater than 1 octet and no greater than 63 octets ✨

The Length (before hiding) of this AVP is 6 plus the length of the Agent-Remote-Id 🎀

The Agent-Remote-Id carries info sent from the Access Node/DSLAM the subscriber is attached to, which helps refine the access loop logical port identification down to a specific user 🫶 What goes in it is entirely up to the service provider. For example, it MAY contain a subscriber billing ID or telephone number 💖 The LAC MUST treat the string as an opaque value and MUST NOT manipulate or enforce its format. The text string is defined in [TR-101] and encoded in the UTF-8 charset [RFC3629] 💅

5.3. Access Line Actual-Data-Rate-Upstream AVP 🚀

This is Attribute Type 129 and it holds the actual upstream train rate of a subscriber's synchronized Access link 🔥

The Attribute Value field for this AVP has the following format:

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Actual-Data-Rate-Upstream
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      ... in bps (64 bits)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Actual-Data-Rate-Upstream is an 8-octet value 🧚

The Actual-Data-Rate-Upstream AVP holds an 8-octet unsigned integer that shows the subscriber's actual upstream data rate on a synchronized Access link. The rate is coded in bits per second ✨

The Length (before hiding) of this AVP is 14 💖

5.4. Access Line Actual-Data-Rate-Downstream AVP 🦋

This one is Attribute Type 130 and it's the downstream twin of the last AVP 👯‍♀️ It contains the actual downstream train rate of a subscriber's synchronized Access link 🌸

The Attribute Value field for this AVP has the following format:

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Actual-Data-Rate-Downstream
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      ... in bps (64 bits)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Actual-Data-Rate-Downstream AVP contains an 8-octet unsigned integer that shows the subscriber's actual downstream data rate on a synchronized Access link. The rate is coded in bits per second 🫶

The Length (before hiding) of this AVP is 14 ✨

5.5. Access Line Minimum-Data-Rate-Upstream AVP 🎀

This is Attribute Type 131 and it holds the subscriber's operator-configured minimum upstream data rate 💅

The Attribute Value field for this AVP has the following format:

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Minimum-Data-Rate-Upstream
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      ... in bps (64 bits)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Minimum-Data-Rate-Upstream AVP contains an 8-octet unsigned integer that shows the subscriber's minimum upstream data rate, as configured by the operator. The rate is coded in bits per second 🌈

The Length (before hiding) of this AVP is 14 💖

5.6. Access Line Minimum-Data-Rate-Downstream AVP 🧚

This one is Attribute Type 132, and it's the operator-configured minimum downstream data rate for the subscriber 🍓

The Attribute Value field for this AVP has the following format:

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                Minimum-Data-Rate-Downstream
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      ... in bps (64 bits)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Minimum-Data-Rate-Downstream AVP contains an 8-octet unsigned integer that shows the subscriber's minimum downstream data rate, as configured by the operator. The rate is coded in bits per second 🫶

The Length (before hiding) of this AVP is 14 ✨

5.7. Access Line Attainable-Data-Rate-Upstream AVP 🦋

This is Attribute Type 133 and it's the subscriber's actual attainable upstream data rate, so basically what the line is capable of 🚀

The Attribute Value field for this AVP has the following format:

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                Attainable-Data-Rate-Upstream
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      ... in bps (64 bits)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Attainable-Data-Rate-Upstream AVP contains an 8-octet unsigned integer that shows the subscriber's Access Line actual attainable upstream data rate. The rate is coded in bits per second 💅

The Length (before hiding) of this AVP is 14 🎀

5.8. Access Line Attainable-Data-Rate-Downstream AVP 💜

This one is Attribute Type 134, and it's the subscriber's actual attainable downstream data rate 🌸

The Attribute Value field for this AVP has the following format:

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                Attainable-Data-Rate-Downstream
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      ... in bps (64 bits)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Attainable-Data-Rate-Downstream AVP contains an 8-octet unsigned integer that shows the subscriber's Access Line actual DSL attainable downstream data rate. The rate is coded in bits per second ⭐

The Length (before hiding) of this AVP is 14 ✨

5.9. Access Line Maximum-Data-Rate-Upstream AVP 👑

Last one in this batch! This is Attribute Type 135, and it holds the subscriber's maximum upstream data rate as configured by the operator 🔥

The Attribute Value field for this AVP has the following format:

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                  Maximum-Data-Rate-Upstream
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      ... in bps (64 bits)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Maximum-Data-Rate-Upstream AVP contains an 8-octet unsigned integer that shows the numeric value of the subscriber's Access Line maximum upstream data rate. The rate is coded in bits per second 🌈

The Length (before hiding) of this AVP is 14 💖

5.10. Access Line Maximum-Data-Rate-Downstream AVP 🌊

okay so this one is the subscriber's max downstream rate, the speed the operator set for them 💖 Attribute Type 136.

The Attribute Value field looks like this 👀

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                 Maximum-Data-Rate-Downstream
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      ... in bps (64 bits)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It's an 8-octet unsigned integer, and the rate is in bits per second. Slay the precision 🎀

The Length (before hiding) of this AVP is 14.

5.11. Access Line Minimum-Data-Rate-Upstream-Low-Power AVP 🐢

This one is the subscriber's minimum upstream rate when they're chilling in low power state, again set by the operator. Attribute Type 137 🦋

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |              Minimum-Data-Rate-Upstream-Low-Power
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      ... in bps (64 bits)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It's an 8-octet unsigned integer that holds the minimum upstream rate while the line is in low power state (L1/L2). It's in bits per second, obviously 💅

The Length (before hiding) of this AVP is 14.

5.12. Access Line Minimum-Data-Rate-Downstream-Low-Power AVP 🌸

Same vibe, just downstream this time. This is the subscriber's minimum downstream rate in low power state, set by the operator. Attribute Type 138 🍓

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Minimum-Data-Rate-Downstream-Low-Power
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                      ... in bps (64 bits)                        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It's an 8-octet unsigned integer for the subscriber's minimum downstream rate in low power state (L1/L2), coded in bits per second 🫶

The Length (before hiding) of this AVP is 14.

5.13. Access Line Maximum-Interleaving-Delay-Upstream AVP ⏱️

This is the subscriber's max one-way upstream interleaving delay, as set by the operator. Attribute Type 139 ✨

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |             Maximum-Interleaving-Delay-Upstream               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It's a 4-octet unsigned integer, and the value is in milliseconds 🔥

The Length (before hiding) of this AVP is 10.

5.14. Access Line Actual-Interleaving-Delay-Upstream AVP 📍

This one is the subscriber's actual one-way upstream interleaving delay, so it's what's really happening, not what's configured. Attribute Type 140 💜

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Actual-Interleaving-Delay-Upstream                 |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It's a 4-octet unsigned integer, measured in milliseconds 🌈

The Length (before hiding) of this AVP is 10.

5.15. Access Line Maximum-Interleaving-Delay-Downstream AVP 🧚

Downstream version of the max delay: the subscriber's max one-way downstream interleaving delay, set by the operator. Attribute Type 141 🌸

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |           Maximum-Interleaving-Delay-Downstream               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It's a 4-octet unsigned integer in milliseconds 🎀

The Length (before hiding) of this AVP is 10.

5.16. Access Line Actual-Interleaving-Delay-Downstream AVP 💫

And the actual downstream version: the subscriber's real one-way downstream interleaving delay. Attribute Type 142 🦋

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            Actual-Interleaving-Delay-Downstream               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It's a 4-octet unsigned integer, and yep, milliseconds 🍓

The Length (before hiding) of this AVP is 10.

5.17. Access Line Access-Loop-Encapsulation AVP 🎀

This AVP describes the encapsulation(s) the subscriber is using on the access loop. Attribute Type 144 💅

The Length (before hiding) of this AVP is 9.

The Access-Loop-Encapsulation value is three 1-octet values: Data Link, Encapsulation 1, and Encapsulation 2, in that order. It's 3 octets total, split into three 1-octet sub-fields, and each one has its own enumeration value 🧩

            0                   1                   2
            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           |   Data Link   |    Encaps 1   |    Encaps 2   |
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Here are the valid values for each sub-field 👇

Data Link:

  • 0x00 ATM AAL5
  • 0x01 Ethernet

Encaps 1:

  • 0x00 NA - Not Available
  • 0x01 Untagged Ethernet
  • 0x02 Single-Tagged Ethernet

Encaps 2:

  • 0x00 NA - Not Available
  • 0x01 PPPoA LLC
  • 0x02 PPPoA Null
  • 0x03 IP over ATM (IPoA) LLC
  • 0x04 IPoA Null
  • 0x05 Ethernet over AAL5 LLC with Frame Check Sequence (FCS)
  • 0x06 Ethernet over AAL5 LLC without FCS
  • 0x07 Ethernet over AAL5 Null with FCS
  • 0x08 Ethernet over AAL5 Null without FCS

5.18. ANCP Access Line Type AVP 🚦

This one describes the transmission systems on the subscriber's access loop. Attribute Type 145 ✨

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                      ANCP-Access-Line-Type                    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Length (before hiding) of this AVP is 10. The ANCP Access Line Type AVP defines the type of transmission system in use 🔥

It has a 1-octet field for the Transmission System, then a 3-octet reserved field that MUST be zero. The whole thing is 4 octets long, and it tells you the transmission systems on the access loop. Right now only that 1-octet field has valid values 💜

Valid values:

  • Transmission system:
    • 0x01 ADSL1
    • 0x02 ADSL2
    • 0x03 ADSL2+
    • 0x04 VDSL1
    • 0x05 VDSL2
    • 0x06 SDSL
    • 0x07 UNKNOWN

5.19. Access Line IWF-Session AVP 🌙

This AVP tells you whether an Interworking Function has been performed on the subscriber's session. Attribute Type 254 🫶

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                   Inter-Working Function                      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Inter-Working Function is a 4-octet value 🧚

Valid values for this field:

  • 0x00 IWF not performed
  • 0x01 IWF performed

The Length (before hiding) of this AVP is 10.

6. Connect Speed Update L2TP Attribute Value Pair Extensions 🎉

The next sections cover the Connect Speed Update AVPs 🌈 Sections 6.1 and 6.2 use the IETF Vendor ID of 0, so they're all IETF-flavoured 💖

The M bit for these AVPs SHOULD be set to 0. 💜 That said, if you really want to stop the L2TP session from being set up or torn down when the peer LNS doesn't support the Connect Speed Update AVP extensions, the M bit MAY be set to 1. There's more on that in Section 4.2 of [RFC2661] and Section 5.2 of [RFC3931] ✨

6.1. Connect Speed Update AVP (CSUN, CSURQ) 🦋

okay so the Connect Speed Update AVP is Attribute Type 97, and it carries the updated connection speeds for this session 💖. It's giving the same energy as the Tx Connect Speed and Rx Connect Speed AVPs, which are Attribute Types 24 and 38 for L2TPv2 and 74 and 75 for L2TPv3 ✨. Since v2 and v3 aren't identical, there's a separate format for each one, so let's look at both 🧚

For L2TPv2 Tunnels, the Attribute Value field looks like this:

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |          Reserved             |      Remote Session Id        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                Current Tx Connect Speed in bps                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                Current Rx Connect Speed in bps                |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

For L2TPv3 Tunnels, it looks like this (the 64-bit speeds spill across a couple of rows, so it's a bit of a puzzle, but it's giving 🧩):

   0                   1                   2                   3
   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
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                     Remote Session Id                         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                Current Tx Connect Speed in bps...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             ...Current Tx Connect Speed in bps (64 bits)         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                Current Rx Connect Speed in bps...
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
             ...Current Rx Connect Speed in bps (64 bits)         |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Remote Session Id is the remote session id relative to the sender, which means it's the identifier the peer assigned to this session 🎀. The Current Tx Connect Speed is a 4-octet value in L2TPv2 or an 8-octet value in L2TPv3. It shows the current transmit connect speed from the LAC's point of view, so it's the data flowing from the LAC to the remote system 💅. The rate is encoded in bits per second. The Current Rx Connect Speed works the same way: it's 4 octets in L2TPv2 or 8 octets in L2TPv3, and it's the current receive connect speed from the LAC's point of view, meaning the data flowing from the remote system to the LAC. Again, the rate is in bits per second 🌸

The Length (before hiding) of this AVP is 18 for L2TPv2 or 26 for L2TPv3 🔥

6.2. Connect Speed Update Enable AVP (ICRQ) 🌈

The Connect Speed Update Enable AVP is Attribute Type 98, and it tells everyone whether the LAC plans to send speed updates to the LNS during the life of the session 🫶 It's a boolean AVP, so presence is the whole story. If it's there, the LAC MAY send speed updates using CSUN (see Section 4.1) during the session, and the LNS SHOULD query for the current connection speed via the CSURQ (see Section 4.2) during failover synchronization ✨ If it's absent, the LAC will not be sending speed updates using CSUN (see Section 4.1) during the session, and the LNS MUST NOT query for the current connection speed via the CSURQ (see Section 4.2) during failover synchronization 🙈

The Length (before hiding) of this AVP is 6 🍓

7. Access Line Information AVP Mapping 💜

okay this part is about mapping the Access Line info from the Access Node/DSLAM into the Access Line AVPs. That mapping is required, so the info has to end up in those AVPs 🔥 You can grab the Access Line information from a few places:

  • Vendor-Specific PPPoE Tags [RFC2516].
  • DHCP Relay Options [RFC3046] and Vendor-Specific Information Suboptions [RFC4243].
  • ANCP [ANCP].

7.1. Summary of Access Line AVPs 🎀

Table 1 is the cheat sheet for all the Access Line AVPs defined in Sections 5.1 through 5.19 💖

+-----------------+----------------------------------------+
| Access Line AVP | Name                                   |
+-----------------+----------------------------------------+
|        1 (0x01) | Agent-Circuit-Id                       |
|        2 (0x02) | Agent-Remote-Id                        |
|      129 (0x81) | Actual-Data-Rate-Upstream              |
|      130 (0x82) | Actual-Data-Rate-Downstream            |
|      131 (0x83) | Minimum-Data-Rate-Upstream             |
|      132 (0x84) | Minimum-Data-Rate-Downstream           |
|      133 (0x85) | Attainable-Data-Rate-Upstream          |
|      134 (0x86) | Attainable-Data-Rate-Downstream        |
|      135 (0x87) | Maximum-Data-Rate-Upstream             |
|      136 (0x88) | Maximum-Data-Rate-Downstream           |
|      137 (0x89) | Minimum-Data-Rate-Upstream-Low-Power   |
|      138 (0x8A) | Minimum-Data-Rate-Downstream-Low-Power |
|      139 (0x8B) | Maximum-Interleaving-Delay-Upstream    |
|      140 (0x8C) | Actual-Interleaving-Delay-Upstream     |
|      141 (0x8D) | Maximum-Interleaving-Delay-Downstream  |
|      142 (0x8E) | Actual-Interleaving-Delay-Downstream   |
|      144 (0x90) | Access-Loop-Encapsulation              |
|      145 (0x91) | ANCP Access Line Type                  |
|      254 (0xFE) | IWF-Session                            |
+-----------------+----------------------------------------+

                 Table 1: Access Line AVP Summary

8. IANA Considerations 🧚

Sections 8.1 and 8.2 cover requests for new values in [IANA.l2tp-parameters]. Those registries are already managed by IANA and are assignable through Expert Review according to [RFC3438]. Section 8.3 covers number spaces that IANA doesn't manage 💅

8.1. Message Type AVP Values 🦋

IANA manages this number space as per [RFC3438]. Two new message types, defined in Sections 4.1 and 4.2, need to be allocated for this specification ✨

Message Type AVP (Attribute Type 0) Values

   28: (CSUN) Connect-Speed-Update-Notification

   29: (CSURQ) Connect-Speed-Update-Request

8.2. Control Message Attribute Value Pairs (AVPs) 🌸

IANA manages this number space as per [RFC3438] too. Two new AVPs, defined in Sections 6.1 and 6.2, need to be allocated for this specification 🫶

Control Message Attribute Value Pairs (AVPs)

   97: Connect Speed Update AVP

   98: Connect Speed Update Enable AVP

8.3. Values for Access Line Information AVPs 💜

The Access Line Information AVPs use the Vendor ID of 3561 for the ADSL Forum, which is now the Broadband Forum 🌈 The number spaces in these values, along with their new allocations (like the enumerated values for the Access Line Access-Loop-Encapsulation AVP and the ANCP Access Line Type AVP), are managed by the Broadband Forum 👑

9. Security Considerations 💀

This part is serious, bestie. Read it all 🚨

The security of these AVPs relies on an implied trust relationship between the Access Node/DSLAM and the BRAS/LAC, and between the LAC and the LNS. The identifiers inserted by the Access Node/DSLAM are unconditionally trusted, and the BRAS does not perform any validity check on the information it receives before forwarding it 😭

These AVPs are meant for environments where the network infrastructure is trusted and secure. That covers the Access Node/DSLAM, the BRAS/LAC, the LNS, and the entire network those devices live in 🔒

Careful consideration should be given to the potential security vulnerabilities in this model before you deploy this option in real networks 👀

The AVPs in this document carry identification and characterization of the subscriber Access Line, and they report connection speed changes. If they're used in a non-secure environment, they could reveal that information 💀 The Tunnel (Control Connection) security considerations are covered in Section 9.1 of [RFC2661] and Section 8.l of [RFC3931]. The hiding of AVP attribute values mechanism can also hide the value of the AVPs in this document if they're sensitive in some environments. AVP hiding is described in Section 4.3 of [RFC2661] and Section 5.3 of [RFC3931] 🙈

The Attributes described in this document neither increase nor decrease the security of the L2TP protocol 🤷‍♀️

It's possible to use [RFC3193] "Securing L2TP with IPsec" to boost security by using IPsec for tunnel authentication, privacy protection, integrity checking, and replay protection 🔐✨

10. Acknowledgements 🫶

Many thanks to Wojciech Dec and the others of the Broadband Forum (previously the DSL Forum) Architecture and Transport Working Group for their help in putting this document together 💖

11. References 📚

11.1. Normative References 🔥

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
  • [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999.
  • [RFC3438] Townsley, W., "Layer Two Tunneling Protocol (L2TP) Internet Assigned Numbers Authority (IANA) Considerations Update", BCP 68, RFC 3438, December 2002.
  • [RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.
  • [TR-101] DSL Forum, "Migration to Ethernet-Based DSL Aggregation", TR 101, April 2006, http://www.broadband-forum.org/technical/download/TR-101.pdf.

11.2. Informative References 🧠

  • [ANCP] Wadhwa, S., Moisand, J., Subramanian, S., Haag, T., Voigt, N., and R. Maglione, "Protocol for Access Node Control Mechanism in Broadband Networks", Work in Progress, March 2009.
  • [IANA.enterprise-numbers] Internet Assigned Numbers Authority, "PRIVATE ENTERPRISE NUMBERS", http://www.iana.org.
  • [IANA.l2tp-parameters] Internet Assigned Numbers Authority, "Layer Two Tunneling Protocol 'L2TP'", http://www.iana.org.
  • [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, "A Method for Transmitting PPP Over Ethernet (PPPoE)", RFC 2516, February 1999.
  • [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
  • [RFC3193] Patel, B., Aboba, B., Dixon, W., Zorn, G., and S. Booth, "Securing L2TP using IPsec", RFC 3193, November 2001.
  • [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
  • [RFC4243] Stapp, M., Johnson, R., and T. Palaniappan, "Vendor-Specific Information Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option", RFC 4243, December 2005.
  • [RFC4679] Mammoliti, V., Zorn, G., Arberg, P., and R. Rennison, "DSL Forum Vendor-Specific RADIUS Attributes", RFC 4679, September 2006.
  • [RFC4951] Jain, V., "Fail Over Extensions for Layer 2 Tunneling Protocol (L2TP) "failover"", RFC 4951, August 2007.

Authors' Addresses ✨

okay the authors' section is where we find out who wrote this, and honestly they're giving main character energy 💅 here are their details, bestie 🫶

Vince Mammoliti
Cisco Systems
181 Bay Street, Suite 3400
Toronto, ON  M5J 2T3
Canada

EMaill: vince@cisco.com


Carlos Pignataro
Cisco Systems
7200 Kit Creek Road
PO Box 14987
Research Triangle Park, NC  27709
USA

EMail: cpignata@cisco.com


Peter Arberg
Redback Networks
300 Holger Way
San Jose, CA  95134
USA

EMail: parberg@redback.com


John Gibbons
Juniper Networks
10 Technology Park Drive
Westford, MA  01886
USA

EMail: jgibbons@juniper.net


Paul Howard

EMail: howsoft@mindspring.com

Five authors, three companies, and a whole lot of ✨ networking knowledge ✨ 🎀

📦 where this page comes from